Phenom vs. Q6600 vs. Q9300 vs. X2 5200+

Nero24

Administrator
Teammitglied
Mitglied seit
01.07.2000
Beiträge
24.066
Renomée
10.445
  • BOINC Pentathlon 2019
  • BOINC Pentathlon 2020
  • BOINC Pentathlon 2018
  • BOINC Pentathlon 2021
Hallo allerseits,

bei den meisten Projekten ist die Hackordnung leider ziemlich deutlich in Richtung Intel festgelegt, oft auch nur aufgrund des verwendeten Intel-Compilers (Einstein) oder aufgrund von SIMD-Optimierungen, die der Phenom nicht hat (SETI Alex-v8 ). Nur bei Riesel Sieve und Spinhenge konnte ich bisher beobachten, dass der Phenom nicht allzu weit von seinen Intel-Gegenspielern weg ist.

Aufgrund des bevorstehenden Races habe ich mich nun logischerweise mit Poem@Home näher beschäftigt und konnte dabei interessantes feststellen was die Berechnungszeiten betrifft. Betrachtet wurden jeweils die WUs, die mit 70,33 Punkten Credit bedacht wurden.

Phenom X4 9850 (Agena 2,5 GHz)
- 11.745,16 s
- 11.613,52 s
- 11.599,28 s
=> Schnitt 11.652,65 s / 29,7 WUs pro Tag

Athlon 64 X2 5200+ (Windsor 2,6 GHz)
- 12.834,53 s
- 12.715,38 s
- 12.706,34 s
=> Schnitt 12.752,08 s / 13,6 WUs pro Tag

Core 2 Quad Q6600 (Kentsfield 2,4 GHz)
- 13.734,45 s
- 13.443,41 s
- 13.637,33 s
=> Schnitt 13.605,06 s / 25,4 WUs pro Tag

Core 2 Quad Q9300 (Yorkfield 2,5 GHz)
- 10.329,45 s
- 10.237,47 s
- 10.412,53 s
=> Schnitt 10.326,48 s / 33,5 WUs pro Tag

Wie man sieht ist das ziemlich ausgeglichen zwischen den Systemen. Es fällt auf, dass der Q9300 ordentlich zugelegt hat gegenüber dem Q6600. Ferner fällt auf, dass der X2 trotz doppelt so großen Caches pro Kern und mehr Taktfrequenz gegenüber dem Phenom den kürzeren zieht, bei der Anzahl der WUs aufgrund der lediglich zwei Kerne sowieso, aber auch bei der Berechnungszeit pro WU. Die Verbesserungen am K10-Kern scheinen also auch hier Wirkung zu zeigen.

In jedem Fall lässt sich festhalten, dass AMD-User bei diesem Projekt nicht mit stumpfen Waffen kämpfen müssen wie bei leider so vielen anderen DC-Projekten :D Außer Acht gelassen wurde hier lediglich das bessere OC-Potenzial der Intel-CPUs. Wenn einer seinen Penryn auf 4 GHz jagt, ist natürlich wieder Ende im Gelände...
 
Hallo allerseits,

bei den meisten Projekten ist die Hackordnung leider ziemlich deutlich in Richtung Intel festgelegt, oft auch nur aufgrund des verwendeten Intel-Compilers (Einstein) oder aufgrund von SIMD-Optimierungen, die der Phenom nicht hat (SETI Alex-v8 ). Nur bei Riesel Sieve und Spinhenge konnte ich bisher beobachten, dass der Phenom nicht allzu weit von seinen Intel-Gegenspielern weg ist.

Kannst du das belegen?
Wenn das stimmen sollte, warum profitieren dann X2 und X4 trotzdem von der optimierten App?
.
EDIT :
.


Core 2 Quad Q9300 (Yorkfield 2,5 GHz)
- 10.329,45 s
- 10.237,47 s
- 10.412,53 s
=> Schnitt 10.326,48 s / 33,5 WUs pro Tag

