64-bit science apps based on Rev-2.2B code released

[Simon]

Hi,

shortly after the 32-Bit Linux app release, here are some 64-bit science apps based on the same code.

They were ported to 64-bit Linux by Crunch3r and have produced reliable and accurate results in all tests.

Performance is better than the equivalent 32-bit apps on Intel systems, on AMD systems it's not as clear; some assembly may be required.

Nota bene - Requirements

• 64-bit Linux 2.6.x - sorry, no 2.4 supported.[/b]
• glibc 2.3.4 or newer - find out what version yours is by typing "/lib/libc.so.6" on a new line - as if you were trying to execute the library itself, that will show you details about your installed glibc version.[/b]
• 64-bit BOINC client - caution: this will limit your choice of other project to participate in at the same time, because not a lot of them offer 64-bit science apps yet.[/b]

64-bit Linux science apps:

SSE2-generic
SSE3-Intel-P4/PD
SSE3-Intel-Core 2

Double the bits, double the fun ;o)
Simon.

[CAPTAIN FUTURE]

The Linux 64-Bit apps are faster than the Linux 32-Bit, of course!

The apps are like the old S@H- V5.12 apps from Crunch3r?
That the Linux 64-Bit apps are faster than Windows 32-Bit?

So in future, if you and the optimizer team would like to do... the Windows 64-Bit apps are the fastest available then, or?

Greetings!

[Fivestar Crashtest]

Sooo, since I have a pretty big cache, I wonder if anyone has had any experience switching BOINC from 32 to 64 bit in midstream?  Does it cause a problem or should I wait until the cache drains out before switching?

I'll set to no new work, but if I could switch everything now with no ill effects, I'll do it!

Pam

[Crunch3r]

Sooo, since I have a pretty big cache, I wonder if anyone has had any experience switching BOINC from 32 to 64 bit in midstream?  Does it cause a problem or should I wait until the cache drains out before switching?

I'll set to no new work, but if I could switch everything now with no ill effects, I'll do it!

Pam

Hi Pam,

you'd be on the safe side to let you cache run dry. So that's what i would do.
You might also consider using a 64 bit boinc client (Agustine) provides one.

HTH

[michael37]

I switched from Seti 32-bit apps to 64-bit apps in midstream and have experienced no ill effects.  As usual with risky configurations, YMMV.    I suspect switching Boincs from i386 to x86_64 architecture may  have ill effects. 

Btw, make sure you test the 64-bit app and convince yourself that it actually runs and produces something before switching midstream and losing all your work 

[Metod, S56RKO]

Nota bene - Requirements

• 64-bit Linux 2.6.x - sorry, no 2.4 supported.
• glibc 2.3.4 or newer - find out what version yours is by typing "/lib/libc.so.6" on a new line - as if you were trying to execute the library itself, that will show you details about your installed glibc version.
• 64-bit BOINC client - caution: this will limit your choice of other project to participate in at the same time, because not a lot of them offer 64-bit science apps yet.

While it's a good idea to have 64-bit BOINC client, this is not really a requirement. I've tested and successfully run 64-bit SAH app with 32-bit BOINC client (I need that for CPDN).

I switched from Seti 32-bit apps to 64-bit apps in midstream and have experienced no ill effects.  As usual with risky configurations, YMMV.    I suspect switching Boincs from i386 to x86_64 architecture may  have ill effects. 

You can change BOINC from i686 to x86_64, but you need to hand-edit the file client_state.xml. Near the end of the file there's tag <platform_name> which needs to match platform name of your BOINC client. If it doesn't, BOINC client will reset all the projects.
Been there, done that ...

[Simon]

Ah, good hint, Metod!

That's happened to me before, as well.
Seems useful to be able to run a 64-bit science app with 32-bit BOINC.

Regards,
Simon.

[Suzuki]

May I first point out that my intense stupidity with Linux is probably more frustrating for you, than me.  Reason for that is that there's good people out there who are so willing to help!  Thanks in advance ...

So, for my next stupid question ...

I had my Linux box (Suse 10) running just fine .. and then managed to break BOINC.  I'm sure I had a previous 64-bit SETI app running on standard BOINC.  But having read a few threads, thought I'd try the 64-bit client too. 

Predictably, I broke it again with the SETI servers telling me that x86--- was not recognised etc.  So I went back to the standard client and copied the 2.2B apps into the relevant folder; which now won't run.  I'm still seeing the standard science app running in the Performance Monitor - and the "aux | grep" thing means nothing to me!

What on earth have I buffooned this time?!  Apart from trashing lord knows how many units!

Does the 64-bit client support SETI (or vice versa) and, if so, how to make it run?  And is there more to switching to the optimised app than just copying the files after stopping BOINC? 

I've done this before, and have no idea what I've cocked up!  As in the SETI threads, I've got a book on order to prevent persistent asking of moronic questions!  Please bear with me!!

Thanks in advance ...

Steve.

[Metod, S56RKO]

Does the 64-bit client support SETI (or vice versa) and, if so, how to make it run?  And is there more to switching to the optimised app than just copying the files after stopping BOINC?

An user named Augustine is quite active in lobbying support for 64-bit Linux in many of projects. He also posts occasionally list of projects that support 64-bit linux as OS platform. Seti is one of them. However, there are a couple of gotcha's:

