Archiv verlassen und diese Seite im Standarddesign anzeigen : Intel - Ist SuperPI Intel-optimiert?
Schrotti
2010-02-12, 22:07:45
Ist das Benchproggi SuperPI auf Intel CPUs optimiert und wenn ja, wo?
Undertaker
2010-02-12, 22:21:35
Nein. Der Code ist schlicht sehr alt und besteht vor allem aus x87 Befehlen - die seit dem Aufkommen von SSE in ihrer Bedeutung verloren haben und somit speziell bei AMDs Prozessoren kaum noch Verbesserungen in der Ausführungsgeschwindigkeit erfahren haben. SuperPi liefert also durchaus ein neutrales Leistungsbild - allerdings für einen in der heutigen Zeit selten gewordenen Anwendungsfall.
Ja das Teil ist total Intel optimiert .. und zwar auf den Penium1 :freak:
Im Ernst, heute sollte es ziemlich egal sein ;-)
Dieser "Benchmark" ist schon etwas merkwürdig. Vor einigen Tagen feierte man die erste übertaktete AMD-CPU, welche 32M (?!) in weniger als 10 Sekunden abschloss. Die Intels sind schon lange bei 5,9 ...
MfG,
Raff
Dieser "Benchmark" ist schon etwas merkwürdig. Vor einigen Tagen feierte man die erste übertaktete AMD-CPU, welche 32M (?!) in weniger als 10 Sekunden abschloss. Die Intels sind schon lange bei 5,9 ...
MfG,
Raff
1 M, sicher nicht 32 M.
Und was ist daran komisch?
Nein. Der Code ist schlicht sehr alt und besteht vor allem aus x87 Befehlen - die seit dem Aufkommen von SSE in ihrer Bedeutung verloren haben und somit speziell bei AMDs Prozessoren kaum noch Verbesserungen in der Ausführungsgeschwindigkeit erfahren haben. SuperPi liefert also durchaus ein neutrales Leistungsbild - allerdings für einen in der heutigen Zeit selten gewordenen Anwendungsfall.
Leider ist das nicht der Grund. Scalar SSE wäre bei SuperPI auf AMDs auch nicht schneller.
Dieser "Benchmark" ist schon etwas merkwürdig. Vor einigen Tagen feierte man die erste übertaktete AMD-CPU, welche 32M (?!) in weniger als 10 Sekunden abschloss. Die Intels sind schon lange bei 5,9 ...
Da sollte der Loop Detektor daran "Schuld" sein ;-)
Sonyfreak
2010-02-13, 02:22:55
Leider ist das nicht der Grund. Scalar SSE wäre bei SuperPI auf AMDs auch nicht schneller.Was ist sonst der Grund dafür?
mfg.
Sonyfreak
Weiß ich nicht, aber x87 ist es jedenfalls nicht.
Loop Stream Detection bei Intel könnte sein, würde aber voraussetzen, dass bei AMD die Branch Prediction Mist baut oder das ganze Decode-Bandwidth limitiert ist.
Mein Tipp wäre ja eher das intelligentere Prefetching bei den Intel-Chips.
Weiß ich nicht, aber x87 ist es jedenfalls nicht.
Loop Stream Detection bei Intel könnte sein, würde aber voraussetzen, dass bei AMD die Branch Prediction Mist baut oder das ganze Decode-Bandwidth limitiert ist.
Hmm, was hat das mit der Branch Prediction zu tun ?
Der Loop Cache hält die µOps für Schleifen vor, wenn die Schleife da reinpaßt, dann werden die Befehle gleich in die Execution Units geschickt, und man spart sich das ganze x86 Befehlsdecodieren. Nachdem da viel x87 Zeugs vorkommt, werden da sicherlich auch ein paar (mehr?) vector path / complex instructions vorkommen, die bei AMD in jedem Schleifendurchlauf langwierig dekodiert werden müssen.
Oder versteh ich was falsch ?
If a loop is less than 28 uops, then Nehalem can cache it in the LSD and issue into the out-of-order engine without using the instruction fetch unit or the decoders. This saves even more power than the Core 2 when using the LSD, by avoiding the decoders and more loops can be cached. Nehalem’s 28 entry uop buffer can hold the equivalent of about 21-23 x86 macro-instructions based on our measurements from several games. The ratio of macro-ops/uops depends heavily on the workload, but in general Nehalem’s buffer is ‘larger’ than that found in the Core 2. http://www.realworldtech.com/page.cfm?ArticleID=RWT040208182719&p=5
Wie schauts eigentlich bei Linux aus ? Da gibts doch auch Pi Versionen zum selbst compilieren ...
Hmm, was hat das mit der Branch Prediction zu tun ?
Wenn der Loop-Stream-Decoder eine Schleife erkennt wird die Branch-Prediction überstimmt, und der korrekte Sprung vorhergesagt in Fällen in denen die Logik die Counter-Variable erkennt oder ansonsten ein Rücksprung angenommen.
Wenn der Loop-Stream-Decoder eine Schleife erkennt wird die Branch-Prediction überstimmt, und der korrekte Sprung vorhergesagt in Fällen in denen die Logik die Counter-Variable erkennt oder ansonsten ein Rücksprung angenommen.
Ok, aber das hilft AMD selbst im Erfolgsfall nicht, wenn sie jeweils in jeder Schleife vector path Befehle decodieren müssen, und intel bereits die µOps vorhält.
(Hatte das oben gerade noch hinzugefügt).
ciao & gute Nacht
Alex
SuperPI ist ganz sicher Integer-Code, und da ist Intel flotter, außerdem liegt SuperPI die Cache-Hierarchie der Core-Prozessoren. Beim I7 hat die Perf./MHz beim 1M Test ja leicht abgenommen.
das sieht man auch schön an meinem Codec Sac (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=417530), der fast nur x87 ist
da schafft ein Q6600@3Ghz: 126sec, und ein X2@3.2Ghz: 132sec
Undertaker
2010-02-13, 10:52:27
SuperPi ist auch auf dem Nehalem noch etwas schneller pro Takt geworden.
http://www.computerbase.de/artikel/hardware/prozessoren/2008/test_intel_core_i7_920_940_965_extreme_edition/13/#abschnitt_wprime_super_pi_maxxpi
Der i7 940 mit maximal 3,2GHz inkl. Turbo schlägt den E8600 mit 3,33Ghz. Takt- und Zeitdifferenz ergeben knapp 10% mehr Leistung pro Takt.
das liegt imo aber eher am Speicherinterface, da der Abstand bei 32M größer wird
Undertaker
2010-02-13, 11:25:48
Interessanterweise ist Lynnfield mit nur 2 Kanälen aber noch schneller (i5 750 schlägt i7 940, beide 3,2GHz):
http://www.computerbase.de/artikel/hardware/prozessoren/2009/test_intel_core_i5-750_core_i7-860_core_i7-870/12/#abschnitt_wprime_super_pi_maxxpi
An der Speicherbandbreite kann es also nicht liegen... Und Latenz? Die scheint weder bei Nehalem noch bei Lynnfield kürzer als beim Core 2 zu sein:
http://www.computerbase.de/artikel/hardware/prozessoren/2009/test_intel_core_i5-750_core_i7-860_core_i7-870/11/#abschnitt_sisoft_sandra_2009
Avalox
2010-02-13, 11:25:57
Ist denn der Code zu SuperPI überhaupt allgemein bekannt?
Wie ist den SuperPI überhaupt kompiliert worden?
SuperPI ist ganz sicher Integer-Code, und da ist Intel flotter, außerdem liegt SuperPI die Cache-Hierarchie der Core-Prozessoren. Beim I7 hat die Perf./MHz beim 1M Test ja leicht abgenommen.
Hmm Integer Code ... wie soll man denn damit Brüche und Wurzeln darstellen ? Der verwendete Algo ist der hier:
http://de.wikipedia.org/wiki/Gau%C3%9F-Quadratur#Gau.C3.9F-Legendre-Integration
Ausserdem, wenn es nur Integer wäre, müßten die P4s abgehen wie eine Rakete ... tuen sie das ?
Ansonsten ja - Cacheabhängig ist das Teil natürlich auch, je nach gewählter Stellenanzahl. Die K10 CPUs legten v.a. aufgrund des 6MB L3 Caches zu.
Der Effekt ist aber nicht allzugroß, wie man an den i3/i5 Clarkdales sieht:
http://www.hardwarecanucks.com/forum/hardware-canucks-reviews/27315-intel-westmere-32nm-launch-clarkdale-core-i5-661-cpu-review-13.html
(i7 870 und i5 661 sind in dem Bench angeblich beide @3,6 GHz).
Nichtsdestoweniger hat die Bandbreite einen Einfluß, also eventuell liegts am schlechteren AMD Uncore, bzw. auch an den Prefetchern, wie CODA schon mutmaßte.
@Avalox:
Nö das Ding ist closed source, vor Jahr und Tag hab ich mal bei XS ein Posting gesehen, in dem einer meinte, dass das mit nem uralt Visual Studio compiliert wäre, was halt so um 1995 angesagt war.
ciao
Alex
Hmm Integer Code ... wie soll man denn damit Brüche und Wurzeln darstellen ?
fixed Point?
Der verwendete Algo ist der hier:
http://de.wikipedia.org/wiki/Gau%C3%9F-Quadratur#Gau.C3.9F-Legendre-Integration
wie kommst du darauf?
wie kommst du darauf?
Steht bei wikipedia.de im Super Pi Eintrag und ich habs auch schon woanders mal gelesen, sollte stimmen.
Ansonsten, das hier ist wohl das inoffizielle Nachfolgeprogramm:
http://www.xtremesystems.org/forums/showthread.php?t=221773
Sogar inkl. SSE4.1 Code (hoffentlich Assembler und nicht ICC ^^) :)
Edit:
Doch ICC :(
http://www.numberworld.org/y-cruncher/algorithms.html
ciao
Alex
Undertaker
2010-02-13, 12:00:44
Interessant aber, dass auch das Programm noch merklich besser auf Intel-Systemen performt... Womöglich dann doch ein Zeichen für die bessere Branch Prediction?
Das halte ich aber für ein Gerücht, daß SSE x87 völlig verdrängt hat und demnach das NICHT Nutzen von SSE ein eher seltener Anwendungsfall darstellt.
Wobei der Codec von pest eher den realen Abstand zwischen PhenomII und Intel wiedergibt. Was man dann mit dem Preis für CPU und Board aufwiegt. Das ist die reale Situation.
Interessanterweise ist Lynnfield mit nur 2 Kanälen aber noch schneller (i5 750 schlägt i7 940, beide 3,2GHz):
http://www.computerbase.de/artikel/hardware/prozessoren/2009/test_intel_core_i5-750_core_i7-860_core_i7-870/12/#abschnitt_wprime_super_pi_maxxpi
An der Speicherbandbreite kann es also nicht liegen... Und Latenz? Die scheint weder bei Nehalem noch bei Lynnfield kürzer als beim Core 2 zu sein:
Das liegt aber nur am erweiterten Turbo-Mode.
Der i920 mit aktivem Turbo-mode dürfte real eine Frequenz von ca. 2,8GHz haben und ist damit geringfügig schneller als Lynnfield mit 2,93GHz.
Das halte ich aber für ein Gerücht, daß SSE x87 völlig verdrängt hat und demnach das NICHT Nutzen von SSE ein eher seltener Anwendungsfall darstellt.
Unter Win64 gibt es x87 nicht mehr und es wird ausschließlich SSE verwendet.
Das halte ich aber für ein Gerücht, daß SSE x87 völlig verdrängt hat und demnach das NICHT Nutzen von SSE ein eher seltener Anwendungsfall darstellt.
Wobei der Codec von pest eher den realen Abstand zwischen PhenomII und Intel wiedergibt. Was man dann mit dem Preis für CPU und Board aufwiegt. Das ist die reale Situation.
Klar es gibt jede Menge alte Software die x87 Code benutzt.(SSE2 kann ja nur seit dem Patenttausch zwischen AMD und Intel als Standard angenommen werden)
Neue Software nutzt fast immer SSE2, außer man benötigt das extended float format.
Das ist in SSE so viel ich weiß nicht enthalten.
Unter Win64 gibt es x87 nicht mehr und es wird ausschließlich SSE verwendet.Und was tut unter Win64 eine Soft die mit x87 rechnet?
Und was tut unter Win64 eine Soft die mit x87 rechnet?
Der WOW64-Layer wandelt x87-Befehle in äquivalente SSE-Befehle um.
64bit-Software nutzt von sich aus nur SSE.
Das liegt aber nur am erweiterten Turbo-Mode.
Der i920 mit aktivem Turbo-mode dürfte real eine Frequenz von ca. 2,8GHz haben und ist damit geringfügig schneller als Lynnfield mit 2,93GHz.Ne, 750 und 940 kommen ja angeblich (ich prüf das jetzt nicht nach ^^) auf den gleichen Turbo Takt.
Was am Ende da wieder der Kasus Knacktus ist, ist das RAM Interface. Ein einzelner Thread hat so gut wie nichts vom Triple Channel, was bleibt ist der DR3-1066 zu DDR3-1333 Unterschied, der pro LGA1156 = i5 750 ausfällt.
@obiger Gast:
Da wird nichts umgewandelt, die WoW Schicht leitet die x87 Anfragen einfach weiter. Wäre ansonsten ja auch schön blöde, da extra eine Emulationsschicht einzuführen.
Undertaker
2010-02-13, 13:01:49
Das liegt aber nur am erweiterten Turbo-Mode.
Der i920 mit aktivem Turbo-mode dürfte real eine Frequenz von ca. 2,8GHz haben und ist damit geringfügig schneller als Lynnfield mit 2,93GHz.
Bei reinem Single-Thread hat der i7-920 +2 Turbostufen, also auch 2,93GHz. ;) Trotzdem hast du Recht mit deinem Beispiel, man sollte wohl revidieren, das sich Nehalem und Lynnfield in dieser Anwendung bis auf minimale Schwankungen weitestgehend gar nichts nehmen.
Bei reinem Single-Thread hat der i7-920 +2 Turbostufen, also auch 2,93GHz. ;)
Theoretisch, in der Praxis schlafen aber so gut wie nie 3 Kerne. In der Realität bekommt man maximal 1 Taktstufe mit dem i920, gerade selbst mit SuperPi nachgeprüft.
Trotzdem hast du Recht mit deinem Beispiel, man sollte wohl revidieren, das sich Nehalem und Lynnfield in dieser Anwendung bis auf minimale Schwankungen weitestgehend gar nichts nehmen.
Scheint so, die 3% die der i920 mit Turbo vor dem 2,8GHz Lynnfield liegt sind nicht der Rede wert. Die Werte sind auch generell sehr kurz, weshalb es zweifelhaft ist ob sie überhaupt aussagekräftig sind. Man sollte wohl mehr stellen berechnen, so dass die schnellsten Prozessoren mindestens 1 Minute am Werken sind.
BlackBirdSR
2010-02-13, 13:22:00
@obiger Gast:
Da wird nichts umgewandelt, die WoW Schicht leitet die x87 Anfragen einfach weiter. Wäre ansonsten ja auch schön blöde, da extra eine Emulationsschicht einzuführen.
stimmt genau.. gäbe gar keinen Grund das zu tun.
BTW: Ich habe gerade mal SuperPI durchlaufen lassen.
Bei einem 8-Thread-Prozessor komme ich in Summe ca. auf 20% Auslastung, also deutlich mehr als nur 1 Kern, vom Single-Core-TM kann man sich also verabschieden.
Triskaine
2010-02-13, 13:31:08
Es gibt auch Pi-Programme in denen das ganze etwas ausgeglichener aussieht, so wie hier: http://gmplib.org/pi-with-gmp.html
Dieses OpenSource Programm verwendet einen sehr modernen Algorithmus (http://en.wikipedia.org/wiki/Chudnovsky_algorithm) und ist allen anderen Programmen (bis auf y-cruncher bei extrem großen Werten) bei der Berechnungsgeschwindigkeit um Lichtjahre voraus. Interessanterweise ist hier ein Phenom II clock-for-clock um 18% schneller als ein i7 Nehalem.
In einer älteren Version hat sogar ein K8 mehr Pro-Takt-Leistung als ein Nehalem.:freak: Das zeigt mal wieder das die Geschwindigkeit eines Prozessors in einem enormen Maß von der verwendeten Software abhängt.
AMD's Prozessorarchitektur ist wenn was die reine Rechenpower betrifft immer noch ganz vorne mit dabei. Das zahlt sich vor allem bei Supercomputern aus.
Es gibt auch Pi-Programme in denen das ganze etwas ausgeglichener aussieht, so wie hier: http://gmplib.org/pi-with-gmp.html
Dieses OpenSource Programm verwendet einen sehr modernen Algorithmus (http://en.wikipedia.org/wiki/Chudnovsky_algorithm) und ist allen anderen Programmen (bis auf y-cruncher bei extrem großen Werten) bei der Berechnungsgeschwindigkeit um Lichtjahre voraus. Interessanterweise ist hier ein Phenom II clock-for-clock um 18% schneller als ein i7 Nehalem.
Compilier mal mit ICC; dann ist der Intel sicherlich vorne ;-)
(fairerweise muss man aber noch sagen, dass der K10 mit 3,2 GHz läuft, der i7 nur mit 2,67).
Zum Algo selbst:
Ist bei GMP auch ein 2ter Prüfalgo dabei ? y-Cruncher hat ja auch den Chudovsky Algo aber zur Überprüfung noch den Ramanujans Algo.
ciao
Alex
Vielleicht nicht relevant für diesen Thread, vielleicht doch, ich habe keine Ahnung, aber ich quote trotzdem mal einen Entwickler von PCSX2 (PS2-Emulator):
The instruction set itself matters very little. The fundamental design of the CPU however matters a lot more. Core2 CPUs have better out-of-order instruction execution, better branch prediction, an extra execution unit, and faster execution units in general (especially for SSEs) compared to PhenomII's. The Core2 also has the "Denormals are Zero" optimization, which is a huge speedup for PCSX2 in certain games.
Thus, even without SSE4, the Core2 chips, clock-for-clock, are always much better at running PCSX2 than PhenomII's. (edit: in PhenomII's defense, they tend to come with higher stock clocks -- though tend not to overlock as well either. Man it's hard to defend them right now.)
Triskaine
2010-02-13, 14:11:15
Compilier mal mit ICC; dann ist der Intel sicherlich vorne ;-)
(fairerweise muss man aber noch sagen, dass der K10 mit 3,2 GHz läuft, der i7 nur mit 2,67).
Die 18% sind taktnormiert, ebenso wie der Vergleich K8 vs. Nehalem. Zum ICC erübrigt sich jedweder Kommentar, dieser Haufen stinkt schon seit Jahren zum Himmel.
Vielleicht nicht relevant für diesen Thread, vielleicht doch, ich habe keine Ahnung, aber ich quote trotzdem mal einen Entwickler von PCSX2 (PS2-Emulator):
Zitat:
The instruction set itself matters very little. The fundamental design of the CPU however matters a lot more. Core2 CPUs have better out-of-order instruction execution, better branch prediction, an extra execution unit, and faster execution units in general (especially for SSEs) compared to PhenomII's. The Core2 also has the "Denormals are Zero" optimization, which is a huge speedup for PCSX2 in certain games.
Thus, even without SSE4, the Core2 chips, clock-for-clock, are always much better at running PCSX2 than PhenomII's. (edit: in PhenomII's defense, they tend to come with higher stock clocks -- though tend not to overlock as well either. Man it's hard to defend them right now.)
Das ein Phenom II in diesem Anwendungsfall zurückfällt ist zwar bedauerlich, doch wenn man ein breites Spektrum an Programmen betrachtet, beträgt die clock-for-clock Differenz zu einem Core2 (Yorkfield) weniger als 10%.
(del)
2010-02-13, 14:16:29
Der WOW64-Layer wandelt x87-Befehle in äquivalente SSE-Befehle um.Und das wars auch schon mit dem ah so fundierten Wissen :freak:
Gipsel
2010-02-13, 14:27:26
Vielleicht nicht relevant für diesen Thread, vielleicht doch, ich habe keine Ahnung, aber ich quote trotzdem mal einen Entwickler von PCSX2 (PS2-Emulator):... compared to PhenomII's. The Core2 also has the "Denormals are Zero" optimization, which is a huge speedup for PCSX2 in certain games.Dann sieht es wohl so aus, als hätte der PCSX2-Entwickler keine Ahnung, wovon er redet. Das kann praktisch jede SSE2-fähige CPU, definitiv sogar schon die alten K8 und erst recht die K10/Phenom-CPUs.
Achja, Denormals kosten auf Intels im Schnitt mehr Performance als auf AMDs, deswegen ist diese DAZ/FTZ-Geschichte bei denen etwas wichtiger ;)
BlackBirdSR
2010-02-13, 14:52:28
BTW: Ich habe gerade mal SuperPI durchlaufen lassen.
Bei einem 8-Thread-Prozessor komme ich in Summe ca. auf 20% Auslastung, also deutlich mehr als nur 1 Kern, vom Single-Core-TM kann man sich also verabschieden.
Bedank dich beim Scheduler.
Setze SuperPi mal auf einen beliebigen der 8 Kerne fest und siehe was passiert ;)
Bedank dich beim Scheduler.
Setze SuperPi mal auf einen beliebigen der 8 Kerne fest und siehe was passiert ;)
Wieso? Es ist ja nichts schlechtes wenn CPU-Kerne benutzt werden die vorhanden sind.
Es liegt daran, dass verschiedene Aufgaben automatisch nebenläufig ausgeführt werden, darunter auch das GUI.
Die eigentliche Hauptarbeit ist zwar in einem einzigen Thread, aber daneben fallen ja immer noch andere Aufgaben an, die dann falls vorhanden auch auf anderen CPUs ausgeführt werden können.
Brillus
2010-02-14, 03:19:15
Edit: hab müll geschrieben.
Edit2: Gerade nochmal nachgeschaut aktuelle x64 Windows versionen unterstützen noch x87 befehle im 64Bit-Modus ist aber deprecated und zukünftige Windowsversionen unterstützen sie evtl nichtmehr weshalb es nciht empfohlen ist sie zu verwenden.
Für 32-Bit-Applikationen wird es eh bis in alle Ewigkeit unterstützt werden.
Bei 64-Bit haben sie ihre Meinung wohl geändert, weil es keine Möglichkeit gibt eine Invalid-Opcode-Trap auszulösen im 64-Bit-Modus wenn x87 verwendet wird. Das würde dann dazu führen dass es manchmal geht und manchmal nicht, je nachdem wie der Task gescheduled wird. Äußerst übel.
Der WOW64-Layer wandelt x87-Befehle in äquivalente SSE-Befehle um.
Nein tut er nicht.
Es wird überhaupt nichts emuliert. Das einzige was passiert ist, dass bei System-Calls die Parameter von der jeweiligen 32-Bit-Variante für die vorhandene 64-Bit-Funktion konvertiert werden.
Hmm, was hat das mit der Branch Prediction zu tun ?
Der Loop Cache hält die µOps für Schleifen vor, wenn die Schleife da reinpaßt, dann werden die Befehle gleich in die Execution Units geschickt, und man spart sich das ganze x86 Befehlsdecodieren. Nachdem da viel x87 Zeugs vorkommt, werden da sicherlich auch ein paar (mehr?) vector path / complex instructions vorkommen, die bei AMD in jedem Schleifendurchlauf langwierig dekodiert werden müssen.Decoding dürfte doch in einer Pipeline keine zusätzlichen Takte kosten.
Das würde dann dazu führen dass es manchmal geht und manchmal nicht, je nachdem wie der Task gescheduled wird.Geschedult.
Decoding dürfte doch in einer Pipeline keine zusätzlichen Takte kosten.
Solange Deine Pipeline immer 100% gefüllt ist, und Nachschub da ist, dann ja. Aber bei ellenlangen vector path Befehlen würde ich nicht unbedingt davon ausgehen.
Ich meine mich zu erinnern, dass es zu Athlon 64 Zeiten so war, dass diese schneller Pi berechneten, als die Pentium 4. Das änderte sich dann, als die ersten Mobile Prozessoren von Intel auf Desktop Bretter geschnallt wurden.. da gabs doch dann auch diese s479->s478 Adapter. Ja und dann kam Core 2 Duo... ;)
Ich meine mich zu erinnern, dass es zu Athlon 64 Zeiten so war, dass diese schneller Pi berechneten, als die Pentium 4. Das änderte sich dann, als die ersten Mobile Prozessoren von Intel auf Desktop Bretter geschnallt wurden.. da gabs doch dann auch diese s479->s478 Adapter. Ja und dann kam Core 2 Duo... ;)
Zuerst kam mal der Core und ich glaube nicht dass der k8 in super pi schneller war als der P4(allerhöchstens pro mhz).
Hast du da eine Quelle dafür?
Undertaker
2010-02-14, 16:20:09
Da hat er schon Recht:
http://www.chip.de/artikel/AMD-Neue-Athlon-64-Prozessoren-und-Mainboards-im-Test-7_12888747.html
SuperPi lag dem P4 ganz und gar nicht.
roidal
2010-02-16, 11:57:05
Der WOW64-Layer wandelt x87-Befehle in äquivalente SSE-Befehle um.
64bit-Software nutzt von sich aus nur SSE.
Ne.
Da es 32-Bit Software ist wird sich auch im 32-Bit-Kompatibilitätsmodus der CPU ausgeführt und da gibts die x87-Befehle.
Warum SuperPI auf AMD-CPU's so langsam ist weiß ich nicht, vor einiger Zeit fand ich mal ein anderes PI-Berechnungsprogramm (war glaub ich in java geschrieben), und da war der Abstand bei weitem nicht so groß.
Acid-Beatz
2010-02-16, 17:09:00
Eigentlich vollkommend egal, ob SuperPi Intel optimiert ist oder nicht weil zu jedem Benchmark gibts ein Gegenstück, dass genau das Gegenteil "beweist" ;)
Eigentlich vollkommend egal, ob SuperPi Intel optimiert ist oder nicht weil zu jedem Benchmark gibts ein Gegenstück, dass genau das Gegenteil "beweist" ;)
Wie lautet das Gegenstück zum 3DMark, welches von AMD-CPUs dominiert wird?
Gegenfrage:
Ist Intel SuperPI-optimiert?
Acid-Beatz
2010-02-20, 16:52:15
Wie lautet das Gegenstück zum 3DMark, welches von AMD-CPUs dominiert wird?
Haha, erwischt :D
Aber prinzipiell kann wohl trotzdem das ein oder andere Spiel als "Beweis" dienen weil synthetische Benchmarks sowieso eher wenig Aussagecharakter haben.
Ist eigentlich irgendwo mal versucht worden die "diskriminierende" Intel vs AMD Frage wegzupatchen?!
Haha, erwischt :D
Aber prinzipiell kann wohl trotzdem das ein oder andere Spiel als "Beweis" dienen weil synthetische Benchmarks sowieso eher wenig Aussagecharakter haben.
Ist eigentlich irgendwo mal versucht worden die "diskriminierende" Intel vs AMD Frage wegzupatchen?!
Welches Spiel hättest du denn für mich im Angebot?
Acid-Beatz
2010-02-20, 18:51:00
Andere Frage bevor ich irgendwas suche: Auf was willst du eigentlich konkret hinaus ???
Andere Frage bevor ich irgendwas suche: Auf was willst du eigentlich konkret hinaus ???
Ob du einfach nur gerne heiße Luft produzierst, oder aber ob wirklich was dahinter steckt.
Auf 2 konkret gestellt Fragen hast du bei der 1. gepasst und dabei die Rahmenbedingungen (synth->realworld) geändert, die 2. mit einer was-willst-du-eigentlich Gegenfrage beantwortet.... von daher macht mich deine motivation etwas stutzig.
Achja, bitte suche keine Game-Benches, wo AMD in Very-High-Resolution GPU-Limitierten Settings mit NV-Grakas führt.
Momentan ist es schon ziemlich schwierig Code zu finden der auf AMDs schneller läuft, das stimmt.
Schön ist, wie stark die neue Mittelklasse bei Super PI einschlägt:
http://www.abload.de/img/pi276v.png
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.