Announcement

Collapse
No announcement yet.

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

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by schmidtbag View Post
    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

    Comment


    • #32
      Originally posted by schmidtbag View Post
      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:

      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)
      Last edited by drago01; 03-01-2012, 02:19 PM.

      Comment


      • #33
        Originally posted by Wildfire View Post
        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.

        Comment


        • #34
          Originally posted by schmidtbag View Post
          the registers directly affect total memory consumption
          No they do NOT.

          Comment


          • #35
            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.

            Comment


            • #36
              Originally posted by Wildfire View Post
              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.

              Comment


              • #37
                Originally posted by schmidtbag View Post
                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.

                Originally posted by movieman View Post
                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.

                Originally posted by Spacenick View Post
                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

                Comment


                • #38
                  Originally posted by Wildfire View Post
                  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?

                  Comment


                  • #39
                    Originally posted by ChrisXY View Post
                    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).

                    Comment


                    • #40
                      Originally posted by ChrisXY View Post
                      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.

                      Comment


                      • #41
                        So you would need a special 64 bit kernel with a 32 bit userland and a modified compiler.. The advantage would of course be that you can store twice as many 32 bit integers as 64 bit integers.

                        Comment


                        • #42
                          Originally posted by ChrisXY View Post
                          So you would need a special 64 bit kernel with a 32 bit userland and a modified compiler.. The advantage would of course be that you can store twice as many 32 bit integers as 64 bit integers.
                          Sure, you need a special kernel. I don't know if it will ever make to the official kernel though. And you need all libraries and the appropriate applications compiled for this ABI. One can argue that if you need to recompile anyhow you better recompile for x86_64. But (1) not all applications are 64-bit safe at the source level and (2) the developers of x32 claim a hefty advantage in performance over x86_64, sometimes up to 30%.

                          Comment


                          • #43
                            Originally posted by ChrisXY View Post
                            So you would need a special 64 bit kernel with a 32 bit userland and a modified compiler.. The advantage would of course be that you can store twice as many 32 bit integers as 64 bit integers.
                            Nothing stopping you from using 32 bit integers on "pure" 64 bit either And since you're up to 1 TB or even 256 TB theoretical memory limit from previously 4 GB you can store way more integers [Some older 64 bit processors use 40 address bits ~ 1 TB, newer ones have 48 bits ~ 256 TB].

                            Comment


                            • #44
                              In any case, given only 1GB RAM, or less, I would run 32-bit Linux. Especially with a Core 2 processor. The Cor 2 microarchitecture has an optimization (micro-ops fusion I think) which is only available in 32-bit. I don't know if that means that the OS should be running in 32-bit mode or the 32-bit tasks under a 64-bit kernel still get to use it. But for 64-bit tasks it is certainly not there. I think Nehalem was the first Intel microarchitecture to extend micro-ops fusion to 64-bit mode. Certainly, Core 2 is a bit outdated nowadays but there are still plenty of machines running and those are more likely to have less than 2GB anyhow. This should not apply to AMD processors which has always had superior 64-bit implementation, although today they are lagging behind Intel in all departments (except, maybe, for Atom vs Brazos).

                              But given 2GB of RAM I would run 64 bit kernel even with a Core 2 processor. There is a peculiarity in Linux WRT memory handling that might cause a small performance hit, although some people claim it's negligible. The kernel keeps the physical memory mapped in the kernel area memory space. With the default 3G/1G split, there's not enough virtual memory space to map the entire memory. That applies to 1GB as well but is certainly more severe, the more memory you have. Now, I'm not a Linux kernel expert and I don't know all the ramifications of having a big HIGHMEM (as it's called) area but I just don't want to go there. I've been happily using 64-bit Linux for more than 3 years already but then, I have 8GB of memory, so it's really a no brainer to me. And I like the idea of 64-bit anyhow. There's additional consideration for floating point-heavy applications. x86_64 can benefit from using SSE2 for floating point by default. Of course, 32-bit applications can also use it if it's present but they have to be compiled appropriately (runtime identification requires specially written applications/libraries). Since most 32-bit distributions are compiled for lesser architectures they don't automatically use SSE2 if present. I guess this advantage is mostly theoretical but with 64-bit OS and applications I don't have to worry about such things (and I do worry - I'm a geek).

                              There is, of course, the problem of some applications being 32-bit only. The ones I'm using are Skype, Acrobat Reader and WINE. For those I have a 32-bit root jail managed with the schroot package. I don't want to pollute my 64-bit environment with 32-bit crap and root jails allows me to keep them isolated. And when I reinstall my Linux I simply copy over the root directory of the jail and the schroot configuration and there I have it. There was also a problem with Skype under Ubuntu 11.10. It depends on a 32-bit package that is not present for 64-bit installs (they officially support 10.04 LTS). That may be fixed now but I really don't want to spend too much time just to make Skype work.

                              As several people have noted, in this discussion and previous related ones, it will also be interesting to see how 32-bit userspace performs under 64-bit kernel. This can easily be tested with a root jail - you can have a complete distribution (without the kernel, obviously) and do whatever you like without affecting the main installation. But Michael seem to be impervious to such pleas
                              Last edited by kobblestown; 03-02-2012, 04:40 AM.

                              Comment


                              • #45
                                Originally posted by Wildfire View Post
                                Nothing stopping you from using 32 bit integers on "pure" 64 bit either.
                                This is actually the default . IIRC in order to use 64-bit operations the instruction needs to be prefixed accordingly. This adds one byte to the size of the instruction but I guess that penalty is mitigated by the performance advantage if used judiciously. Just look at the OpenSSL results!

                                Comment

                                Working...
                                X