• Some projects support platform named x86_64-unknown-linux-gnu (Seti being one of them) and some support x86_64-pc-linux-gnu. The later is official name for platform as set by Berkeley. Some of projects that support platform in question do it via 32-bit applications. If the 64-bit linux platform is not supported at all, you may have luck running it and use anonymous platform mechanism (ie. use app_info.xml). I am successful doing so at Einstein@Home, but not at CPDN.
• If you decide to switch platform (eg. from i686 to x86_64), BOINC client will reset all projects the host is attached to. You can avoid this by hand-editing file client_state.xml.

Now, as to your problem: perhaps you are best off starting a new install and (re)attach your box to all projects you want to. Here's what I usually do:

• Install official Berkeley's BOINC client. Then get a 64-bit one and simply copy the executable over the original one. Actually what I do is to create a sym-link named boinc and pointing to the executable I wish to run.
• Start (64-bit) BOINC and attach to projects you wish to participate in. Don't worry about warnings that some projects don't support your platform.
• Stop BOINC client.
• Install proper project scientific executables and pay attention to install also proper version of app_info.xml.Use 64-bit apps for SETI of course. You can get necessary project executables for 32-bit linux by manually downloading them from projects' servers and then construct appropriate app_info.xml.
• Start BOINC client and keep an eye on it for a couple of days to make sure everything is fine.

I hope you'll get it sorted out.

[Suzuki]

That sounds like something I can manage ... I'll give it a whirl and let you know how I get on.

Many thanks for your help.

Steve.

[ohiomike]

I've been trying (with little success) to compile an x64 version from the 32b source. Would it be possible to put the x64 source up here so I don't have to track down all the changes needed? I wanted to try the V10.0.023 version of the icc compiler which is supposed to have improved AMD support via the -xO switch. I realize I have a bunch of icc & ipp refs to change, but if I could get the base to work it would help.
   NI!

[Simon]

Hi Mike,

http://calbe.dw70.de/2.2b/FINAL_2.2B_LINUX_v2_64bit.tar.bz2 <-- Crunch3r's source snapshot that we compiled the 64-bit Linux apps from.

Compiling is really a b...other.

That said, I recommend you use OpenSuSe 10.2 as a compilation platform, since it'll have all the same lib versions, then adjust the ICC and IPP paths.

First, edit MAKE.ICC to reflect your ICC/IPP directories, then run it.

Second, go inside the client/Optimizer subdirectory and use one of the compile_* scripts (after editing for your system paths) to compile the library with the optimized code.

Then, go up one dir to client/ and copy the corresponding Makefile* (you'll see there are a few with recognizable extensions) to "Makefile" (again, after editing them to reflect your paths). Run "make" inside the client directory.

That's it, provided you'll go with OpenSuSe 10.2 (64-bit, obviously). No guarantees with other distros, we tried and there were quite a lot of problems that weren't really reproducible.

As for running the apps, that's different. Compiling works best there with this source package.

I've been lazy and haven't updated the Linux compilation How-To. Yet another to-do

HTH,
Simon.

[Crunch3r]

Hi Mike,

http://calbe.dw70.de/2.2b/FINAL_2.2B_LINUX_v2_64bit.tar.bz2 <-- Crunch3r's source snapshot that we compiled the 64-bit Linux apps from.

Compiling is really a b...other.

That said, I recommend you use OpenSuSe 10.2 as a compilation platform, since it'll have all the same lib versions, then adjust the ICC and IPP paths.

First, edit MAKE.ICC to reflect your ICC/IPP directories, then run it.

Second, go inside the client/Optimizer subdirectory and use one of the compile_* scripts (after editing for your system paths) to compile the library with the optimized code.

Then, go up one dir to client/ and copy the corresponding Makefile* (you'll see there are a few with recognizable extensions) to "Makefile" (again, after editing them to reflect your paths). Run "make" inside the client directory.

That's it, provided you'll go with OpenSuSe 10.2 (64-bit, obviously). No guarantees with other distros, we tried and there were quite a lot of problems that weren't really reproducible.

As for running the apps, that's different. Compiling works best there with this source package.

I've been lazy and haven't updated the Linux compilation How-To. Yet another to-do

HTH,
Simon.

Hehe i've allready send him the link about an hour ago via pm on the SETI board I was faster 

[ohiomike]

Thanks Crunch3R/Simon,
I've had good luck the stock Boinc Client and with the optimized 32b app (icc 9.x) under FC6, so I was going to try that first. I'll let you know how it works.

[KWSN Holy HndGrena]

Sooo, since I have a pretty big cache, I wonder if anyone has had any experience switching BOINC from 32 to 64 bit in midstream?  Does it cause a problem or should I wait until the cache drains out before switching?

I'll set to no new work, but if I could switch everything now with no ill effects, I'll do it!

Pam

Hi Pam,

you'd be on the safe side to let you cache run dry. So that's what i would do.
You might also consider using a 64 bit boinc client (Agustine) provides one.

HTH

In my experience (with  xp and 32-bit...) all you need to do is not switch  apps while  running a WU.  Either let your cache run dry, or  (if you have a sufficiently small number of WU's...) suspend all non-running WU's before makeing the switch.  I'm trying (again, with xp pro and 32 bit...) this last approach with a new installation, that's showing 9 hour times for the stock app (I'll get back to ya on how long the WU's actually take - the client is known for lousy initial estimate times...)