I was just wondering, why is it that my AMD Athlon processor has a better benchmarking that an Intel Pentium Prossesor that is faster than mine ?

My AMD http://setiweb.ssl.berkeley.edu/show_host_detail.php?hostid=351975

A Random P4 http://setiweb.ssl.berkeley.edu/show_host_detail.php?hostid=353330

My AMD is a 1.8GHz

The Random P4 is 2.40GHz

---

> I was just wondering, why is it that my AMD Athlon processor has a better
> benchmarking that an Intel Pentium Prossesor that is faster than mine ?
>
> My AMD http://setiweb.ssl.berkeley.edu/show_host_detail.php?hostid=351975
>
> A Random P4
> http://setiweb.ssl.berkeley.edu/show_host_detail.php?hostid=353330
>
> My AMD is a 1.8GHz
>
> The Random P4 is 2.40GHz
>

The benchmark code used by boinc runs faster on athlons.
The seti code (mainly large ffts) likes P4s with large chache.

Regards Hans

---

> > I was just wondering, why is it that my AMD Athlon processor has a
> better
> > benchmarking that an Intel Pentium Prossesor that is faster than mine ?
> >
> > My AMD
> http://setiweb.ssl.berkeley.edu/show_host_detail.php?hostid=351975
> >
> > A Random P4
> > http://setiweb.ssl.berkeley.edu/show_host_detail.php?hostid=353330
> >
> > My AMD is a 1.8GHz
> >
> > The Random P4 is 2.40GHz
> >
>
> The benchmark code used by boinc runs faster on athlons.
> The seti code (mainly large ffts) likes P4s with large chache.
>
> Regards Hans
>

Thats what I was thinking while i was posting this thread, but i just wanted to make sure :)

Thanks :)

---

Generally the code runs equal on both AMD and P4. Your example, MiniZiper, is not very good because you're comparing P4 on Linux with AMD on Windows - Linux code is slower. Additionally, obviously, this P4 is with HT enabled, which means that you'll have to double the scores from the benchmark. Better it is seen here
Greetings.

---

On SourceForge SetiBOINC there appears to be a project to improve the client for specific processors. When this comes to fruition, numbers may change.

PS
I remember way back when people complained about faster FFTs being available (and even hacked 'fast' clients themselves) that the project admins didn't want to include that in the official client because of the science integrity.

---

- Marco
<a href="http://setiweb.ssl.berkeley.edu/team_display.php?teamid=36971">Team #LuckyStar</a>

<img src="http://www.boincstats.com/stats/banner.php?cpid=e3c78d10c4cf326b67e1210e1db0ce55">

I certainly hope that the sourceforge group (or anyone else) is making use of the quality CPU optimized FFT's that have been available for a long time now. For instance, AMD has several versions of FFT code in their free Core Math Library package that is optimized on a range from the early Athlons to the latest Athlon64s. Since most of what Seti does is FFT calculation, I'm sure that it would make a significant performance impact if integrated properly. I don't think that such code from the CPU manufacturer should be in too much question for scientific integrity!

---

> I certainly hope that the sourceforge group (or anyone else) is making use of
> the quality CPU optimized FFT's that have been available for a long time now.
> For instance, AMD has several versions of FFT code in their free Core Math
> Library package that is optimized on a range from the early Athlons to the
> latest Athlon64s. Since most of what Seti does is FFT calculation, I'm sure
> that it would make a significant performance impact if integrated properly. I
> don't think that such code from the CPU manufacturer should be in too much
> question for scientific integrity!
>

Yes, I completly agree with you!

---

WARR - Wissenschaftliche Arbeitsgemeinschaft für Raketentechnik und Raumfahrt
(WARR - scientific working group for rocket technology and space travel)

I noticed one of the project admins on SourceForge is Eric J. Korpela ;c)

---

- Marco
<a href="http://setiweb.ssl.berkeley.edu/team_display.php?teamid=36971">Team #LuckyStar</a>

<img src="http://www.boincstats.com/stats/banner.php?cpid=e3c78d10c4cf326b67e1210e1db0ce55">

> I certainly hope that the sourceforge group (or anyone else) is making use of
> the quality CPU optimized FFT's that have been available for a long time now.
> For instance, AMD has several versions of FFT code in their free Core Math
> Library package that is optimized on a range from the early Athlons to the
> latest Athlon64s. Since most of what Seti does is FFT calculation, I'm sure
> that it would make a significant performance impact if integrated properly. I
> don't think that such code from the CPU manufacturer should be in too much
> question for scientific integrity!

Before code is accepted, it must be run on a seti test WU, and compare to a know good result file, with the same tolerances allowed by the validator for all current WUs.

Haven't run a side by side yet, but I think the FFT in setiboinc might be faster than FFTW3. They have done benchmarks of all the FFT packages out there, including Intel's and I believe AMD's. The setiboinc one is a SIMD version of Oourda's (the FFT code used by regular seti_4.08), and Oourda did fairly well as straight C code against FFTW3.

Eric wants to fit all the SIMD code into a C++ "SIMD" class he's been working on.

Very interesting news, Benher, thanks for the info.


> Eric wants to fit all the SIMD code into a C++ "SIMD" class he's been working
> on.

If he's offering a distance learning section perhaps I'll try to audit! ;)

---