He has tried only one project, which gave 7 % on one special CPU...
In short, the benefits of compiling it in 64 bit depends strongly on the used platform and the source.
SETI gave improvements from 5 to 15 % if it was compiled on 64 bit on some platforms. Other platforms runs slower with 64 bits.
Also same on SIMAP, there was a improvement from 5 to 15 %, but there was some platforms, which ran 20 % slower in 64 bit.

The first program I remember advertising SMP features was 3D Studio MAX back in... 1996? Kinetix. That was 10 years ago!

Ah, happy days.

I'd hate to rehash this. However, I would really like to know if WCG can configure their server to send the 32bit app for a client that reports x86_64-pc-linux-gnu. The 32bit app should run just fine on 64-bit OSes and several projects are currently doing this.

You don't have to recompile your applications. It shouldn't take much work at all. It would be a great help to users who DO want to use 64-bit clients. On ABC@Home, their 64bit app gives a 200% increase in speed:

"15 January, 2007
Linux people with a 64bit cpu, please test the x64 application. The first result of 32bit vs. 64bit is impressive: an amd64 3500+ is twice as fast as an intel core 2 duo using the 32bit application. "

That's straight from the ABC@Home Beta site where they did the tests. This is because ABC@Home uses integer calculations which ARE 64-bit and they are working with massive integers that have to be massaged to fit in a 32-bit register but fit just fine in a 64-bit register. Many projects use floating point calculations which won't benefit this much from 64-bit.

However, look at it this way. Even if WCG doesn't benefit directly from sending out 32-bit clients or if someday you support 64-bit natively and you only get a small performance increase, you are HELPING other projects and science in general. There are users like myself who are holding back from using 64-bit clients just because some of their other favorite projects do not support these clients in any way at all. In this way, it's actually hurting the projects that have come after all of the other because users don't want to give up other projects to help increase the power of projects like ABC.

Please understand I'm not asking for a new 64-bit app. I'm just asking if you can configure the server to send 32-bit apps out to 64-bit clients. Please help make a difference for all science. Thanks.

- John Watzke

Actually, there are no hacks or mods needed for Linux. A plain vanilla compile (no crazy optimizations) of the boinc client on a 64bit platform with the recommended compile flags from BOINC (http://boinc.berkeley.edu/compile_client.php) and using --build=x86_64-pc-linux-gnu for the machine type creates a client that works just fine with 32-bit apps I compiled this way on my AMD64 machine and it runs 32bit clients. The only thing needed is to get projects to hand back a 32bit apps to a system reporting as "x86_64-pc-linux-gnu" at least until they start handing out 64bit apps. It's sad for now that I don't have many projects that do that. Riesel Sieve has started doing this so that's added that project back to my list.

Some projects feel uneasy about the 64bit clients. I can understand that. And I'm hoping that BOINC will start releasing official 64bit builds soon to ease those concerns. Of course, it also may not seem worth it to the BOINC team to release official clients if someone downloads it only to find they can't crunch much using it. I'm trying to get the ball moving with enough projects that I can convince David and Rom that official 64bit clients are now more worthwhile.

- John Watzke

Hi s060319,

Lets look behind the scene at what is going on. The 32-bit server code is being rewritten into 64-bit code to allow the servers to run with larger memories. One project (Help Cure Muscular Dystrophy) is being run to validate the science, so it has only been compiled for one platform (UD Windows). The other 4 projects are being maintained for 5 platforms - UD Windows, BOINC Windows, Linux x86, Mac PPC and Mac x86. HPF2 has not been validated and released yet for all platforms, but all the platform versions have been compiled and have made test runs. So that is 21 versions in all. BOINC has been changing its throttle code, so Rick has been working away changing the BOINC throttle code inside the versions right in lockstep. It is a judgment call how much testing for each change should be made before releasing it. A few days ago we had to hastily revert to an earlier version for some projects when the latest version caused problems for some people. He continues to revise the I/O routine for Genome Comparison trying to minimize activity. Help Defeat Cancer is doing well, as you can see on the updates at their site ( http://pleiad.umdnj.edu/IBM/ ) so they are preparing some more filters for additional cancer research. The preliminary runs have turned up some bugs that did not affect the earlier filters so we have some changes and tests to run before releasing the new HDC code to run the next set of samples with.

Meanwhile, people keep reporting problems on their systems and some of these reports result in test runs on the official test computers to see if they can replicate the problems. Often they cannot. Meanwhile, the project scientists have not been standing still. Dr. Garrett Morris has been continuously evolving and improving AutoDock and we are considering scheduling time to adopt the latest version of AutoDock for Fight AIDS At Home, which would mean (yes, you guessed it) major testing for 5 versions.

Nobody has said anything officially about 64-bit Linux or adapting the servers to send 32-bit versions to 64-bit Linux systems. The issue has been raised here in this thread. But there is a lot going on and children keep growing bigger at home while their parents are off working on the Grid.

So - maybe something will happen soon in this area and maybe it won't. It all depends on the perceived benefit versus the estimated work required to make it happen. But with 21 versions of 5 different projects to maintain, there is always a large backlog of work to do.

Lawrence