You are not logged in.
Pages: 1
I'm looking for the fastest possible version, and I was wondering if Arch64 is faster than regular Arch. Are there any significant downfalls to Arch64?
Offline
Is is sometimes faster, sometimes slower (probably due to binary size). Read this http://www.bit-tech.net/bits/2007/10/16 … _the_ram/1 for a general idea of what the difference.
And also, it might be a bit more work getting 32 bit only programs running, such as wine, and skype and flash, though there are bin32-* packages for those, which introduces more overhead, since you then have 32 bit libraries loaded at the same time as 64 bit libraries that do the same thing.
You probably won't notice 64 bit being faster (I don't), unless you happen to access tons of ram (>4gb), which I don't have.
Anyone else have a say on this?
Offline
If you're like me and one of the primary functions of your box it to encode videos, you will benefit from 64 bit (x264 is clearly faster under 64 bit from my experience). Some rendering engines will perform better under 64 bit, some will have no real effect (Blender internal was giving me identical results on both architectures). Large databases will certainly do better under 64 bit. Compiling is much faster on 64 bit.
Games, if I understand correctly, will run better under 32 bit until it hits a point of critical mass with pointers. If there aren't huge numbers of pointers, memory allocation will be faster under 32 bit. But after a certain threshold, swapping out memory has a point of diminishing returns. I can't remember where the article is that I read that, but their tests show that most games tested never got to that point.
Offline
If I recall correctly x86_64 bit gives you three things:
1. 64 bit memory addressing (i.e. access to > 4GB of virtual memory)
2. 64 bit integer registers make operations on > 32 integers faster
3. Double the number of integer and floating point registers (16 vs. 8)
4. No execute flag
Using 64 bit addressing helps alot if you need > 4GB of RAM, it's alot faster and simpler than Intel's PAE which allowed 32 bit processors to use > 4GB of RAM (PAE creates a buffer within the first 4GB of RAM and reads/writes high memory by copying it through the buffer). Compression and encryption operations use alot of big integers (oftentimes > 64 bit) and thus run faster in 64 bit mode. Register access is faster than L1 cache access, and increasing the number of registers decreases useage of L1 data cache (thus reducing L1D miss rate); therefore, most non-trivial programs will benefit from this. Finally the no execute flag allows the operating system to flag areas of memory as non-executable, the CPU will refuse to accept instructions from non-executable memory. This makes buffer overflow attacks alot harder.
However, there are downsides. To differentiate 64 bit instructions from 32 bit ones, AMD had to add a prefix byte, making each 64 bit instruction one byte longer than the equivalent 32 bit instruction. Additionally the increased number of registers (8 = 2^3 = 3 bits, 16 = 2^4 = 4 bits) and larger pointers make some 64 bit instructions still larger. That means fewer instructions fit in the L1 instruction cache, which increases L1I cache miss rate. Larger pointers and increased use of long (64 bit) integer values makes program data structures larger, this increases both RAM useage, and the amount of memory and FSB bandwidth required to move the data. Finally, the CPU has to change modes when switching between 64 bit and 32 bit modes, and as vogt mentioned above will require loading both 32 bit and 64 bit versions of some libraries. So there is definetely a performance hit when running 32 bit apps on a 64 bit OS.
So for any given application it's hard to predict whether performance will improve of decline - unless it routinely uses > 4GB of RAM (database, high end 3D rendering, etc.) or uses alot of big integers (compression, encryption), in which cases it will generally peform better if recompiled for 64-bit. And 32 bit apps will generally perform worse on a 64 bit OS.
Last edited by RagingDragon (2008-09-04 05:09:59)
Offline
Pages: 1