Message boards :
Number crunching :
AMD´S OR INTEL´S ???
Message board moderation
Author | Message |
---|---|
Chilean Send message Joined: 6 Apr 03 Posts: 498 Credit: 3,200,504 RAC: 0 |
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 |
Hans Dorn Send message Joined: 3 Apr 99 Posts: 2262 Credit: 26,448,570 RAC: 0 |
> 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 |
Chilean Send message Joined: 6 Apr 03 Posts: 498 Credit: 3,200,504 RAC: 0 |
> > 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 :) |
Arm Send message Joined: 12 Sep 03 Posts: 308 Credit: 15,584,777 RAC: 0 |
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. |
Marco Niese Send message Joined: 21 May 99 Posts: 11 Credit: 4,238 RAC: 0 |
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"> |
Divide Overflow Send message Joined: 3 Apr 99 Posts: 365 Credit: 131,684 RAC: 0 |
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! |
bjacke Send message Joined: 14 Apr 02 Posts: 346 Credit: 13,761 RAC: 0 |
> 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) |
Marco Niese Send message Joined: 21 May 99 Posts: 11 Credit: 4,238 RAC: 0 |
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"> |
Benher Send message Joined: 25 Jul 99 Posts: 517 Credit: 465,152 RAC: 0 |
> 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. |
Divide Overflow Send message Joined: 3 Apr 99 Posts: 365 Credit: 131,684 RAC: 0 |
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! ;) |
©2024 University of California
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.