Any chances for 64-bit seti client for AMD64 ?
(Or even Intel 64?)

---

--
Get up, stand up! Don\'t give up the fight!
Credits will make everybody feel high! ;-)

> Any chances for 64-bit seti client for AMD64 ?
> (Or even Intel 64?)
>
1. You will need to install a 64-bit OS (Linux or Windows XP 64-bit).

2. See if you can compile it yourself.

---

> Any chances for 64-bit seti client for AMD64 ?
> (Or even Intel 64?)
>
The problem is that the AMD 64 is NOT 64 bit in the math processing part of the chip. Meaning that it would not help very much to compile an AMD 64 specific client.

---

> > Any chances for 64-bit seti client for AMD64 ?
> > (Or even Intel 64?)
> >
> The problem is that the AMD 64 is NOT 64 bit in the math processing part of
> the chip. Meaning that it would not help very much to compile an AMD 64
> specific client.
>
The Floating Point Processor Unit carries the same size numbers for 32 bit and 64 bit architectures. I beleive that IEEE specifies 80 bits, but I am not exactly certain.

64 bit refers to the integer registers and databus width.

---

BOINC WIKI

64 Bit Athlon advantages in code...

               32 bit -  64 bit
Int Registers:   8         16
Float Regs:      8          8
SSE SIMD Regs:   8         16

Regular seti doesn't use SIMD regs, so no advantage there.
In addition to the 8 regular registers, Intel/AMD 32 bit both have hidden registers that they use to allow them to perform cpu instructions out of order. Intel P4 has 120 of these, for example.

If compiled for 64 bit, the only advantage would be the extra int registers that the compiler could use to keep values out of RAM longer (and the hidden regs do that now mostly). Also, the compiler might automatically choose to use the SSE Scalar FP regs which are somewhat faster than the x86 "stack based" FP regs.
(SIMD SSE = Using and doing math with 4 FP values at a time with each SSE register
Scalar SSE = Using 1 FP value at a time in each SSE reg)
SIMD: --[ FP ][ FP ][ FP ][ FP ]
Scalar: [ FP ][ -- ][ -- ][ -- ]

> > > Any chances for 64-bit seti client for AMD64 ?
> > > (Or even Intel 64?)
> > >
> > The problem is that the AMD 64 is NOT 64 bit in the math processing part
> of
> > the chip. Meaning that it would not help very much to compile an AMD 64
> > specific client.
> >
> The Floating Point Processor Unit carries the same size numbers for 32 bit and
> 64 bit architectures. I beleive that IEEE specifies 80 bits, but I am not
> exactly certain.

The standard specifies several number types and the original implementations used the "standard" single and double sizes as is, but also had the 80 bit form which almost no one saw outside of the FPU.

Most of the original FPU that did IEEE754 did an internal conversion to 80-bit form and then did the math, then did a conversion back into the single or double forms for output.

In effect they truncated the "noise" at the end of the calculations.

In todays CPUs I no longer know if they still follow that pattern.

In doing quicke search I ran across a neat reference that indicated the last place you saw number anarchy is on Cray computers; which for speed purposes did not do very accurate math, and for those that take offense, rememeber, slide rules and most early math usually only carried forward 3-4 digits of precision.

For even more fun, Norman Agustine did come up with a law for arbitrary precision ... as in it will cost 3.4926 Trillion Dollars ...

---

Hmm...

During recent 64bit WinXP testing, Programs like POV-Ray, Whetstone or Mandelbrot Programs (all pure FPU-heavy) improved by 20% to 40%...

Not sure if the FFT Routine would benefit massively, but there's quite a potential in it (I've read several people are working on SIMD'ing the SETI FFT as we speak).
If they finish, I expect performance improvements anywhere between 40% and 80%.

(the old "hacked" SETI Classic code improved performance on AMD Athlon and K6-2 by almost 100% as far as I remember)

I'll keep an eye on the development, since I already got quite a few 64bit and 64bit-capable Systems running, but indeed so far had no reason to move the x86 64bit'ers to a 64bit OS yet.

---

Since all the infrastructure is in place
(winxp64bit released, both Intel and AMD selling massively 64bit CPUs)
i think its a good time to ask SETI development team:
are you planning to release 64 bit optimized version?
if you are, then when we should expect it?

and another question i have(to the SETI dev team) :
Are you using different SSE instruction sets to optimize the performance?

---

I wonder if my client works for Athlon64. It is not 64bit specific, but optimized with SSE/SSE2 vectorization (not scalar SSE) and linked with fftw library. Will you try one in this thread? (seti-sse2.zip) But before trying, I strongly recommend to make a backup copy of the whole boinc folder in case it crashes and damages your whole data.

On P4s, crunching speed is boosted more than twice. So I hope it will boost Athlon64 also. But I've never tried this one or heard yet.

regards,

---

Luckiest in the world. WMD = Weapon of Mass Distraction.
Click this table.

A note of caution - there are other factors to consider. For example, the compilers don't always produce better code for x86-64. From my linux experiences:

For my Linux clients compiled using gcc, version 3.4 gave small increases for x86-64 whereas gcc4 was way slower (most likely a bug with gcc4) and the 32-bit Athlon XP client is actually faster on 64-bit AMD hardware.

I guess it's just impossible to predict, but on linux so far at best we've only seen relatively small improvements going 64-bit, and at worst 64-bit clients are much slower that their 32-bit couterparts.

Just don't blindly _assume_ that a 64-bit client is automatically going to be faster :)

Ned

---

*** My Guide to Compiling Optimised BOINC and SETI Clients ***
*** Download Optimised BOINC and SETI Clients for Linux Here ***

hmmm....then what's the best way to utilize athlon64? But this is none of my business....sorry :) There are too many architectures and Os'.....

---

Luckiest in the world. WMD = Weapon of Mass Distraction.
Click this table.

Well, for windows users fftw3 will most likely make more difference than just compiling for AMD64, so until a compiler for Windows that can compile fftw3 for AMD64 is available it's all somewhat hyperthetical anyway. All I was trying to illustrate is that there's not automatically huge gains to be had just by going 64-bit - there are many other factors involved - compiler, OS etc :)

---

*** My Guide to Compiling Optimised BOINC and SETI Clients ***
*** Download Optimised BOINC and SETI Clients for Linux Here ***