proud2b schrieb:
Auf welchen Benchmark genau sprichst Du an?
Ich verfolge auf Phoronix schon eine geraume Zeit die Tests. Man muß sehr gut aufpassen, was und womit getestet wird. In der Regel aber, ich hoffe es zumindest, werden die Testsuits auf der Zielplattform compiliert, das heißt auch die Testgrundlage profitiert von einer Architektur (wenn ein Test in php geschrieben ist und php auf der Zielplattform compiliert wurde, kann das einen Vorteil ergeben).
Aber gut, daß Du diesen Bench-Parcours aufgegriffen hast. Er zeigt sehr deutlich, wo AMDs Silizium zu liegen kommt.
AMD kann dort punkten, wo offenbar die Datenstrukturen eine gute Auslastung der ALUs ohne häufige Speicherzugriffe erlauben. Dann stehen ungefähr 8 ALUs bei AMD gegen 6 ALUs auf Intels Seite. Der Compilerbenchmark ist auch näher erklärt und legt meine Vermutung nahe.
Threaded I/O, paralleles NAS Benchmarking, eigentlich ebenfalls Stärken der INTEGER Einheiten, sprechen dann wiederum gegen eine gute Auslastung. Schlägt hier das schlecht designte Frontend der Module zu?
Ganz übel für AMD wird es dann in Sachen Fließkommaarithmetik. Eigentlich sollten, wenn keine 256 Bit breiten AVX Instruktionen Verwendung finden, pro Modul je zwei halbe FPUs verfügbar sein. Also 8 halbe FPUs und acht ganze ALUs. Nun, offenbar stimmt die Rechnung nicht ganz, es entsteht eher der Eindruck, als seien wirklich nur 4 FPUs vorhanden und diese zudem auch noch trotz des höheren Taktes im Vergleich zum Intel schlechter an das Frontend angebunden. Auch scheint der Leistungseinbruch bei allen parallelen Benchmarks auf suboptimale hardwareseitige Handhabung der Kontextwechsel und damit verbundenen ladezeiten/Speicherzugriffe hinzudeuten.
AMDs DIV Instruktion ist doppelt so schnell wie Intels Sandy-Bridge Pendant - dennoch scheint sich dieser Umstand in der Summe wenig auszuzahlen. FMA und XOP werden wohl vom Compiler nicht intensiv umgesetzt, so daß Potential verloren geht. Wenn die Compiler allerdings hier besser optimieren, dann hat Intel ebenfalls FMA implementiert.
Es ist bekannt, daß eine Bulldozer/Piledriver ALU eine schlechtere IPC als das K8/10 Vorgängermodell aufweist - bei gleichem Takt. Eigentlich peinlich. Das krude Frontend, das offenbar öfter als erwartet einer Verstopfung erliegt, kommt offenbar dem Datenhunger seiner "Kerne" nicht nach - ganz zu schweigen von der FPU.
proud2b schrieb:
Speicherdurchsatz ist doch eine bekannte stärke der FX?
HW Angaben stehen glaub ich auf der ersten Seite.
Bei allen bislang veröffentlichten Benchmarks mit SiSOFT Sandra habe ich stets Intel mit großem Abstand in Speicherbandbreitenbenchmarks vorne gesehen! Vor allem dann, wenn Intel auf 4 Kanäle zugreifen kann und AMD immer noch mit 2 daherdümpelt.
Aber auch Intel hat bereits unfreiwillig zugeben müssen, daß im Ivy-Bridge die Kerne nicht mehr ausreichend mit Daten "versorgt" werden können, im XEON Ivy-Bridge-E/EN/EP wird es deshalb DDR3-1866 Speicher als Standard gebebn, man munkelt auch, daß statt zwei nun drei oder vier Riegel pro Kanal eingesetzt werden sollen (wohl nur bei den großen Server-Schlachtschiffen).
Athlonscout schrieb:
Dieser Prozessor ist nicht das Maximum. Imho eine Frechheit von Intel kastriertes Silizium zu diesen Preisen ihren Kunden andrehen zu wollen.
... so ärgerlich das auch ist bzw. sein mag, offenbar klappt das. Denn die Großabnehmer sind vermutlich Leute, die nicht wissen, was in ihrem Luxusrechner steckt, die interessiert nur, daß sie in der Preisklasse das Beste haben ...
Wenn man auf ECC verzichten kann, dann wäre theoretisch ein kleiner Ivy Bridge i3-3220 für einen Server optimal. Intel weiß das. Deshalb schneidet man dieser CPU Klasse auch AES-NI aus dem Fleisch! Genau diese Hardware aber beschleunigt den Verschlüsselungsdurchsatz auf kleinen Servern erheblich. Man muß also zu einem deutlich teureren XEON greifen oder einem Core i5. Und damit definiert Intel genau das, was der Kunde braucht, und nicht umgekehrt, wie es eigentlich sein sollte. Was aber will man von Winkeladvokaten und den Mitgliedern des Clubs des Goldenen Kalbes erwarten?