Are these SETI work units not being crunched with 64-bits? I installed
Seti-enhanced from FreeBSD ports running a pure 64-bit system (I dropped make with LIB32=true) etc..

The reason I ask is that 'lapack' is doing 5x the mathematical computations in less time than it takes to crunch the numbers in SETI.
(I'm not even using the GUI) If SETI is runnung computations in pure
64-bit, than something must be wrong on my end.

Thanks in advance.

There are not so much difference in speed between i386 and x64 for S@H computations. Maybe +-2%, so it's minimal...

---

There are not so much difference in speed between i386 and x64 for S@H computations. Maybe +-2%, so it's minimal...

I beg to differ...When it comes to math / video editing etc..X64 blows X86 out of the water.

If you want to check out real benchmarks install lapack & run the 'same' computations on X86 and X64.. I think you would be surprised. :-)

There are not so much difference in speed between i386 and x64 for S@H computations. Maybe +-2%, so it's minimal...

I beg to differ...When it comes to math / video editing etc..X64 blows X86 out of the water.

If you want to check out real benchmarks install lapack & run the 'same' computations on X86 and X64.. I think you would be surprised. :-)

It depends on what type of math work you're doing. For SETI@Home, it is primarily floating point math, which on all x87 CPUs is already 80bit. The 64bit software is mainly referring to the ALU which was 32bit paired with 80bit FPUs.

You might want to research what you're talking about before begging to differ. :)

---

There are not so much difference in speed between i386 and x64 for S@H computations. Maybe +-2%, so it's minimal...

I beg to differ...When it comes to math / video editing etc..X64 blows X86 out of the water.

If you want to check out real benchmarks install lapack & run the 'same' computations on X86 and X64.. I think you would be surprised. :-)

It depends on what type of math work you're doing. For SETI@Home, it is primarily floating point math, which on all x87 CPUs is already 80bit. The 64bit software is mainly referring to the ALU which was 32bit paired with 80bit FPUs.

You might want to research what you're talking about before begging to differ. :)

You must have ignored my first question .i.e. the topic of of this post. Some of us use real math in real world situations a la metlab, maple, lapack and linpack. I can only tell you what I see. what I see is X64 running computations almost twice as fast as x86. If these BOINC programs aren't taking full advantage of this, than that would be there lose,Yes?

Sorry if English is bad...

There are not so much difference in speed between i386 and x64 for S@H computations. Maybe +-2%, so it's minimal...

I beg to differ...When it comes to math / video editing etc..X64 blows X86 out of the water.

If you want to check out real benchmarks install lapack & run the 'same' computations on X86 and X64.. I think you would be surprised. :-)

It depends on what type of math work you're doing. For SETI@Home, it is primarily floating point math, which on all x87 CPUs is already 80bit. The 64bit software is mainly referring to the ALU which was 32bit paired with 80bit FPUs.

You might want to research what you're talking about before begging to differ. :)

You must have ignored my first question .i.e. the topic of of this post. Some of us use real math in real world situations a la metlab, maple, lapack and linpack. I can only tell you what I see. what I see is X64 running computations almost twice as fast as x86. If these BOINC programs aren't taking full advantage of this, than that would be there lose,Yes?

Sorry if English is bad...

If you think I ignored your first question, then that means you did not understand the answer. I'll try to explain it again.

64bit speedups depend on the math being used and the dataset being used. 64bit is also referring to the ALU or the Arithmetic Logic Unit, which is the main part of your CPU. Another part of your CPU is the Floating Point Unit, or FPU. The FPU in your CPU is already 80bits, so therefore any apps primarily using the FPU is already using a higher precision accuracy than what 64bit offers in the real world. SETI uses the FPU almost exclusively, therefore SETI is already using 80bit math, which is higher than 64bit. The executable is still 32bit, but it is using 80bit math functions. Compiling the app to 64bit nets no gains because of the dataset being used - and it isn't as simple as using a different dataset just to take advantage of 64bit as not all math needs large datasets, and SETI is one that doesn't need large datasets.

Also, since SETI's application does not need large datasets, using 64bit has actually shown to slow down the performance of the app in real world testing. Because of this, there has been no pressing need to release a 64bit executable.

