Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 28

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

  1. #11
    Join Date
    Dec 2010
    Location
    MA, USA
    Posts
    1,205

    Default

    Quote 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.

  2. #12
    Join Date
    Apr 2011
    Location
    Sofia, Bulgaria
    Posts
    75

    Default

    Quote 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.

  3. #13
    Join Date
    Jun 2012
    Posts
    29

    Lightbulb 32-bit is way ahead as regards to battery life

    Quote 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.

  4. #14
    Join Date
    Apr 2011
    Location
    Sofia, Bulgaria
    Posts
    75

    Default

    Quote 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.

  5. #15
    Join Date
    Nov 2012
    Posts
    140

    Default

    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...

  6. #16
    Join Date
    Nov 2007
    Posts
    1,353

    Default

    Firefox has supported being compiled 64bits for years. The only problem that used to exist was adobe flash player didnt release a version compiled 64bit. That is no longer the case and there really is no difference between firefox32bit and firefox64bit.

  7. #17
    Join Date
    Jun 2009
    Posts
    519

    Default

    Quote Originally Posted by Nuc!eoN View Post
    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...
    That's complete rubbish. Firefox never stopped providing x64 binaries for Linux.

    They dropped x64 binaries for Windows in November last year because most users always ended up opting for the 32bit build, and because many third-party plugins on the Windows side are still 32-bit only. And even then, they never went through with it because come December the team had a change of heart and decided to continue with the production of a x64 version of Firefox for Windows.

    And frankly, compiling Firefox on Linux (both x86 and x64) is rather easy on Linux because Mozilla maintains a set of instructions for doing so in their developer pages. It's the x64 compilation on Windows that is much harder because of the need to make Microsoft's Visual Studio compiler play nice with the variety of (typically) Linux libraries like GTK, autoconf and perl, all of which have to be properly imported in Windows before building can even proceed.

  8. #18
    Join Date
    Sep 2009
    Posts
    114

    Default

    Quote Originally Posted by kobblestown View Post
    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.
    Quoted for truth. I don't think many people really understand this. Though I would slightly disagree with the compiler making good use of SSEx. It definitely helps but usually doesn't come close to hand optimization. Regardless, it is much better than using simply x87 but it less to do with doing real vector operations and more to do with the additional hardware.

    Quote Originally Posted by vk512 View Post
    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.
    This is a myth. For one, I doubt Intel or AMD are turning off individual registers that are not being used within a core. Yes a 32 bit pointer is less data to manage than a 64bit pointer but its not like its doubling the amount of memory used or anything.
    We have seen that software compiled for 64 bit architectures usually run faster than 32 bit. The benefit beyond the obvious raw performance advantage is that the CPU and memory can go to a idle state faster. Get the job done quickly and then they can go into a low power state longer than a slower 32 bit OS and program could.

    In the end it is not likely that a 64 bit or 32 bit OS is going to make anything but a negligible difference in power efficiency.

  9. #19
    Join Date
    Dec 2008
    Location
    San Bernardino, CA
    Posts
    231

    Default

    There is more than just a register size difference when comparing 32 vs 64-bits.

    64-bit CPU's have a 64-bit wide ALU, allowing them to process in one instruction (a 64-bit add) what would take two on a 32-bit machine. On pure integer based code a 64-bit machine could theoretically achieve 2x performance. In real life, its going to be much less.

  10. #20
    Join Date
    Sep 2009
    Posts
    114

    Default

    Quote Originally Posted by gururise View Post
    There is more than just a register size difference when comparing 32 vs 64-bits.

    64-bit CPU's have a 64-bit wide ALU, allowing them to process in one instruction (a 64-bit add) what would take two on a 32-bit machine. On pure integer based code a 64-bit machine could theoretically achieve 2x performance. In real life, its going to be much less.
    This is true, however, 64 bit OPs require explicit use and they are rarely used beyond cryptography applications.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •