By: JasonB (no.delete@this.spam.com), May 13, 2007 5:37 pm
Room: Moderated Discussions
Linus Torvalds (torvalds@osdl.org) on 5/13/07 wrote:
---------------------------
>So Linux defaults to giving user space 3GB, and just 1GB
>for the kernel. That's basically the "user space is more
>important in the end" version. I think WinXP does a 2:2GB
>split.
That's the default, you can tell it to do a 3:1GB split using the /3GB boot switch. The developers of the application also need to flag it as being capable of using more then 2GB of virtual address space (i.e. they didn't do anything silly like assume pointers were equivalent to 32 bit signed integers) by setting the /LARGEADDRESSAWARE linker flag. (The flag can actually be set in the executable by anybody using a simple tool that comes with Visual C++ but only the developers would know whether it's safe or not.)
Executables with /LARGEADDRESSAWARE set can use 4GB of RAM under 64 bit Windows, which is nice.
>It also needs to map in PCI memory-mapped stuff etc, so in
>practice, it's actually less than that.
Especially when you have video cards with 512MB of RAM in notebooks these days!
>>So, in practical terms, is there benefit from using
>>64-bit OS on a machine with, lets say, 2-3 GB RAM ?
>
>Absolutely. No question what-so-ever. If you have 2GB
>of RAM on a 64-bit architecture, you can access it all
>easily in the kernel, and none of it is limited to just
>some special use. And a single big process can also use
>it effectively at the same time, so a database can
>actually have it all mapped without having to play
>windowing games in user space either.
I agree 100%, even if you are using 32 bit applications! Under 32 bit XP, our software will start having problems allocating more memory once its total footprint exceeds 1.2-1.5GB (the actual amount varies, I believe due to the degree of virtual addess space fragmentation).
That exact same 32 bit software will happily use well over 2GB of RAM on the same PC under XP x64 or 64 bit Vista. I haven't done any testing to confirm this, but I also get the feeling that the performance is significantly higher as well -- memory allocations start to take a long time when the OS is struggling to cram things into a 2GB virtual address space.
It's important to note that the working set can be only a tiny fraction of the total address space that the application is using. When you have large address spaces you can start memory-mapping big files (so you can let the MMU hardware determine which bit of data you're using rather than trying to guess and pull it in manually in software) and do all sorts of other nice tricks that simplify code. The total footprint can be far in excess of the physical memory in the system without any slowdown, as long as the working set remains below the physical memory limit.
As soon as we can assume that all of our customers who want to deal with large data sets are going to be running on a 64 bit OS, we can clean up a lot of code, simplifying a lot of things. This is good for end-users because not only will the code run faster, but it is also less likely to be buggy, and because we will have to spend less time debugging we can spend more time adding new features or further performance enhancements.
---------------------------
>So Linux defaults to giving user space 3GB, and just 1GB
>for the kernel. That's basically the "user space is more
>important in the end" version. I think WinXP does a 2:2GB
>split.
That's the default, you can tell it to do a 3:1GB split using the /3GB boot switch. The developers of the application also need to flag it as being capable of using more then 2GB of virtual address space (i.e. they didn't do anything silly like assume pointers were equivalent to 32 bit signed integers) by setting the /LARGEADDRESSAWARE linker flag. (The flag can actually be set in the executable by anybody using a simple tool that comes with Visual C++ but only the developers would know whether it's safe or not.)
Executables with /LARGEADDRESSAWARE set can use 4GB of RAM under 64 bit Windows, which is nice.
>It also needs to map in PCI memory-mapped stuff etc, so in
>practice, it's actually less than that.
Especially when you have video cards with 512MB of RAM in notebooks these days!
>>So, in practical terms, is there benefit from using
>>64-bit OS on a machine with, lets say, 2-3 GB RAM ?
>
>Absolutely. No question what-so-ever. If you have 2GB
>of RAM on a 64-bit architecture, you can access it all
>easily in the kernel, and none of it is limited to just
>some special use. And a single big process can also use
>it effectively at the same time, so a database can
>actually have it all mapped without having to play
>windowing games in user space either.
I agree 100%, even if you are using 32 bit applications! Under 32 bit XP, our software will start having problems allocating more memory once its total footprint exceeds 1.2-1.5GB (the actual amount varies, I believe due to the degree of virtual addess space fragmentation).
That exact same 32 bit software will happily use well over 2GB of RAM on the same PC under XP x64 or 64 bit Vista. I haven't done any testing to confirm this, but I also get the feeling that the performance is significantly higher as well -- memory allocations start to take a long time when the OS is struggling to cram things into a 2GB virtual address space.
It's important to note that the working set can be only a tiny fraction of the total address space that the application is using. When you have large address spaces you can start memory-mapping big files (so you can let the MMU hardware determine which bit of data you're using rather than trying to guess and pull it in manually in software) and do all sorts of other nice tricks that simplify code. The total footprint can be far in excess of the physical memory in the system without any slowdown, as long as the working set remains below the physical memory limit.
As soon as we can assume that all of our customers who want to deal with large data sets are going to be running on a 64 bit OS, we can clean up a lot of code, simplifying a lot of things. This is good for end-users because not only will the code run faster, but it is also less likely to be buggy, and because we will have to spend less time debugging we can spend more time adding new features or further performance enhancements.
Topic | Posted By | Date |
---|---|---|
Rock/Tukwila rumors | mas | 2007/05/05 11:59 AM |
Rock/Tukwila rumors | David Kanter | 2007/05/05 01:33 PM |
Rock/Tukwila rumors | Dean Kent | 2007/05/05 02:35 PM |
K8 vs Win64 timeline | anonymous | 2007/05/05 05:19 PM |
Yes, I misremembered... | Dean Kent | 2007/05/05 09:03 PM |
Rock | Daniel Bizó | 2007/05/06 01:34 AM |
Rock | Dean Kent | 2007/05/06 06:11 AM |
Rock/Tukwila rumors | Joe | 2007/05/06 10:24 AM |
Rock/Tukwila rumors | Dean Kent | 2007/05/06 10:49 AM |
Rock/Tukwila rumors | Linus Torvalds | 2007/05/06 11:09 AM |
Rock/Tukwila rumors | anon | 2007/05/07 12:32 AM |
Rock/Tukwila rumors | Rakesh Malik | 2007/05/07 08:36 AM |
Rock/Tukwila rumors | Michael S | 2007/05/07 09:06 AM |
Rock/Tukwila rumors | anon | 2007/05/07 08:48 PM |
Rock/Tukwila rumors | Rakesh Malik | 2007/05/08 05:45 AM |
Rock/Tukwila rumors | anon | 2007/05/08 04:30 PM |
Wow. (nt) | Brannon | 2007/05/08 05:16 PM |
Rock/Tukwila rumors | rwessel | 2007/05/08 08:48 PM |
Rock/Tukwila rumors | JS | 2007/05/08 09:07 PM |
Rock/Tukwila rumors | JS | 2007/05/09 05:44 AM |
Rock/Tukwila rumors | Rakesh Malik | 2007/05/09 04:35 AM |
Much ado about x | Michael S | 2007/05/09 08:39 AM |
Call it x86-64 | Linus Torvalds | 2007/05/09 09:27 AM |
(i)AMD64 | Michael S | 2007/05/09 11:16 AM |
(i)AMD64 | Linus Torvalds | 2007/05/09 11:29 AM |
(i)AMD64 | Groo | 2007/05/09 03:45 PM |
TIFNAA | anonymous | 2007/05/09 04:49 PM |
Inspired by FYR Macedonia? (NT) | Michael S | 2007/05/09 10:21 PM |
More likely... | rwessel | 2007/05/09 11:39 PM |
TIFNAA | Gabriele Svelto | 2007/05/09 10:57 PM |
(i)AMD64 | James | 2007/05/10 01:27 AM |
i86 | Dean Kent | 2007/05/09 11:30 AM |
(i)AMD64 | Max | 2007/05/09 12:28 PM |
wide86? long86? | hobold | 2007/05/10 04:05 AM |
x87 perhaps, it is one more. :) (NT) | Groo | 2007/05/10 04:50 AM |
x86+ | Dean Kent | 2007/05/10 07:44 AM |
Does it really matter? | Doug Siebert | 2007/05/10 08:10 AM |
let's stay with x86-64 for now, please | Marcin Niewiadomski | 2007/05/10 10:50 AM |
let's stay with x86-64 for now, please | Dean Kent | 2007/05/11 05:11 AM |
let's stay with x86-64 for now, please | rwessel | 2007/05/11 01:46 PM |
let's stay with x86-64 for now, please | Dean Kent | 2007/05/11 05:03 PM |
let's stay with x86-64 for now, please | Michael S | 2007/05/12 09:49 AM |
let's stay with x86-64 for now, please | Dean Kent | 2007/05/12 12:05 PM |
let's stay with x86-64 for now, please | Michael S | 2007/05/12 12:25 PM |
let's stay with x86-64 for now, please | Dean Kent | 2007/05/12 02:39 PM |
let's stay with x86-64 for now, please | JasonB | 2007/05/13 06:43 AM |
client consolidation | Michael S | 2007/05/13 07:37 AM |
let's stay with x86-64 for now, please | Tzvetan Mikov | 2007/05/13 02:44 PM |
let's stay with x86-64 for now, please | rwessel | 2007/05/14 01:42 PM |
What's your point? | Doug Siebert | 2007/05/11 01:56 PM |
What's your point? | Linus Torvalds | 2007/05/11 03:15 PM |
What's your point? | Doug Siebert | 2007/05/13 02:11 PM |
What's your point? | Dean Kent | 2007/05/13 06:04 PM |
What's your point? | JasonB | 2007/05/14 01:06 AM |
What's your point? | Dean Kent | 2007/05/14 06:20 AM |
What's your point? | JasonB | 2007/05/14 03:35 PM |
What's your point? | JasonB | 2007/05/14 06:35 PM |
What's your point? | Dean Kent | 2007/05/14 07:12 PM |
What's your point? | Dean Kent | 2007/05/11 05:06 PM |
What's your point? | Stephen H | 2007/05/13 12:55 AM |
Why didn't MS take advantage of PAE? | David W. Hess | 2007/05/13 07:37 AM |
PAE sucks (Why didn't MS take advantage of PAE?) | Linus Torvalds | 2007/05/13 09:20 AM |
PAE sucks (Why didn't MS take advantage of PAE?) | Dean Kent | 2007/05/13 09:49 AM |
PAE sucks (Why didn't MS take advantage of PAE?) | David W. Hess | 2007/05/13 11:37 AM |
> 1 GB RAM on a 32-bit system | Tzvetan Mikov | 2007/05/13 12:44 PM |
> 1 GB RAM on a 32-bit system | S. Rao | 2007/05/13 02:00 PM |
> 1 GB RAM on a 32-bit system | Tzvetan Mikov | 2007/05/13 04:32 PM |
> 1 GB RAM on a 32-bit system | S. Rao | 2007/05/13 11:19 PM |
> 1 GB RAM on a 32-bit system | Linus Torvalds | 2007/05/13 02:46 PM |
> 1 GB RAM on a 32-bit system | Tzvetan Mikov | 2007/05/13 04:23 PM |
> 1 GB RAM on a 32-bit system | JasonB | 2007/05/13 05:37 PM |
Windows manages memory differently | Tzvetan Mikov | 2007/05/13 07:31 PM |
Windows manages memory differently | JasonB | 2007/05/14 12:50 AM |
Windows manages memory differently | Tzvetan Mikov | 2007/05/14 07:56 AM |
Windows manages memory differently | rwessel | 2007/05/14 02:40 PM |
Windows manages memory differently | David W. Hess | 2007/05/14 03:07 PM |
Windows manages memory differently | rwessel | 2007/05/14 03:51 PM |
Windows manages memory differently | Tzvetan Mikov | 2007/05/14 04:40 PM |
Windows manages memory differently | rwessel | 2007/05/14 05:09 PM |
Windows manages memory differently | Howard Chu | 2007/05/14 10:17 AM |
Windows manages memory differently | Jukka Larja | 2007/05/14 10:30 AM |
Windows manages memory differently | Tzvetan Mikov | 2007/05/14 12:54 PM |
Windows manages memory differently | Howard Chu | 2007/05/15 02:35 AM |
Windows manages memory differently | Groo | 2007/05/15 06:34 AM |
Anyone know what OS X (10.4, Intel, desktop) does? | Matt Sayler | 2007/05/15 05:23 AM |
Anyone know what OS X (10.4, Intel, desktop) does? | Wes Felter | 2007/05/15 07:37 AM |
Anyone know what OS X (10.4, Intel, desktop) does? | Anonymous | 2007/05/15 09:49 AM |
Anyone know what OS X (10.4, Intel, desktop) does? | anon2 | 2007/05/15 06:13 PM |
PAE sucks (Why didn't MS take advantage of PAE?) | Paul | 2007/05/13 02:40 PM |
PAE sucks (Why didn't MS take advantage of PAE?) | Peter Arremann | 2007/05/13 04:38 PM |
PAE sucks (Why didn't MS take advantage of PAE?) | Henrik S | 2007/05/14 02:31 AM |
The fragility of your argument | slacker | 2007/05/13 02:56 PM |
The fragility of your argument | nick | 2007/05/13 04:42 PM |
The fragility of your argument | Howard Chu | 2007/05/14 01:52 AM |
The fragility of your argument | Dean Kent | 2007/05/14 08:19 AM |
The fragility of your argument | anon2 | 2007/05/14 07:26 AM |
The fragility of your argument | Tzvetan Mikov | 2007/05/14 08:01 AM |
The fragility of your argument | Dean Kent | 2007/05/14 08:16 AM |
The fragility of your argument | Linus Torvalds | 2007/05/14 10:57 AM |
The fragility of your argument | JasonB | 2007/05/14 03:48 PM |
The fragility of your argument | Dean Kent | 2007/05/14 06:36 PM |
The fragility of your argument | Ricardo B | 2007/05/16 01:40 AM |
The fragility of your argument | Dean Kent | 2007/05/16 02:32 AM |
The fragility of your argument | Ricardo B | 2007/05/16 05:41 AM |
PS | Ricardo B | 2007/05/16 05:50 AM |
The fragility of your argument | Dean Kent | 2007/05/16 08:07 AM |
Modern web browsing | S. Rao | 2007/05/16 08:16 AM |
Aha! | Dean Kent | 2007/05/16 08:27 AM |
Aha! | Dean Kent | 2007/05/16 08:32 AM |
Aha! | S. Rao | 2007/05/16 09:34 AM |
The fragility of your argument | Ricardo B | 2007/05/16 09:00 AM |
The fragility of your argument | Vincent Diepeveen | 2007/05/16 09:10 AM |
The fragility of your argument | Paul | 2007/05/16 02:01 PM |
The fragility of your argument | Vincent Diepeveen | 2007/05/17 02:05 AM |
The fragility of your argument | anon2 | 2007/05/15 12:35 AM |
Splits vs page allocations? | Matt Sayler | 2007/05/15 06:33 AM |
What's your point? | Michael S | 2007/05/13 07:55 AM |
What's your point? | anonymous | 2007/05/13 10:08 AM |
What's your point? | Michael S | 2007/05/13 10:31 AM |
let's stay with x86-64 for now, please | JasonB | 2007/05/13 06:16 AM |
x864 =) (NT) | some1 | 2007/05/15 02:03 AM |
Rock/Tukwila rumors | IntelUser2000 | 2007/05/06 01:27 PM |
Rock/Tukwila rumors | m | 2007/05/13 07:05 AM |
Rock/Tukwila rumors | mas | 2007/05/15 08:40 AM |