Do not assume that because other "real world" apps get a speedup that this somehow suggests that all apps will get a speedup is the bottom line of what I'm trying to tell you. There are other BOINC projects that need larger datasets and therefore get a boost from 64bit computing. There are also other BOINC projects that exclusively use the ALU instead of the 80bit FPU, so they also get a speedup from 64bit apps. SETI is neither of those.

In short, your answer is no. SETI is still 32bit and it does not get a performance boost from 64bit apps despite what you see elsewhere.

Does that answer your question yet?

---

There are not so much difference in speed between i386 and x64 for S@H computations. Maybe +-2%, so it's minimal...

I beg to differ...When it comes to math / video editing etc..X64 blows X86 out of the water.

If you want to check out real benchmarks install lapack & run the 'same' computations on X86 and X64.. I think you would be surprised. :-)

It depends on what type of math work you're doing. For SETI@Home, it is primarily floating point math, which on all x87 CPUs is already 80bit. The 64bit software is mainly referring to the ALU which was 32bit paired with 80bit FPUs.

You might want to research what you're talking about before begging to differ. :)

You must have ignored my first question .i.e. the topic of of this post. Some of us use real math in real world situations a la metlab, maple, lapack and linpack. I can only tell you what I see. what I see is X64 running computations almost twice as fast as x86. If these BOINC programs aren't taking full advantage of this, than that would be there lose,Yes?

Sorry if English is bad...

If you think I ignored your first question, then that means you did not understand the answer. I'll try to explain it again.

64bit speedups depend on the math being used and the dataset being used. 64bit is also referring to the ALU or the Arithmetic Logic Unit, which is the main part of your CPU. Another part of your CPU is the Floating Point Unit, or FPU. The FPU in your CPU is already 80bits, so therefore any apps primarily using the FPU is already using a higher precision accuracy than what 64bit offers in the real world. SETI uses the FPU almost exclusively, therefore SETI is already using 80bit math, which is higher than 64bit. The executable is still 32bit, but it is using 80bit math functions. Compiling the app to 64bit nets no gains because of the dataset being used - and it isn't as simple as using a different dataset just to take advantage of 64bit as not all math needs large datasets, and SETI is one that doesn't need large datasets.

Also, since SETI's application does not need large datasets, using 64bit has actually shown to slow down the performance of the app in real world testing. Because of this, there has been no pressing need to release a 64bit executable.

Do not assume that because other "real world" apps get a speedup that this somehow suggests that all apps will get a speedup is the bottom line of what I'm trying to tell you. There are other BOINC projects that need larger datasets and therefore get a boost from 64bit computing. There are also other BOINC projects that exclusively use the ALU instead of the 80bit FPU, so they also get a speedup from 64bit apps. SETI is neither of those.

In short, your answer is no. SETI is still 32bit and it does not get a performance boost from 64bit apps despite what you see elsewhere.

Does that answer your question yet?

Yep, you did answer my question. Sorry to sound like I was going off the rails on the "Crazy Train" OzzFan. I'm new to SETI and this type of (DC) computing.. -;)

Where I work and what I do - It would seem that SETI is uh, how shall we say-- arse backwards.
Why not have a cluster of cpu's brute force one work unit? Why asigin one work unit per-cpu? I guess they have there reasons....

TIA

Yep, you did answer my question. Sorry to sound like I was going off the rails on the "Crazy Train" OzzFan. I'm new to SETI and this type of (DC) computing.. -;)

No problem. :)

Where I work and what I do - It would seem that SETI is uh, how shall we say-- arse backwards.

Not really. It simply depends on the needs of the programmers. I think the larger problem is that too many people assume that more bits means more work done faster, but this isn't always the case.

Why not have a cluster of cpu's brute force one work unit? Why asigin one work unit per-cpu? I guess they have there reasons....

TIA

This is one of the things that is constantly being looked into. There have been many roadblocks, and a shortage of volunteer programmers willing to help the Open Source BOINC & SETI staff. One of the biggest problems is that multi-core is so new that many programmers are still learning how to utilize all the available power in their coding.

It will probably take a long time, but I believe SETI will eventually have mutli-threaded apps where 2, 4, 8 or more CPUs will all be able to work on a single WU together.

---