Ubuntu 12.04 LTS: 32-bit vs. 64-bit Performance

Quote:

---

Originally Posted by schmidtbag

when i was using the term register i was referring to the cpu itself, ram has little to do with registers. i guess i should've been more specific where the jugs are the amount of cpu registers and the contents are how many registers are used. I was pretty tired when i wrote that analogy. so does that change anything? i think i understand what you're trying to say now but you're focusing more on the userspace level, which is generally what uses up the most memory but doesn't define much of what happens to it at the architectural level; the architectural level is the important part because thats why 64 bit is often considered to be more memory consuming.

---

I'm not sure we're on the same page here :) I was under the impression that when people refer to memory consumption they're primarily concerned about ram, not cpu registers. This is also where the reported 15-20% increase in memory consumption comes from.

Are you saying that 32 bit on a 64 bit architecture kind of "wastes" registers because data is only using half of the space available in each register? I haven't written assembler code in some time (and never on 64 bit architecture) but afair a register is either in use or it's not, which means it shouldn't matter how much data it contains. Neither should a 64 bit value use more registers, because on 64 bit architecture all registers are 64 bit wide. The only part of a cpu which could be affected is its cache, which can only store half as many 64 bit values as 32 bit values. Long story short, I'm still confused what you're trying to say :)

Quote:

---

Originally Posted by schmidtbag

mind explaining why? what i've described is what i've seen first-hand. 32 bit binaries running on 64 bit operating systems ARE generally more memory consuming. running a 64 bit binary of the same program on a 64 bit OS generally is just as memory consuming as the 32 bit version - once in a while i've seen the 64 bit version use up a bit more memory. maybe what i said about the registers is wrong, but here's how i see it:

So, if you think this is "nonsense", mind explaining how it REALLY works with the same analogy?

---

No I am not going to use pick up your analogy (because it does not make sense) but rather try to explain it differently. You wrote:

Quote:

---

what i should have said is 32 bit programs running in 64 bit can OFTEN use UP TO double the amount of ram usage, due to 64 bit being double the amount of registers

---

When running the 32bit program on a 64bit CPU the additional registers are simply not used at all. There is no way this can lead to even single byte of extra memory consumption. CPU registers have nothing to with the memory usage of the program. Hence why I said "that's nonsense". You can add 100 more registers to the CPU the memory consumption won't change.

Your misunderstanding seem to come from the fact that you don't seem to know what CPU registers actually are. So I recommend some reading (ex. http://en.wikipedia.org/wiki/Processor_register)

Quote:

---

Originally Posted by Wildfire

I'm not sure we're on the same page here :) I was under the impression that when people refer to memory consumption they're primarily concerned about ram, not cpu registers. This is also where the reported 15-20% increase in memory consumption comes from.

Are you saying that 32 bit on a 64 bit architecture kind of "wastes" registers because data is only using half of the space available in each register? I haven't written assembler code in some time (and never on 64 bit architecture) but afair a register is either in use or it's not, which means it shouldn't matter how much data it contains. Neither should a 64 bit value use more registers, because on 64 bit architecture all registers are 64 bit wide. The only part of a cpu which could be affected is its cache, which can only store half as many 64 bit values as 32 bit values. Long story short, I'm still confused what you're trying to say :)

---

the registers directly affect total memory consumption which is why i brought them up. and yes, what i was saying that 32 bit binaries on 64 bit OSes waste registers - and thats why considering people seem to disagree, i was hoping someone would prove me wrong (prove meaning explain, not just saying "that's wrong"). i think i could try explaining my point a little better, but the more i think about it, the more i realize myself that i might be wrong. in the end, i still don't have an answer for why 32 bit programs can end up being significantly more memory consuming on 64 bit systems, but i am pretty sure i'm looking at this the wrong way.


but, i still want to point out that 64-bit linux is not nearly as memory consuming as people are making it out to be. i have yet to see a program that uses up to 20% more memory (or even 15% more) than it's 32 bit counterpart.

Quote:

---

Originally Posted by schmidtbag

the registers directly affect total memory consumption

---

No they do NOT.

That's only 99.999% correct :-)
They do affect memory consumption because they need to be saved for context switches and they affect memory consumption because with more registers less stack is used.
But it doesn't matter much because for registers it's as simple as "more is better".

To get back on topic though I think it's absolutely stupid to use a 32bit OS on 64bit hardware. That's always true on x86 where 32bit software can really use only a fraction of the registers which is horrible especially since it makes function calls orders of magnitude less efficient.
On other architectures like MIPS or SPARC it's not such a big problem because they have sane 32bit ABIs so it's only a matter of "can some program use >3 GB RAM (last gig is reserved for kernel so it's 4 GB for 32bit apps on 64bit kernel)"
And even this question more often then not should be "hell yes I want them to be able to use more RAM".

One thing many people don't understand is that RAM usage is a good thing, as long as it's used for data that's needed.
That's also why some people are concered because Linux never leaves much of the RAM unused but will use everything not used by an application to cache filesystem data.
It's quite simple actually, the goal is to always have the data you need in the fastest memory you got!
And yes there are a lot of applications where it makes huge sense to use a lot more then 3 GB of RAM.

Also you can't mmap a big file on 32bit and mmapping is one of the best ways to do fast and efficient file access methods.

In the end if your hardware supports it you'd be dumb to not use 64bit.

Quote:

---

Originally Posted by Wildfire

