Message boards :
Number crunching :
Versions for x86_64 platforms avaible ?
Message board moderation
Previous · 1 · 2 · 3 · Next
| Author | Message |
|---|---|
|
Send message Joined: 13 Jul 05 Posts: 456 Credit: 75,142 RAC: 0 |
This topic seems to get asked over and over again .. the "64-bitness" refers to integer functions [...] The thing about Sixtrack is the important parts of it aren't ran on the integer (ALU) [...] As you say this cones up frequently, but your point is only three-quarters right. You correctly identify 3 things that are not helped by 64 bit processing. However, as I understand it, a 64 bit machine still gives you faster fetching of program code (8 bytes at a time instead of 4) and faster fetch and store of those douple precision floats that sixtrack so loves. In other words it is the wider bus between RAM and cache that makes the most useful difference to sixtrack. What I am not clear on, is if you have a 64 bit machine running 32 bit code in backwards compatibility mode, then presumably the hardware can still give you those advantages anyway -- any hardware geniuses care to comment? If so, then you get the bonus even when running the 32 bit client. If not, then you'd need the 64 bit client to benefit. At a guess I'd put money on around 5% to 10% performance boost on a 64 bit sixtrack, but I don't know if anyone has actually doen the test to prove me right. Or wrong as the case may be ;-) River~~ 
|
 Send message Joined: 18 Sep 04 Posts: 30 Credit: 104,162 RAC: 0 |
This topic seems to get asked over and over again .. the "64-bitness" refers to integer functions... AMD64's "64-bitness" is just part of its story. It provides twice the number of both integer and floating-point registers. And it defaults to the more efficient 16 SSE registers, instead of the cumbersome 8-entry x87 stack. SPEC CPU2000 uses sixtrack as a benchmark and the evidence that its faster as an AMD64 application than as a x86 application is that everyone has submitted peak results for 64-bit OS'es running it as an AMD64 application (see this), even if one or another benchmark was run as a x86 application in such submissions. HTH 
|
|
Send message Joined: 18 Sep 04 Posts: 30 Credit: 104,162 RAC: 0 |
What I am not clear on, is if you have a 64 bit machine running 32 bit code in backwards compatibility mode, then presumably the hardware can still give you those advantages anyway -- any hardware geniuses care to comment? Processors supporting AMD64 are newer ones and they have improvements that benefit most applications regardless of their "bitness". However, AMD64 is more than a mere change in the "bitness", it's a new extension to the x86 instruction set, making it more powerful and flexible. And in order to take advantage of this extended x86 instruction set, known as AMD64, programs have to be recompiled for it. HTH
|
|
Send message Joined: 13 Jul 05 Posts: 456 Credit: 75,142 RAC: 0 |
... it does. Thanks R~~ |
|
Send message Joined: 29 Sep 04 Posts: 196 Credit: 207,040 RAC: 0 |
However, as I understand it, a 64 bit machine still gives you faster fetching of program code (8 bytes at a time instead of 4) and faster fetch and store of those douple precision floats that sixtrack so loves. In other words it is the wider bus between RAM and cache that makes the most useful difference to sixtrack. I'd put my money on it being a key architectural enhancement between generations of CPUs. A wider bus would be software independent. Just like Intel's Macro-Op fusion in Core2 products: The tech is bit & software independent and allows certain instructions to be paired and executed simultaneously in 32 or 64 mode. Pentium M didn't have that tech. 
|
|
Send message Joined: 18 Sep 04 Posts: 30 Credit: 104,162 RAC: 0 |
I'd put my money on it being a key architectural enhancement between generations of CPUs. A wider bus would be software independent. Only neither AMD nor Intel processors which support AMD64 have a wider memory interface or fetch any more bytes at a time than their predecessors.
|
|
Send message Joined: 29 Sep 04 Posts: 196 Credit: 207,040 RAC: 0 |
Good point. And unfortunately it appears from what I've read that sixtrack wouldn't be well suited for GPU (Stream) processing either - for the same reason why it doesn't use MMX or SSEx. The memory interface on the latest RD600 ATI chips is 512-bit on GDDR4 @2GHZ - the amount of lookups it can do in a second is astounding. nVidia will be behind once those chips end up on the shelf to buy (384-bit memory interface) .. for a few months at least. Competition is splendid. :)
|
|
Send message Joined: 13 Jul 05 Posts: 456 Credit: 75,142 RAC: 0 |
Only neither AMD nor Intel processors which support AMD64 have a wider memory interface or fetch any more bytes at a time than their predecessors. Showing my ignorance here, but: Presumably the immediate predecessors already fetch 64 bits at a time then? Including doing this for integers and for fetching prog code? R~~ |
|
Send message Joined: 18 Sep 04 Posts: 30 Credit: 104,162 RAC: 0 |
Presumably the immediate predecessors already fetch 64 bits at a time then? Including doing this for integers and for fetching prog code? Modern processors fetch chunks at a time, whether it started as a byte or more. The chunk size is that of the cache line, typically 64 or 128 bytes. Previous and current models have a 64 or 128-byte memory interface, the wider being better performance-wise. HTH
|
|
Send message Joined: 18 Sep 04 Posts: 30 Credit: 104,162 RAC: 0 |
So far, two projects have added support for x86-64: SETI sends the x86 application and SIMAP, a true x86-64 application. Would you consider supporting the platform x86_64-pc-linux-gnu or x86_64-unknown-linux-gnu similarly? Yay! Malaria now supports AMD64 on Linux with a 32-bit application too.
|
|
Send message Joined: 18 Sep 04 Posts: 30 Credit: 104,162 RAC: 0 |
So far, two projects have added support for x86-64: SETI sends the x86 application and SIMAP, a true x86-64 application. Would you consider supporting the platform x86_64-pc-linux-gnu or x86_64-unknown-linux-gnu similarly? ABC ß now provides a 64-bit application for AMD64 on Linux yielding double the performance.
|
 Send message Joined: 14 Jul 05 Posts: 275 Credit: 49,291 RAC: 0 
