Has the 64bit boinc been finished yet???? I tryed to search for the thread but couldn't find it
[url=http://usa.duane-n-lisa.net]

Boinc does not do any number crunching, it's the application.
64 bit Boinc will not help, what you need is Seti or the other app. to be 64 bit.
My 2 cents
Fred BOINC Alpha & BOINC Beta Tester

Perhaps this is the thread you were looking for. There have been no new posts in quite some time though.

http://setiweb.ssl.berkeley.edu/forum_thread.php?id=2913

> Perhaps this is the thread you were looking for. There have been no new posts
> in quite some time though.

I think one of the major players in that effort is on sick leave while he gets surgery for his back ...

But, the 64-bit movement is alive and well and looking at all of the potential optimizations that may come down in time ...

I posed some questions to the optimizations mailing list and got this in reply:

Ben,

Just asking questions as I am not sure I understand the issues here ... :)

a) this effort's end result would be optimized code for execution on the participant's side, correct?
    The questions I was answering were related to your optimization options.  For the optimization GROUP and mailing list...yes...that is the ultimate goal. 
    Identical scientific results, but calculated faster.

 b) If that is true, could we modify the executable delivery system so that we could deliver the correct optimized science application? 

    If we do, and this has been discussed, then we would have to keep a very large number of build versions available for the dispatch server to download to clients.

c) if that is true, could the compile process be modified so that multiple builds are created as part of the build process?
    Each release of code would rerquire a rebuild of all these versions of clients (and presumably adequate testing of each). 
d) with these changes that would allow the most aggressive optimizations for each class of processor, correct?
    If we went down that path...yes. 

 e) with some of the work I thought I read about here, there is also the idea of using arrays of modules so that at run time the "best" tailored version can be used on the computer. Is that not possible for this instance also? 

   The current idea, and Eric correct me if I'm wrong, is to have the same number of worker clients for current platforms...BUT...

   at runtime, on each client, to determine what speed features that system has (which code has been written for) which will improve the computation speed.

   (Example: SIMD instructions, Enhanced FPU, maybe even Graphics Processor (GPU))

   The client would have several differently named functions, one for each possible speed enhancement.

   If the feature was present, the enhanced routine would be called instead of the generic routine.

 

So the overall code would not be compiled for CPU specific, just the individual functions. 

And only those functions that eat up most of the CPU time would have other versions written.

It won't really speed up the operation of the seti worker if the code for "printf" is compiled for G4 or G5, because the code hardly prints anything at all...

but improving the Fast Fourier routines (where the code spends more than 50% of its time) would see a benefit. 

I know that the MacNN team has builds available that seem to be compiled for various versions of the G-4/G-5 family (though the one I ran as one test did not seem to give me any advantage with the Mac I own ... of course I was only running the science application and not the BOINC Work Manager with optimized compilation. 

Maybe you could check and report to the group any speed improvement of the Altivec version by Brad Anderson at  http://www.djbradanderson.com/global/seti.php.

There is also a FFTW version by Eric Heien http://setiathome.berkeley.edu/~eheien/fftw3_code.tar.gz.


 =Ben 

At the moment it looks like we are getting proggress, but the end goal is actually to have every one using the best code for the processor in the system. I know for the Macintosh there are several versions available for the G4 and G5, the one *I* tried did not seem to give me any increase in speed, so I don't know if I did something wrong, I use the system too heavily and that screws up the functioning ...

But to be honest, right now I will take just working ... and it you are using the windows on one of the compatible microprocessors you should be able to run in 32-bit emulation mode... not as fast, but that will come along in due time ...
<p>
For BOINC Documentaion: Click Me!

Thanks paul for the info
[url=http://usa.duane-n-lisa.net]

But Girls and Boys-64 bit is not -faster- it s only more stability the Program if the code are good ;-)
Machmal sind kleine aber durchdachte und verstandene Schritte die bessere Wahl.Guidos Boinc Forum

Sure, then we went to 32bits from 16bits and to 16bits from 8bits to have more stable Programs? Don't be fool. New 64bits instructions give more performance, something like MMX, SSE, SSE2 ... plus when you have 64bits operating system you may easy and direct address 4GB of memory which makes things run faster. Just an example, correct me when I'm wrong.
But right, it is not 2 times faster ten 32bits, as a lot of people thing.
At the end: todays 64bits Windows XP are less stable then 32bits version. ;o)))

> But Girls and Boys-64 bit is not -faster- it s only more stability the Program
> if the code are good ;-)
> Machmal sind kleine aber durchdachte
> und verstandene Schritte die bessere Wahl.Guidos Boinc Forum

@slavko.sk
At the end: todays 64bits Windows XP are less stable then 32bits version. ;o)))....
this is right if you are the CEO of a WINDOWS Factory
but i think ,when i think 64 BIT Software UNIX not Linux not Seattle !
Machmal sind kleine aber durchdachte und verstandene Schritte die bessere Wahl.Guidos Boinc Forum

I'm "=Ben" and this message has my approval.

Virtually all of the current seti client code is centered around 32 bit floating point numbers. (integer = 0,1,2,3,4 ; floating = 4.284, 3.1415, 924.283)

There already exist 64 bit floating point numbers (called doubles) for 32 bit machines, but seti code isn't using them.

We might, in theory, get more accurate results if seti used 64 bit doubles but it wouldn't be any faster.

Right now, on 6x86 machines (AMD, Intel, Transmeta, etc.) the floating point processor internally uses 80 bit floating point numbers for regular float calculations, whether single or double. When the CPU stores the values in memory, it then abbreviates the number to 64 or 32 bits. So the code is "partially" using 80 bit currently.

SIMD (Simultanous Instructions with Multiple Data) floating point:

3Dnow is 2 x 32 bit floats all calculated at once.
SSE is 4 x 32 bit floats all calculated at once.
SSE2 is 2 x 64 bit floats all calculated at once.

For SSE or SSE2 both are stored in a 128 bit register.

On Athlon 64 CPUS, SSE still are only 128 bit registers and so can still only handle same number of single or double floats. Granted on Athlon 64 there are more registers (16 registers vs 8), but the same sized registers.

Any CPU speed boosts would not be improved by larger 64 bit regular CPU registers (for SETI at least). If you watch, the code only uses about 14-17Meg of RAM, and so no benefit in being able to address more than 4 GIG of RAM.

=Ben