As someone else already pointed out, 64 bit applications consume about 15-20% more memory, due to pointers being 64 bit instead of 32 bit.

---

Only if 15-20% of your data is pointers. Which would be possible if you're running a language like Java where every object is a pointer to memory allocated on the heap, but a strange special case in a native language like C++.

Programs that process a lot of data are typically working with pixels (image editing, video editing, games, etc), which are a fixed size regardless of your register size. So if you're using a lot of RAM you'll probably find that very little is used for pointers.

In addition, I've often seen 64-bit code compile significantly smaller than 32-bit code, presumably because it can keep more data in registers and doesn't have to keep generating instructions to push it out to RAM and read it back.

I just can't imagine having a 64-bit CPU and not running a 64-bit OS on it, unless you are in one of those strange special cases where it's beneficial.

Quote:

---

Originally Posted by schmidtbag

the registers directly affect total memory consumption which is why i brought them up. and yes, what i was saying that 32 bit binaries on 64 bit OSes waste registers - and thats why considering people seem to disagree, i was hoping someone would prove me wrong (prove meaning explain, not just saying "that's wrong"). i think i could try explaining my point a little better, but the more i think about it, the more i realize myself that i might be wrong. in the end, i still don't have an answer for why 32 bit programs can end up being significantly more memory consuming on 64 bit systems, but i am pretty sure i'm looking at this the wrong way.

---

The number of registers on a cpu is fixed, you cannot dynamically create more of them. The size of a register on a 64 bit cpu is typically 64 bit wide and it has some additional registers, compared to a 32 bit cpu.

While a 32 bit application only uses 32 bit of each register (same as on a 32 bit cpu), that doesn't mean it suddenly uses more of them. The "unused" bits aren't exactly "wasted" either, because it's not like somebody else could use them while your process is executing. A 32 bit application also doesn't "see" those additional registers, they're only available to 64 bit processes.

The one thing you could say is, that a 32 bit application doesn't use a 64 bit cpu to its full potential. However none of this causes it to use more resources, it simply doesn't use all available resources. Which is why it doesn't make much sense to use a 32 bit OS on 64 bit architecture.

Quote:

---

Originally Posted by movieman

Only if 15-20% of your data is pointers. Which would be possible if you're running a language like Java where every object is a pointer to memory allocated on the heap, but a strange special case in a native language like C++.

---

I agree, it really depends on your pointer-to-data ratio. On the other hand, C++'s int depends on the architecture, so unless you're using int32_t all your ints could needlessly double in size. Maybe this is something that happened early on (simple recompile) which might explain why memory consumption "doubled" on some occasions.

Quote:

---

Originally Posted by Spacenick

That's only 99.999% correct :-)
They do affect memory consumption because they need to be saved for context switches and they affect memory consumption because with more registers less stack is used. But it doesn't matter much because for registers it's as simple as "more is better".

---

Going by general purpose registers only, if you're saving the state for 10,000 threads you'd go from 10,000 x 8 registers x 32 bit (~312 KiB) to 10,000 x 16 x 64 (~1,250 KiB). I don't know much about the other registers (like SSE) but even if you increase those numbers tenfold it should hardly matter :)

Quote:

---

Originally Posted by Wildfire

While a 32 bit application only uses 32 bit of each register (same as on a 32 bit cpu), that doesn't mean it suddenly uses more of them. The "unused" bits aren't exactly "wasted" either, because it's not like somebody else could use them while your process is executing. A 32 bit application also doesn't "see" those additional registers, they're only available to 64 bit processes.

---

Is that logic hardwired? I mean, you could theoretically store 2 32 bit integers in each 64 bit register and I imagine shifting 32 bits would still be faster than fetching something from RAM... Or would the increased access time for approximately 1/2 of the register accesses invalidate that advantage?

Quote:

---

Originally Posted by ChrisXY

Is that logic hardwired? I mean, you could theoretically store 2 32 bit integers in each 64 bit register and I imagine shifting 32 bits would still be faster than fetching something from RAM... Or would the increased access time for approximately 1/2 of the register accesses invalidate that advantage?

---

In a 32 bit mode, the code doesn't see the upper 32 bits of the 64-bit registers. There are no instructions with which to access them. The x32 Linux kernel ABI tries to combine the advantages of both x86 and x86_64 modes (sans >4GB process memory space). The idea is to run in 64-bit mode but only use 32-bit address values, e.g. for pointers. The application should have access to more registers, and I guess to the upper 32-bit parts should it need them (even in 64-bit mode the default operand size is 32 bits).

Quote:

---

Originally Posted by ChrisXY

Is that logic hardwired? I mean, you could theoretically store 2 32 bit integers in each 64 bit register and I imagine shifting 32 bits would still be faster than fetching something from RAM... Or would the increased access time for approximately 1/2 of the register accesses invalidate that advantage?

---

As far as I know a 32 bit application doesn't know the register is actually 64 bit so it can't do any such tricks. The additional registers aren't accessible to a 32 bit process either (even if they were, it simply doesn't know about them). As far as the performance trade off between fewer memory roundtrips vs. more logic required to do all those shift-shenanigans goes, I really don't know. It would definitely make your assembler code far more complex (and error prone).

Even if you could change your 32 bit application to be 64 bit aware you could just go one step further and turn it into a 64 bit application anyway. On top of that, unless you're programming in assembler you usually don't get access to the registers on such a level, which means such tricks would have to be implemented on the compiler level.