genau diese Werte erhalte ich bei meinem Q9300 auch, aber bei 3.1GHz.
Meiner Meinung nach profitieren die X2/X4 hier vom IMC bzw. FPU, weniger vom Cache, und von SSE schonmal garnicht, da es nicht (es wurde mal getestet) benutzt wird.
 
Kannst du das belegen?
Wenn das stimmen sollte, warum profitieren dann X2 und X4 trotzdem von der optimierten App?
Nun, für den X2 und X4 gibt's ja auch optimierte SETI-Clients von Alex - nur halt nicht mit SSE4.1 Unterstützung, sondern nur mit SSE3 bzw. SSE2 - mit entsprechend weniger "Gain" gegenüber dem Originalclient ohne SSE-Support.

Bei den Einstein Power-Apps gibt's nur SSE-Support. Daher profitieren die AMD-Clients, die SSE unterstützen (alle seit dem Athlon XP) natürlich ebenfalls davon. Ferner wurden die Einstein Power_Apps auch generell optimiert und zwar bereits auf Sourcecode-Ebene, nicht nur mit SIMD via Compiler-Flag.

Und da der Intel-Compiler, den die meisten "Optimierer" verwenden, generell besser optimiert, als jeder andere Compiler, profitieren die AMD-CPUs davon in bestimmtem Maße ebenfalls, aber natürlich nicht im selben Umfang, wie die Intel-CPUs, auf die der Intel-Compiler in Sachen Architektur voll optimiert. In einer älteren Version des Intel-Compilers wollte Intel dem mal einen Riegel vorschieben und hat AMD-CPUs künstlich eingebremst. Gab dazu auch schon mal einen Thread im DC-Forum. Weiß allerdings nicht, ob das bei den letzten Versionen auch noch der Fall ist.
genau diese Werte erhalte ich bei meinem Q9300 auch, aber bei 3.1GHz.
Meiner Meinung nach profitieren die X2/X4 hier vom IMC bzw. FPU, weniger vom Cache, und von SSE schonmal garnicht, da es nicht (es wurde mal getestet) benutzt wird.
Bei POEM profitiert keine der CPUs von SSE oder sonst einer SIMD-Einheit, da POEM keine davon nutzt und darauf auch noch stolz ist :o
http://boinc.fzk.de/poem/forum_thread.php?id=194
 
Nun, für den X2 und X4 gibt's ja auch optimierte SETI-Clients von Alex - nur halt nicht mit SSE4.1 Unterstützung, sondern nur mit SSE3 bzw. SSE2 - mit entsprechend weniger "Gain" gegenüber dem Originalclient ohne SSE-Support.

Bei den Einstein Power-Apps gibt's nur SSE-Support. Daher profitieren die AMD-Clients, die SSE unterstützen (alle seit dem Athlon XP) natürlich ebenfalls davon. Ferner wurden die Einstein Power_Apps auch generell optimiert und zwar bereits auf Sourcecode-Ebene, nicht nur mit SIMD via Compiler-Flag.

Und da der Intel-Compiler, den die meisten "Optimierer" verwenden, generell besser optimiert, als jeder andere Compiler, profitieren die AMD-CPUs davon in bestimmtem Maße ebenfalls, aber natürlich nicht im selben Umfang, wie die Intel-CPUs, auf die der Intel-Compiler in Sachen Architektur voll optimiert. In einer älteren Version des Intel-Compilers wollte Intel dem mal einen Riegel vorschieben und hat AMD-CPUs künstlich eingebremst. Gab dazu auch schon mal einen Thread im DC-Forum. Weiß allerdings nicht, ob das bei den letzten Versionen auch noch der Fall ist.
Bei POEM profitiert keine der CPUs von SSE oder sonst einer SIMD-Einheit, da POEM keine davon nutzt und darauf auch noch stolz ist :o
http://boinc.fzk.de/poem/forum_thread.php?id=194

