"Bulldozer" und "Sandy Bridge" bringen beide neue Eigenschaften mit, die ein Compiler ersteinmal "richtig" optimieren lernen muß. Es ist nicht damit getan, daß der Compiler nun in der Lage ist, über "CODEGEN" den entsprechenden Zielcode zu erzeugen. Vielmehr muß der Optimierer auch "verstehen", welche Qualitäten der neuen CPU nutzbar gemacht werden können und wie man sie statt Althergebrachtem in neuem Code einbettet.
Die Situation am Markt ist weder Sandy-Bridge- noch Bulldozer-freundlich! C/C++ Compiler aus dem hause PathScale, M$, PGI und Intel können zwar bereits auf SB und BD optimierten Code generieren, Tests haben aber gezeigt, daß automatische Optimierungen zumindest auf der Intel-SB Plattform lediglich für einen Leistungszuwachs von ca. 3 - 5% sorgen. Erst handoptimierter Code bringt einen über die 20%-Marke reichenden Geschwindigkeitsschub.
Andere Skriptsprachen wie Python, die im UNIX und Linux Umfeld beliebt sind und auch compiliert werden können, nutzen ebenfalls keine BD- oder SB-Eigenschaften und die Liste der "Ich-kenne-weder-SB-noch-BD"-Compiler ließe sich weiter fortführen.
Auf der sogenannten x86-komaptiblen Methusalem-Plattform kommt dann auch zum Tragen, daß man Software auch "kompatibel" compilieren kann! "Generisches" compilieren heißt, daß auf der AMD64-Plattform lediglich SSE3 sozusagen als "ggT" angenommen werden kann. Als Entwickler werde ich dann auch tunlichst BLOBs in Umlauf bringen, die auf allen CPUs laufen, die diese Kriterien erfüllen.
Eine Möglichkeit ist dann aber, Funktionen in dynamisch ladbare Bibliotheken auszulagern, die mit entsprechenden Architektur-Optionen compiliert wurden und entsprechend der CPUID vom Zentralprogramm geladen werden. Soweit ich weiß, macht Windoof 7 dies mit Kernbibliotheken zur Behandlung mathematischer Operationen, sobald eine AVX-fähige CPU im System entdeckt wird.
Jeder Entwickler weiß aber, daß man oftmals nicht alle Fälle im Vorfeld beachten und abfangen kann und zudem erfordert es etwas Erfahrung mit der entsprechenden Architektur, bis man Code erzeugt, der optimal die architektonischen Eigenschaften einer neuen Generation berücksichtigen kann.
Ein Beispiel für einen solchen Vorgang war die Einführung der P4 von Intel, die gegenüber der bisherigen Architektur und die darauf optimierte Software das Nachsehen hatte. Es hat ca. 6 Monate gedasuert, bis Software am Markt war, die neue Eigenschaften und Design-Fallstricke optimal meistern konnte. Bis dahin waren in fast allen Computer-Boulevard Gazetten bereits die Tests/benchmarks durch.
Aus diesen Gründen sehe ich den Windows-Benchmarks gelassen entgegen, sie messen effektiv nur einen Bruchteil des durch die neue Architektur möglichen Verbesserungen, das meiste kommt durch Turbo, hohen Takt und generischen IPC-Verbesserungen zustande.
Aussagekräft ist meiner Meinung eh nur Opensource-Software, bei der man den Compiler mitsamt seinen Optimierungen kennt. oder SPEC, bei welchen diese Vermessung schon akademische Züge annimmt - und das ist so ziemlich genau. Alles andere ist besserer Kindergeburtstag und man darf stets davon ausgehen, daß "offizielle" Vermessungspakete, ob der Krempel nun 3DMark oder anders genannt wird, lediglich marktpolitischen, also PR-Zwecken dient.
Bulldozer bringt für Naturwissenschaftler und Leute, welche wirklich mit dem Prozessor rechnen, einige Eigenschaften zurück, die durch Intels x86-Durchseuchung der Szene verloren gegangen schienen. "Fused-Multiply-Add", eine die Genauigkeit erhöhende Berechnungsmodalität der FPU, bei der die Rundungsfehler der Berechnung von y = a +(b*c) stark reduziert werden, kennt der BD schon. Auf Intelplattformen muß man diese Operation umständlich durch numerische Bibliotheken "emulieren", was natürlich viel Taktzyklen kostet. Zudem kann die AMD CPU jetzt bei Operationen das Ergebnis der Operation auf ein von den Quellen unabhängiges Ziel schreiben. Das konnten nahezu alle 64Bit RISC Prozessoren, selbst der MC68k von Motorola war dessen schon in der Lage. Wenn man auf einem Intel-x86-komnpatiblen Dinosaurier, auch Sandy-Bridge, den Wert im Zielregister noch benötigt - weil dies zwingend einer der bdien Operanden gewesen ist, muß das namlich erst auf den Stack gerettet werden. Das sind wieder umständlich verlorene Taktzyklen. Wenn der Compiler nicht auf diese Instruktionen optimieren kann oder der Programmierer nicht Code erzeugt, der genau einen solchen Fall wie im Bulldozer bereitgestellt präferiert, liegt diese schnelle und schicke Eigenschaft brach.
Leider entscheiden heute Kinder, Anwälte und PR-Profis", was gebaut und vermarktet wird. Die Zeiten, als Ingenieure noch für alles zustandig waren und auch ihre Produkte entsprechend offen darlegten, sind vorbei. es steht zu befürchten, daß die neuen Eigenschaften des Bulldozer dann erst voll zur Geltung kommen werden, wenn Intel diese Eigenschaften ebenfalls implementiert haben wird und die Intel-hörigen Compiler aus dem Hause Intel selbst und Microsoft diese eigenschaften auch explizit nutzen werden. Dann aber ist Intel vermutlich schon in der zweiten Post-Bulldozer-Generation.
Mein dringlicher Vorschlag wäre, unbedingt die Testmodalitaten in Richtung Objektivität zu verschieben. Das, was heute und hier, vor allem auf den Spielzeug-Gazetten zelebriert wird, kann man llenthalben belächeln.
(athlon x2) Ich hoffe daher das non-fx Bulldozer (sowas gibts doch auch oder?) dann preislich richtig interessant sind, ein sagen wir 2,5 -3 ghz quadcore würde mir zur not schon reichen, mit neuem effektiven kern, da die spiele ja eh fast alle auf Konsolen optimiert werden, und die sich seit 4 jahren nicht verbessert haben, dürfte das bis auf weiteres für jedes spiel reichen.
