Announcement

Collapse
No announcement yet.

32-bit vs. 64-bit Ubuntu 13.04 Linux Performance

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

  • 32-bit vs. 64-bit Ubuntu 13.04 Linux Performance

    Phoronix: 32-bit vs. 64-bit Ubuntu 13.04 Linux Performance

    While nearly all modern Intel/AMD x86 hardware is 64-bit capable, among novice Linux users the question commonly is whether to install the 32-bit or 64-bit version of a given distribution. We have previously delivered benchmarks showing Ubuntu 32-bit vs. 64-bit performance while in this article is an updated look in seeing how the 32-bit versus 64-bit binary performance compares when running Ubuntu 13.04 with the Linux 3.8 kernel.

    http://www.phoronix.com/vr.php?view=18676

  • #2
    Am I missing something or is your comment on the OpenArena tests on the second page innaccurate?

    Comment


    • #3
      OpenArena

      Originally posted by bawkbawkboo1 View Post
      Am I missing something or is your comment on the OpenArena tests on the second page innaccurate?
      Yes, that's exactly what I wanted to point out (independently). For OpenArena 32-bits seem certainly better (from the graphs), not the other way.

      It also might be interesting how x32 compares (not in Ubuntu ATM). http://www.phoronix.com/scan.php?pag...tem&px=MTEwMTk
      Last edited by vcunat; 04-25-2013, 03:52 AM. Reason: Additional comment

      Comment


      • #4
        Well, again, its only better for ancient intel graphics, the story would be completely different with at least ivy bridge, or even better - with a real graphics card with real CLOSED source drivers

        Comment


        • #5
          32Bit

          I confess, I use 32Bit Xubuntu. I use it for compatibility and because I have only 4GB Ram. I also use it because, at the time I got the ISO, the page actually recommended I use the 32Bit version. There are still people having issues with 64bit believe it or not and a lot of software only has 32bit versions. I can say with confidence, I'll be using 32bit for the foreseeable future. At least until I get 8 or 16 GB of Ram, then I'll move to 64Bit. But right now I have zero use for it, 32Bit is working out fine for me. I understand I may sound odd to some of you, but it's working out great for me.

          Comment


          • #6
            More than just the OA text doesn't match the graphs. Michael, don't write while tired :P

            Comment


            • #7
              Originally posted by BO$$ View Post
              Any ideas why the big difference in some cases? I was hoping they were more or less equal, maybe with the 64 to have an edge.
              In 64-bit mode the processor has twice the number of registers. So more data can be kept there. Also, the calling convention uses more registers to pass values - no need to put them on the stack for most functions. Also, the FPU implements SSE2. Sure, you can use SSE2 in 32-bit code but your code has to check for the presence of SSE2 because that's not guaranteed. So I assume most application on 32-bit land are compiled with x87 FP code which is slower. I think there's faster SYSCALL instruction too. Maybe other things as well.

              The major drawback is that pointers are twice the size so for pointer heavy applications it might get a bit slower. But it seems that overall 64-bit is worth it. I've been using 64-bit Ubuntu for 5 years now. Never had any problems. And all 32-bit applications run fine. Initially I ran them in a 32-bit jail but now I don't bother. Properly made 32-bit packages for 64-bit distributions pull in the 32-bit libs so it's fine. The dynamic linker knows what libs are needed and where to find them.

              Comment


              • #8
                Originally posted by Mike Frett View Post
                I confess, I use 32Bit Xubuntu. I use it for compatibility and because I have only 4GB Ram. I also use it because, at the time I got the ISO, the page actually recommended I use the 32Bit version. There are still people having issues with 64bit believe it or not and a lot of software only has 32bit versions. I can say with confidence, I'll be using 32bit for the foreseeable future. At least until I get 8 or 16 GB of Ram, then I'll move to 64Bit. But right now I have zero use for it, 32Bit is working out fine for me. I understand I may sound odd to some of you, but it's working out great for me.
                Mike, on Linux you really want to use 64-bit kernel even physical RAM of 1GB (or larger, of course). Due to the way Linux partitions the virtual memory space, there's only 960MB in the kernel-reserved area to map physical memory. So it often has to remap if it needs to access RAM that is not mapped at the moment. I don't know how much it slows down the system - maybe not by any signifficant amount - but why bother. Just use 64-bit kernel and 32-bit userland. The 32-bit support on 64-bit kernels is flawless.

                BTW, are you sure you have access to all your 4 gigs of RAM. If you use non-PAE kernel you' probably have 3.5GB or sth like that. Windows keeps it like that even for PAE kernels. I don't know how it is with PAE-enabled Linux kernels. But Linux calls PAE "an ugly hack". I've switched to 64-bits and never looked back.

                Comment


                • #9
                  @Mike Frett

                  https://wiki.archlinux.org/index.php/Multilib

                  5 apr. 2013 – Enabling the [multilib] repository allows the user to run and build 32-bit applications on 64-bit installations of Arch Linux. [multilib] creates a ...
                  It is also mentioned in the article that the state of multi lib is good enough to go for 64 bit even if you have a lot of 32 bit applications.

                  Comment


                  • #10
                    Originally posted by BO$$ View Post
                    Any ideas why the big difference in some cases? I was hoping they were more or less equal, maybe with the 64 to have an edge.
                    64 bit is superior at data crunching because of it's larger register size. Other than that, the only other glaring reason to go 64 is large ram support.

                    Yes there are more registers in the AMD_64 protocol.
                    no, most programs don't use them (same with all the mmx,sse,3dnow etc no one ever used (I did but that's besides the point).

                    There are other benifits and backfires (large address space), still wish we could get some 64 bit games why everyone has a love affair with 32 is beyond me.. oh yeah Windows. Took them what? until 2005 to even support it.. we had support in 2001 =).

                    Comment


                    • #11
                      Originally posted by kobblestown View Post
                      BTW, are you sure you have access to all your 4 gigs of RAM. If you use non-PAE kernel you' probably have 3.5GB or sth like that. Windows keeps it like that even for PAE kernels. I don't know how it is with PAE-enabled Linux kernels. But Linux calls PAE "an ugly hack". I've switched to 64-bits and never looked back.
                      That only happens if you use a discrete GPU. With an integrated GPU, sure you could still get less than 4GB of usable system memory but you don't actually lose access to the memory, it's just redistributed.

                      Also, most x86-32 linux distros enable PAE. The problems it causes (in terms of stability and performance) are negligible.

                      Comment


                      • #12
                        Originally posted by nightmarex View Post
                        Yes there are more registers in the AMD_64 protocol.
                        no, most programs don't use them
                        Dude, with amd64 all programs use the larger general purpose register file. The compiler automatically generates code for that. Same for SSE2 - that's the way amd64 implements FP math. No x87 there.

                        On the contrary, very few programs benefit from the 64-bitness of registers. Because they have to be explicitly written to do so (and the default word width is 32-bits even in 64-bit mode; the 64-bit instructions require an instruction prefix). A notable example is openssl which is quite a bit faster on amd64 because it uses 64-bit math. Not many others do that.

                        Comment


                        • #13
                          32-bit is way ahead as regards to battery life

                          Originally posted by nightmarex View Post
                          why everyone has a love affair with 32 is beyond me.. oh yeah Windows. Took them what? until 2005 to even support it.. we had support in 2001 =).
                          Ok most people here are focused on raw performance, but having switched back and forth a couple of times since 2007 I now stay with 32-bit on my laptops. On the whole the fact that it consumes less RAM makes it easier on the battery, yet I admit I didn't do a bona fide comparison to see if this would imply more CPU time. As I perceive it, for the usual stuff (office + web, no big games) 32-bit seems more efficient.

                          Comment


                          • #14
                            Originally posted by schmidtbag View Post
                            That only happens if you use a discrete GPU. With an integrated GPU, sure you could still get less than 4GB of usable system memory but you don't actually lose access to the memory, it's just redistributed.

                            Also, most x86-32 linux distros enable PAE. The problems it causes (in terms of stability and performance) are negligible.
                            I think you are mixing the issues somewhat. The lower 4GB of physical address space are never entirelly mapped to RAM. There are regions there dedicated to I/O. Yes, the discrete graphics cards are the biggest offenders but not the only ones. Without any graphics card (discrete/internal) I think you are looking at 256MB reserved area. It only gets bigger with any device you add.

                            The RAM that should have been where the I/O regions are is remapped above the 4GB limit in physical address space. The remapping is set up by the BIOS so check if you have this option enabled otherwise you might really "loose" that RAM. Provided that mapping is in place, it might be that the OS restricts the phisical address space to 4GB even if it could manage more by means of, say, PAE. 32-bit client version of Windows do that for fear of badly written drivers that don't expect to be allocated physical memory above 4GB. I guess that's not the case with Linux because most drivers are part of the kernel and should be 64-bit safe. But you cannot infer this from "first principles". It's just a fact that is either one way or the other.

                            In any case, it's not a good idea to run 32-bit kernel with more that 2GBs of RAM because of the kernel memory mapping issue I wrote about. Well, it's not a big deal either. But there really isn't any good reason to run a 32-bit kernel with 1GB or more. Maybe if you have a binary-only 32-bit driver but that must be quite rare these days. And if you use 64-bit kernel, why not use 64-bit userland too? You can still run your 32-bit applications. Like that they even get full 4GB virtual address space, rather than the default 3GB with 32-bit kernels.

                            Comment


                            • #15
                              Can anybody explain to me why 64bit browser versions are so inefficient?? I mean firefox even dropped plans for 64bit as far as I know because of performance reasons...

                              Comment

                              Working...
                              X