das mit Seti ist mir klar, nur eben nicht von Einstein, da du es oben in Klammern in diesem Zusammenhang erwähnt hattest. Daher die Frage gibt es belege dafür das Einstein einen "intelcompiler" verwendet *noahnung*
.
EDIT :
.

Nun, für den X2 und X4 gibt's ja auch optimierte SETI-Clients von Alex - nur halt nicht mit SSE4.1 Unterstützung, sondern nur mit SSE3 bzw. SSE2 - mit entsprechend weniger "Gain" gegenüber dem Originalclient ohne SSE-Support.

Bei den Einstein Power-Apps gibt's nur SSE-Support. Daher profitieren die AMD-Clients, die SSE unterstützen (alle seit dem Athlon XP) natürlich ebenfalls davon. Ferner wurden die Einstein Power_Apps auch generell optimiert und zwar bereits auf Sourcecode-Ebene, nicht nur mit SIMD via Compiler-Flag.

Und da der Intel-Compiler, den die meisten "Optimierer" verwenden, generell besser optimiert, als jeder andere Compiler, profitieren die AMD-CPUs davon in bestimmtem Maße ebenfalls, aber natürlich nicht im selben Umfang, wie die Intel-CPUs, auf die der Intel-Compiler in Sachen Architektur voll optimiert. In einer älteren Version des Intel-Compilers wollte Intel dem mal einen Riegel vorschieben und hat AMD-CPUs künstlich eingebremst. Gab dazu auch schon mal einen Thread im DC-Forum. Weiß allerdings nicht, ob das bei den letzten Versionen auch noch der Fall ist.
Bei POEM profitiert keine der CPUs von SSE oder sonst einer SIMD-Einheit, da POEM keine davon nutzt und darauf auch noch stolz ist :o
http://boinc.fzk.de/poem/forum_thread.php?id=194

So from our perspective this is not a fundamental issue, but just one of priorities: if at some point in this project we have the resources to develop a client version which we can distribute, open source may well be an option (there are some copyright issues etc). However, it seems senseless to initiate such a project if we do not have the resources to integrate the feedback into the project.

schade

wobei ich das nicht verstehe, sie hatten bereits einen test mit SSE laufen, und dieser brachte 50% boost. Vllt waren sie mti dem ergebnissen nicht zufrieden ???
 
das mit Seti ist mir klar, nur eben nicht von Einstein, da du es oben in Klammern in diesem Zusammenhang erwähnt hattest. Daher die Frage gibt es belege dafür das Einstein einen "intelcompiler" verwendet *noahnung*
Puh, da fragst Du mich jetzt was *kopfkratz Ist schon ne Weile her, dass ich mich intensiv mit den Einstein Power_Apps befasst habe. Hab damals auch fast jeden Thread dazu gelesen und war mir jetzt sicher, dass da was von Intel Compiler stand. Ich werde mal sehen, ob ich das Thema nochmal finde...

Edit:
ok, ich hab's gefunden - und trotzdem lag ich falsch. Erst einmal der Grund, weswegen ich davon ausgegangen bin, dass für die Einstein Power_Apps der Intel Compiler verwendet wird: hier wird darüber diskutiert, ob die neue Version wieder AMD-Prozessoren künstlich via CPUID ausbremst:
The App will probably have some CPU vendor detection linked into it (as the 4.26 has), but my guess is that the linear sin/cos code that we're using now isn't affected by this noticeably, so there should be no "penalty" for AMD users. Please try to prove me wrong!
http://einstein.phys.uwm.edu/forum_thread.php?id=6504&nowrap=true#80942
it was discovered that AMD users were "awarded" with a performance penalty due to how compilers treated the string "AuthenticAMD" existing in the science application's executable.
http://einstein.phys.uwm.edu/forum_thread.php?id=6504&nowrap=true#81662
Und noch ein paar anderen Posts mit ähnlichem Inhalt, weshalb ich schlußfolgerte, dass die vom Intel Compiler sprechen, da hier ja bekannt ist, dass einige Versionen AMD-CPUs künstlich die Optimierung verweigern. Siehe hier: http://www.planet3dnow.de/vbulletin/showthread.php?t=336249