|
ABC now provides a 64-bit application for AMD64 on Linux yielding double the performance. Thanks for the spam without removing all previous quotes >:| But seriously, double performance? That's great! I don't quite agree with projects having a 64-bit platform with the 32-bit application, there should be instead logic on the core client (and/or server) to use 32-bit platform automatically if 64-bit is not found. |
|
Send message Joined: 18 Sep 04 Posts: 30 Credit: 104,162 RAC: 0 |
But seriously, double performance? That's great! Yep, double, but triple the performance has also been observed (see this and this). I agree that the client or the server should automatically send the 32-bit application and I suggested it to the BOINC developers a long time ago (see this). Until then, it's up to the developers to either port the application to 64 bits or have the 32-bit application be sent to such clients instead.
|
 LiborASend message Joined: 8 Dec 05 Posts: 1 Credit: 6,691 RAC: 0 |
In short, not for LHC@Home. Sixtrack does not stand to benefit from "64-bit" technologies at this time. For reasons why, see this thread. Yes, thats true but a lot of people have 64b core cient a their amount will be boost. If these people can move into LHC they must use app_info.xml now. Some projects (see Augistine's list) use native 32b application for platform x86_64. Whats the problem duplicate linux application and setup servers for x86_64-unknown-linux-gnu and x86_64-pc-linux-gnu paltform support? |
|
Send message Joined: 18 Sep 04 Posts: 30 Credit: 104,162 RAC: 0 |
So far, two projects have added support for x86-64: SETI sends the x86 application and SIMAP, a true x86-64 application. Would you consider supporting the platform x86_64-pc-linux-gnu or x86_64-unknown-linux-gnu similarly? Docking just added support for AMD64 Linux clients through a 32-bit application for the time being.
|
|
Send message Joined: 29 Sep 04 Posts: 196 Credit: 207,040 RAC: 0 |
It's good that projects who can benefit from it are. The only benefit that I still see for sixtrack is if it were a 64-bit binary it would only make it "native" so to speak for 64-bit OSes. Performance in sixtrack is dependent on floating point ops and those are way beyond 64-bit calculations. I'd venture to guess perhaps a -2% - +2% change in speed for sixtrack as 64-bit. Any change would be minor. However, if a reliable way for sixtrack to use SSE instrucitons were to be found, there could be significant speed increases. Oh well.. another battered topic. :)
|
|
Send message Joined: 18 Sep 04 Posts: 30 Credit: 104,162 RAC: 0 |
It's good that projects who can benefit from it are. The only benefit that I still see for sixtrack is if it were a 64-bit binary it would only make it "native" so to speak for 64-bit OSes. Performance in sixtrack is dependent on floating point ops and those are way beyond 64-bit calculations. There's more to x86-64 than 64-bit intergers. There are many other improvements that offer potential for improved performance of several applications. I'd venture to guess perhaps a -2% - +2% change in speed for sixtrack as 64-bit. Any change would be minor. sixtrack is used in the SPEC2000 suite and submissions made by Intel point to an improvement of 5% using the 64-bit compiler over using the same 32-bit compiler. To put this figure in perspective, typically a 3% improvement is the same as upgrading a processor to the next higher speed grade. It'd be as though LHC gained processors almost 2 speed grades better! ;-) HTH
|
|
Alex Send message Joined: 2 Sep 04 Posts: 378 Credit: 10,765 RAC: 0 |
There's been several discussions on the differences between floating point results between machines. http://frs.web.cern.ch/frs/report/computer_error.pdf Basically, even with floating point processors which meet the iee754 spec, you can get different results, losing 5 decimal points of precision in only 1000 turns of the simulation. (see page 7 of the pdf) another good thread was http://lhcathome.cern.ch/forum_thread.php?id=908 Which discussed homogeneous redundancy. I'm not the LHC Alex. Just a number cruncher like everyone else here. |
|
Send message Joined: 18 Sep 04 Posts: 30 Credit: 104,162 RAC: 0 |
So far, two projects have added support for x86-64: SETI sends the x86 application and SIMAP, a true x86-64 application. Would you consider supporting the platform x86_64-pc-linux-gnu or x86_64-unknown-linux-gnu similarly? RieselSieve is yet another project supporting AMD64 Linux clients by sending the 32-bit application.
|
|
Send message Joined: 18 Sep 04 Posts: 30 Credit: 104,162 RAC: 0 |
So far, two projects have added support for x86-64: SETI sends the x86 application and SIMAP, a true x86-64 application. Would you consider supporting the platform x86_64-pc-linux-gnu or x86_64-unknown-linux-gnu similarly? RieselSieve supports AMD64 Windows clients by sending the 32-bit application too.
|
©2024 CERN