64-bit in Einstein crunching
25 Dec 2007 6:57:18 UTC
Topic 193402
(moderation:
Hi all! Preved! :-)
Sorry, but I didn't found anything about any benefits of using 64-bit OS, BOINC client etc. Will 64 bit give any advantages about crunching speed, performance or smth.? I supose that E@h application(s) are not optimized for 64 bits? Is there a native application(s)compiled under 64 bits at all?
64-bit in Einstein crunching
)
Currently there are no E@H apps that use 64 Bit instruction sets. The performance benefit would be minimal, but you'd get some limited speedup because in 64 bit mode a few more registers are available for the compiler to store temporary data in.
CU
Bikeman
Preved, Medved! The gain
)
Preved, Medved!
The gain in pefomance will rise not just because of wide registers in use, but also by running 64 bit processor in native 64-bit and not having headake of using 32-bit instructions prefixes. Some gain can be achieved of cause by 64-bit data alignment and 64-bit computation. But this means the final code should be optimized after compilation.
So, why just not to try?
RE: Preved,
)
Preved, my understanding friend! It seems that project developers just doesn't want to pay attention to such unperspective (in they opinion) part of cruncher's machines like x64... But may be this is only our lammer's mistake?
RE: Preved, Medved! The
)
I think there are some problems in this reasoning:
Isn't the exact opposite true? The science app is mainly dealing with floating point and 32 bit integer data types. The current app does not use "32-bit instruction prefixes" because 32 bit is the default. You would get those prefixes only if you compiled the app to run in 64 bit mode, however, because you just don't want to convert all 32 bit integer data types into 64 bit integer data types (effort, memory consumption, effort, effort :-) ).
Bikeman
I think, the use of memory is
)
I think, the use of memory is not a reason these days. My current version 4.15 consume only 40 Megs of RAM. Multiply it by 4 for Quad-Core - it will be only 160 Megs. Let it be. Take a look at Windows Vista - it consumes by default about 750 Megs and this is (by Microsoft's opinion) normal. I think the gain of use native 64-bit mode and 64-bit data alingment by default right from compile time, will give us more potentials than larger consumption of system resourses.
I remember those times when Intel presents i386 and 32-bit data extentions and (later) made it a native mode for P3s. There were a lot of people who said that 32 bit is redundant and not really necessary. And what we do get nowadays. So, I think 64 bit is our future and soon it will not be as redundant as it seems.
RE: I think, the use of
)
This neglects the rather limited fast CPU cache memory. If you are unnecessarily expanding data types from 32 to 64 bits, you will waste 50% of the cache!
Data alignment is something that the compiler and runtime library can deal with, it's independent of the CPU. In fact, with programs using the standard GNU C
runtime library (like E@H under Linux), you can configure the data alignment of dynamically allocated memory at runtime by setting the environment variable MALLOCALIGN to any power of 2 >= 2^3= 8. This is the alignment in bytes(!!), in fact, 8 bytes (64 bits) is already the default (and minimum)alignment for data memory in most compilers, even on 32 bit systems. You might get slightly better performance with alignments of 32 bytes or 64 bytes: this way you ensure that a block of memory always starts at a cache line boundary.
CU
Bikeman
And this is the main reason
)
And this is the main reason why we should try 64-bit executable on 64-bit systems and beta test it. The cache size is large enough to maintain necessary data in it for fast transformations. The other computations that require large memory tables indeed will not feed the cache and must be optimized for faster memory access - one more argument for 64-bit data in memory that nowadays (I mean DDR,DDR2,DDR3) gain perfomance in large data transfers rather than in faster data access (look at CAS latencies for DDR2-1066 and 1333 modules).
The data in memory should be already organaized in tables for faster access (I didn't saw the code but I think it already is) and it can be partially done right in compile time (for constants like sometimes ago we did it for sin/cos tables) and in runtime also.
I still tend to disgree here.
)
I still tend to disgree here. The way the CPU fetches data from memory doesn't depend so much on the mode (32 or 64 bits) it is running in. No matter if you load a single byte, a word , a double or quad word, the CPU will always load a whole cache-line (32 or 64 *bytes* depending on the CPU) from RAM to CPU-Cache. And if the access pattern to this array is regular enough (constant stride), a modern CPU will even speculatively pre-fetch the next segment of the array in advance before it's actually requested.
So if you are using an array of (say) 64 bit integers in 64 bit mode although 32 bits would do, in the end you require twice as much memory-bandwidth. I don't see the advantage.
The only advantage I see here is for programs that can use the 64 bit address space e.g. databases, and the extra registers you get in the 64 bit instruction set mode. But not much more.
CU
Bikeman
RE: The only advantage I
)
The advantage depends on the application.
The ABC@Home project runs double fast in 64 bit mode.
Wow, that's something!!
)
Wow, that's something!!
But are you sure the apps are using the same code basis and the only difference is the 64 bit mode? I mean if you compile for 64 bit you know you'll have SSE2 so you can just throw that it, while the 32 bit app might be x87 based. Just speculating, tho.
CU
Bikeman