Aber ich habe mich getäuscht, denn nach weiterer Recherche fand ich heraus, dass die nicht vom Intel Compiler sprechen, sondern vom MS Compiler:
BOINC is currently bound to the MS compiler, and mixed linking is painful and the results still have their drawbacks. I'd really like to use the Intel compiler for all x86-based platforms, but so far I could get neither BOINC nor our code compiled with these.
http://einstein.phys.uwm.edu/forum_thread.php?id=6446&nowrap=true#79866

Daher ziehe ich meine Aussage zurück und behaupte das Gegenteil ;D ;)
 
Ach ja, bevor ich's vergesse: diese Info wollte ich auch noch loswerden!

AMD Phenom 9600BE mit TLB-Fix => 19.000 s :o
AMD Phenom 9600BE ohne TLB-Fix => 12.500 s :]

(jeweils CASP_169 WUs mit 70,33 Credits)

Lohnt sich also bei einem System, bei dem man den TLB-Fix im BIOS nicht abschalten kann, Musics Artikel genauer zu studieren ;)
http://www.planet3dnow.de/vbulletin/showthread.php?t=330868
 
[...]

Edit:
ok, ich hab's gefunden - und trotzdem lag ich falsch. Erst einmal der Grund, weswegen ich davon ausgegangen bin, dass für die Einstein Power_Apps der Intel Compiler verwendet wird: hier wird darüber diskutiert, ob die neue Version wieder AMD-Prozessoren künstlich via CPUID ausbremst: http://einstein.phys.uwm.edu/forum_thread.php?id=6504&nowrap=true#80942
http://einstein.phys.uwm.edu/forum_thread.php?id=6504&nowrap=true#81662
Und noch ein paar anderen Posts mit ähnlichem Inhalt, weshalb ich schlußfolgerte, dass die vom Intel Compiler sprechen, da hier ja bekannt ist, dass einige Versionen AMD-CPUs künstlich die Optimierung verweigern. Siehe hier: http://www.planet3dnow.de/vbulletin/showthread.php?t=336249

Aber ich habe mich getäuscht, denn nach weiterer Recherche fand ich heraus, dass die nicht vom Intel Compiler sprechen, sondern vom MS Compiler: http://einstein.phys.uwm.edu/forum_thread.php?id=6446&nowrap=true#79866

Daher ziehe ich meine Aussage zurück und behaupte das Gegenteil ;D ;)

vielen dank für deine Nachforschungen ;)
.
EDIT :
.

Ach ja, bevor ich's vergesse: diese Info wollte ich auch noch loswerden!

AMD Phenom 9600BE mit TLB-Fix => 19.000 s :o
AMD Phenom 9600BE ohne TLB-Fix => 12.500 s :]

(jeweils CASP_169 WUs mit 70,33 Credits)

^^ das erinnert an WINRAR, welches ja am verflucht gut IMC und mit Bandbreite/Latenzen super skaliert.
 
Ich probierte zusätzlich den ganged und unganged Modus aus.

Alles auf einem Phenom 9550 @ 2,64 GHz; 880 MHz RAM (laut Memtest); 1940 MHz NB Takt und Linux Ubuntu 64 7.10
ganged: 12351,8 Sec.
unganged: 11436,8 Sec.
macht 7% aus

Phenom Takteffizienz bei Phenom:
2,2 GHz; 800 MHz RAM; 1,9 GHz NB Takt unganged Mode:
13,349.89 Sec.

2,64 GHz usw.
11436,8 Sec.

macht also insgesamt: 14% aus

von 2,2 auf 2,64 GHz ergab eine Takterhöhung von: 17%, verläuft also nicht ganz Linear, aber sieht ansonsten ganz ok aus.

Meine bisherige Kenntnis zusammengefasst:
Für mehr POEM Performance:
*Linux
*unganged Mode (beim Phenom)
*höherer RAM Durchsatz
*höhere Taktrate nur einsetzbar, wenn auch der vorhandene RAM Durchsatz gewährleistet ist, ansonsten bezahlt ihr mehr Strom für nix.
*eventuell noch: (NB-Takt soll L3-Cache beeinflussen?)
*etwas vergessen?
 
hi,

auf welchen boards sitzen der q6600 und der q9300 ?
ich fürchte ich hab mit meinem griff zu diesem teil für einen q9300 eine niete gezogen
http://geizhals.at/deutschland/a298801.html
für eine 169er zeigt er mir um die 21000s an

muss aber auch noch kontrollieren obs kein thermisches problem ist
 
hi,

auf welchen boards sitzen der q6600 und der q9300 ?
ich fürchte ich hab mit meinem griff zu diesem teil für einen q9300 eine niete gezogen
http://geizhals.at/deutschland/a298801.html
für eine 169er zeigt er mir um die 21000s an

muss aber auch noch kontrollieren obs kein thermisches problem ist
Über das Brett (und andere mit low-end nForce) hatte ich auch nachgedacht, habe aber davon abgesehen, da sie wohl kein Dualchannel unterstützen...

Das wäre, beim bandbreitenlastigen POEM ne arge Limitierung und würde die Zeit erklären...
 
Über das Brett (und andere mit low-end nForce) hatte ich auch nachgedacht, habe aber davon abgesehen, da sie wohl kein Dualchannel unterstützen...

Das wäre, beim bandbreitenlastigen POEM ne arge Limitierung und würde die Zeit erklären...

Habe genau das Problem und werde das Board austauschen. Hätte nicht gedacht das Singlechannel soviel ausmacht.
Ein Quadxeon @2,4ghz braucht im Singlechannel genauso lange für eine Wu wie ein T5500 @1,6ghz mit Dualchannel :[
 
Habe genau das Problem und werde das Board austauschen. Hätte nicht gedacht das Singlechannel soviel ausmacht.
Ein Quadxeon @2,4ghz braucht im Singlechannel genauso lange für eine Wu wie ein T5500 @1,6ghz mit Dualchannel :[
das wär ein grund alle cluster-nodes auf dual-channel aufzurüsten ;)
 
So, ich habe das Motherboard getauscht und die Zeit ist von 18k sec. auf 12k sec. gefallen.
Ich denke das hat sich gelohnt :)
 
Wo nach richtet sich eigentlich wie viel Credit man bekommt für die WU?

http://boinc.fzk.de/poem/results.php?hostid=24466

Meine haben nicht 70,33 aber mit im Schnitt von ca 10,500.00 CPU time (sec) denke ich liegt der Rechner im grünen Bereich (100 % CPU Last erlaubt aber keine Optimierungen der Task die sonst noch laufen etc.)

Als Neueinsteiger in diesem Bereich ist es erstmal recht unübersichtlich zu vergleichen ob die Leistungen der Maschinen so weit passen.
 
Es ist wirklich erstaunlich wie gut manche AMDs bei poem abschneiden. Ich hab mal in den statistiken unseres cluster geschaut.
hier mal unser opteron 1212@2,9ghz
chart_uk_bo_object_new_hosts_3923699.gif


ein q6600@3ghz
chart_uk_bo_object_new_hosts_3082169.gif


auch unsere anderen opterons (180 und 170) und phenoms geben sich gegen die Intels nicht geschlagen ;)
 
Q9300@3.2GHz (nicht combined, nur POEM):

chart_uk_poem_object_new_hosts_15269.gif


Q6600@3.2GHz (nicht combined, nur POEM):

chart_uk_poem_object_new_hosts_23438.gif


(ps.: bei den outputlöchern wurde zwischendurch gerieselt :))
 
Zurück
Oben Unten