|
AMD K8, eine Fragestunde
Es ist nun doch vollbracht. Der AMD K8, Codename Hammer, ist endlich erschienen. Doch trotz dem aufwändigen Release Event am 22. April, den erhältlichen technischen Dokumenten und den Reviews einiger angesehener Hardwareseiten, gibt es auch heute noch mehr als genug ungeklärte Fragen zu AMDs neuem Wunderchip. Während Einige davon nur in einschlägigen Hardwarekreisen diskutiert werden, ziehen Andere den durchschnitts User und die Internetpresse in ihren Bann. Eben jene naheliegendere Fragen wollen wir daher genauer erläutern und ihre Hintergründe zum Vorschein bringen, zugleich wir natürlich genauso wenig mit endgültig richtigen Lösungen aufwarten können. Wir werden jedoch mögliche Antworten, wie sie in Foren und Artikeln besprochen werden, verständlich darlegen und somit zumindest ansatzweise einige Geheimnisse des K8 lüften. Sobald es Antworten von AMD auf die wichtigsten Fragen gibt, werden wir auf diese eingehen und mit den bisherigen Vermutungen vergleichen. Obwohl sich diese Unklarheiten verständlicherweise zuerst nur auf den Opteron beziehen, sind sie dennoch auch relevant für User, die mit einem Athlon 64/ FX liebäugeln.
Bild: Der AMD Opteron "K8"
Intelligente Hardware, die 64-Bit CPU
Echte 64-Bit CPUs gibt es ja schon längerer Zeit. Allerdings waren sie für Enduser wie uns, bisher völlig uninteressant. Meistens fanden diese CPUs ein Zuhause in großen Workstations oder Servern. Mit AMDs K8 ändert sich das jedoch schlagartig! Plötzlich wird 64-Bit auch im Desktopmarkt interessant und vor allem bezahlbar. Da wird es eigentlich einmal Zeit, die Sache so zu durchleuchten, dass der unsichere User auch weiss, was diese ominösen 64Bit ihm bringen sollen. Angefangen hat es ja im großem Stil mit Intels erster richtig großer 64-Bit-Architektur: Dem Itanium (IA-64). Von Hewlett-Packard und Intel zusammen entwickelt, mit etlichen Jahren Verspätung, und in der ersten Version mit eher durchwachsener Performance, versuchte man eine völlig neuartige Architektur auf den Markt zu werfen. Diese benötigt neue Software und eine neue Art zu denken. Heutige x86-CPUs verschwenden viel Zeit darauf, den Programmcode selbst so umzustrukturieren, dass sie ihn am besten abarbeiten können. Der Programmierer muss sich darum keine allzugroßen Sorgen machen. Der IA-64 dagegen setzt zwar auf brutale Rechenleistung, verlangt aber von Programmierer und Compiler wiederum, den Code direkt auf die Eigenheiten der CPU anzupassen. Softwarecode der nicht IA-64 freundlich ist, läuft sehr langsam ab. Zusammen mit einem Horrorpreis, lausiger Performance bei x86-Anwendungen, gewaltigen Chipgrößen und einer Wärmeverlustleistung jenseits aller bisherigen Desktop-CPUs war schnell klar, der IA-64 hatte im Desktop-Markt vorerst also nichts verloren.
Hier kann AMD punkten. Der K8 erreicht 64-Bit nicht durch eine komplett neue Architektur, sondern durch geschicktes Aufbauen auf bisherigen x86-32-Bit Ansätzen. Das macht den K8 ebenfalls zu einer echten 64-Bit-CPU, welche aber an den gleichen x86-Prinzipien wie bisherige Athlons angelehnt. Programmierer müssen nicht groß umdenken, Software kann schnell und relativ effizient für 64-Bit optimiert werden. AMDs Ansatz ist damit sehr benutzerfreundlich und für den trägen Desktop-Markt wie geschaffen. Allerdings hat das auch seine Nachteile. Um den x86-Pfad nicht gänzlich zu verlassen, musste AMD die Neuerungen im 64-Bit-Modus Grenzen setzen. Mit einer 64-Bit-CPU wie dem Itanium2, Power4 von IBM, Sparc 64 V oder den verblasenden Alphas kann der K8 daher nur bedingt mithalten. Wenngleich verschiedenste Benchmarks immerwieder belegen: Der K8 ist trotz der x86 Wurzeln, ein mehr als ernst zu nehmender Konkurrent.
64-Bit? Wo, wie und warum?
Doch für was sind diese 64-Bit-CPUs überhaupt nötig? Warum ist dieses Thema so wichtig, an dem sich so viele Geister scheiden? Ganz einfach: 64-Bit-CPUs erlauben es, Grenzen zu sprengen, die bereits zu Performanceeinbußen führen:
> 32-Bit-CPUs sind nur in der Lage, insgesamt 4 GByte (32-Bit Adressierung) Speicher anzusprechen. Direkt nutzbar sind weit weniger. In Zukunft entsteht ein Engpass da Anwendungen immer mehr Speicher benötigen um ihre Arbeit zu verrichten. Für einige Server Datenbank-Applikationen, Bildbearbeitung im großen Stil sowie der professionellen Videobearbeitung ist dies heute schon ein kritisches Problem. Die von Intel eingeführte Ausweichmethode mit 36-Bit-Adressierung, ist allerdings sehr umständlich, und nur in wenigen Fällen ausreichend schnell. 64-Bit-CPUs erlauben es, diese Grenze ohne Tricks zu überschreiten. Durch einen höheren Adressraum, z.B.: 40-Bit in der ersten Generation des K8, können theoretisch ganze 1024 GByte direkt angesprochen werden. Jetzt liegt die Grenze erst einmal wieder bei Mainboard- und Speicher-Herstellern, welche Speichermodule mit entsprechenden Größen fertigen und betreiben müssen. Sollte es dann nötig werden, kann AMD diesen Adressraum in zukünftigen CPUs erweitern und damit die vermeintliche Grenze noch weiter vor sich herschieben.
> 32-Bit-CPUs besitzen 32-Bit breite Register. Register sind die kleinsten aber auch schnellsten Zwischenspeicher einer jeden modernen CPU. Bevor die CPU irgendetwas bearbeiten kann, muss sie es erst einmal in solche Register einlesen (typischerweise aus dem L1-Cache). Die x86-CPUs besitzen leider nur sehr wenige, für ein Programm sichtbare Register. Bei großen Operationen muss die CPU deshalb ständig auslagern und umschaufeln. So verliert man wertvolle Peformance. Bei 32-Bit-Registern ist es möglich einen maximal 32-Bit großen Ganzahlen-Datentyp, z.B: eine 2^32 große Zahl aufzunehmen. Benötigt man Zahlen in einem Zahlenraum von 64-Bit, müssen diese auf 2 Register verteilt werden. Bei 64-Bit-CPUs dagegen können solche "Integer" Daten (Ganze Zahlen, ohne Kommstellen) in ein einziges Register geladen werden. Man braucht weniger Schritte für das gleiche Ergebnis und gewinnt dadurch an Performance. Fairerweise sollte man erwähnen, dass mehr als 4 GByte Speicher für Desktops noch nicht wirklich erforderlich sind. Und 64-Bit-Datentypen findet man dort ebenfalls nicht im Überfluss. Warum sollte AMD also 64-Bit in ein Desktopsystem pressen, zumal ein 64-Bit-Programm nicht auf einer 32-Bit-CPU läuft.
Fairerweise sollte man erwähnen, dass mehr als 4 GByte Speicher für Desktops noch nicht wirklich erforderlich sind. Und 64-Bit-Datentypen findet man dort ebenfalls nicht im Überfluss. Warum solte AMD also 64-Bit für den Desktop bringen?, zumal ein 64-Bit-Programm nicht mehr auf einer 32-Bit-CPU läuft.
K8 als 64-Bit-CPU
Wie schon im Vorfeld erwähnt, musste AMD auf dem x86-Pfad bleiben um überhaupt eine Chance zu haben, im Desktop-Markt entsprechenden Anklang zu finden. AMD entschied sich dem K8 verschiedene Betriebsmodi zu verpassen. Einen reinen 32-Bit-Modus, einen 64-Bit-Kompatibilitätsmodus der 32-Bit-Software ausführen kann, und einen echten 64-Bit-Modus. Um zwischen 32- & 64-Bit-Modi zu wechseln, braucht es einen Neustart. Zwischen 64-Bit-Kompatibilitätsmodus und echtem 64-Bit-Modus kann die CPU selbst beliebig umschalten. Dies ermöglicht es dem K8, 32-Bit- & 64-Bit-Programme gleichzeitig auszuführen. Der K8 kann also als 32-Bit-CPU betrieben werden, während er als 64-Bit-CPU den größeren Adressraum für mehr Speicher, und die doppelt so breiten Register besitzt. Dass diese zwei Argumente allerdings kaum ein Grund sind, ein normales Spiel oder Programm auf 64-Bit anzupassen, wusste auch AMD. Man ließ es sich deshalb nicht nehmen, den vorhandenen und etablierten x86-Standard im 64-Bit-Modus etwas aufzumöbeln. Da ein 64-Bit-Programm sowieso nicht auf einem 32-Bit Athlon oder Pentium läuft, musste man auch nicht mehr dafür sorgen, dass die Kompatibilität zu 100 Prozent gewährleistet ist. Als Grenze galt nur: die CPU muss auch im 64-Bit-Modus alte x86-Software ausführen können, und der Programmierer darf nicht gezwungen werden, zu stark umzudenken. Es ergab sich Folgendes:
> Der K8 besitzt im 64-Bit-Modus nicht nur 64-Bit breite Allzweck-Register für Integer Datentypen, er verdoppelt zudem deren sichtbare Anzahl von 8 auf 16. Als Folge muss die CPU weniger Auslagern, was spürbare Vorteile bringt.
> Die bereits 128-Bit breiten SSE2-Register wurden ebenfalls von 8 auf 16 erweitert. Damit beschleunigt man besonders in Fälle, in denen SSE2-Code durch die Anzahl der Register gebremst wird. Zugleich, legt man den Programmierern nahe, Fließkommaberechnungen nur noch mit SSE2 zu erledigen. Die bisherigen FPU Berechnungen samt ihrer über Jahre vererbten Krücken, wird aufs tote Gleis geschoben.
> Einige kleinere, der Performance zuträgliche Änderungen und Aufräumaktionen am verstaubtem x86-Standard.
Mehr Performance mit 64-Bit?
Nach einem langen Intro und der Betrachtung des 64-Bit-Modus des K8 steht nun sicherlich eine Frage im Raum; Was bringen diese 64-Bit denn nun? - Zuersteinmal gar nichts!
Wer die Vorteile des 64-Bit-Modus nicht nutzt, erhält auch keinen Performance-Vorteil. Erst spezielle 64-Bit-Betriebsysteme und angepasste Compiler erlauben es, die Extra-Register und deren doppelte Breite zu nutzen. Davor bleibt der K8 eine 32-Bit-CPU mit z.B.: 1,8 GHz Takt. Einzig der große Cache und Verbesserungen an der Architektur selbst machen die CPU schneller als die Desktop-Boliden mit vergleichbaren 1,8 GHz. Im 64-Bit-Modus lassen sich z.B.: viele Wissenschaftliche-Programme schneller ausführen, die von den Registern und der schnelleren Verarbeitung profitieren. Ein Beispiel von AMD, wäre eine Multiplikation mit 2(64-Bit) Integer Zahlen. Ein gleichgetakteter 32-Bit-Athlon darf dafür gut 4x(Multiplizieren) und 8x(Addieren). Der K8 soll dies im 64-Bit-Modus bereits mit einer Multiplikation schaffen. Zudem multipliziert er im 32-Bit Modus auch noch etwas schneller als sein Vorgänger. Sicherlich ein Extrembeispiel, es zeigt jedoch was möglich ist, falls man Nutzen daraus zieht.
Doch was bringt das dem Spieler? Nicht jedes Spiel berechnet schließlich die Ausbreitung von Wellen in flüssigem Metal, durch ganze Zahlen. Spiele können kaum einen großen Nutzen aus so immensen Zahlen ziehen. Vielmehr macht sich hier die höhere Anzahl der Register, sowie der sehr große Cache bemerkbar. Die für Physik, KI und Geometrie so beliebten Fließkomma Operationen, können von 32-Bit-CPUs bereits als 64-Bit große Daten verarbeitet werden. Hier bringt der K8 bis auf SSE2, also keine größeren Neuerungen. Tatsächlich scheint also die 64-Bit-Version eines Spiels, nur Alibi um an die begehrten 8 zusätzlichen Register heranzukommen. Operationen mit 64-Bit-Integer-Daten oder gar mehr als 2 GByte Speicher (4 GB sind für Programme nicht direkt verfügbar), wird so schnell kein Spiel benötigen. Jedenfalls wäre der 64-Bit-Ansatz an sich kein Kriterium, ein 3D-Spiel bedeutend schneller zu machen. Viel mehr zählen die Änderungen, die AMD wie oben beschrieben, zusätzlich eingefügt hat. Ob man wirklich 30 Prozent mehr Leistung sehen wird, wie die angebliche 64-Bit UT2004-Version bescheinigen soll, ist für uns daher noch fraglich. Man lässt sich jedoch gerne überraschen.
Bei anderen Programmen wie der Bildbearbeitung oder echten High-End Multimedia-Anwendungen sieht die Sache schon etwas anders aus. Je nach Programmcode könnte man durchaus seinen Nutzen aus den eigentlichen 64-Bit-Fähigkeiten ziehen. Wie hoch der Performanceschub dann wirklich in Zukunft sein wird ist aber jetzt noch nicht ersichtlich. Man kann jedoch sicherlich von ~ 5 bis 15 Prozent ausgehen. Es liegt in der Hand von Microsoft wie gut das 64-Bit-Windows wird. Denn, seien wir ehrlich - am Ende wird es so oder so darauf hinauslaufen, dass sich der größte Teil der User ein 64-Bit Windows installieren würde und man nur 64-Bit-Windows Benchmarks um die Ohren gehauen bekommt. Die Frage ist jetzt nur: Wird es in naher Zukunft überhaupt eine öffentliche Version von Windows XP-64 geben? Bisher scheint das noch nicht gesichert zu sein.
Zukunftsmusik?
Trotzdem - AMD es den Herstellern relativ leicht gemacht hat, werden 64-Bit-Programme im Desktop-Markt vorerst wohl nur selten anzutreffen sein. Zuerst muss AMD eine große Anzahl an 64-Bit-CPUs verkaufen. Ob Intel danach mitzieht oder eine eigene Suppe kocht, steht auch nicht fest. Eventuell wird 2004 bzw. erst 2005 dann aber doch das große 64-Bit-Jahr für uns. Und vielleicht findet sich dann auch schon Verwendung für mehr als 4 GByte Speicher.
Die Fragen - Was ist los mit SSE2?
Seit AMD die Server-CPU "Opteron" vorgestellt hat, ist es wieder etwas ruhiger um die K8 Architektur geworden. Einzig wer halbwegs aufmerksam in einigen Foren mitgelesen hat, wird wohl die ein oder andere Fragwürdigkeit schon aufgeschnappt haben. Zumindest die vermeintliche SSE2 Schwäche wurde jedoch von Vielen bereits angemerkt. Als die erste AMD-CPU mit Intels Multimedia Erweiterungen SSE2, wurde der Opteron natürlich mit großem Interesse auf dieses Thema hin untersucht. Gerade deshalb war die Enttäuschung umso größer, als der Opteron in diversen Benchmarks mit SSE2, weit hinter einen Intel Pentium 4 zurückfällt. Wie wir sehen werden, in einigen Fällen sogar noch hinter die Werte eines AMD Athlon XP ohne SSE2! Glücklicherweise gibt es einige Hinweise, die helfen könnten die Gründe für diese Schwäche etwas aufzulösen.
Wie hoch ist die Verlustleistung des K8?
Ein weiteres Geheimnis ist die Verlustleistung der K8-CPUs. Zwar gibt AMD einen ziemlich hohen Wert an, allerdings nur einen Gemeinsamen für alle bisherigen Modelle. Die Meinungen gehen hierbei weit auseinander. AMDs Angaben lassen die Möglichkeit zu, dass alle Modelle tatsächlich den gleichen Wert, nämlich max. 89 Watt verbrauchen. Daneben ist es zumindest genauso wahrscheinlich, dass AMD die maximale Verlustleitung für den höchst getakteten Opteron in diesem Fertigungsprozess angibt. Die bisherigen Aussagen von eher "kühlen" CPUs, decken sich dabei mit einigen Tests die von Kollegen aus den USA angefertigt wurden.
SSE2 auf Abwegen
Am 2. Mai meldete "The Inquirer", dass ein Opteron mit SSE2 langsamer läuft als ein vergleichbarer AMD Athlon XP. Als Basis diente ein Bericht eines Japanischen Journalisten, der nach eigenen Tests geradezu niederschmetternde SSE2 Ergebnisse für den K8 erzielte. Während der getestete 1,6 GHz Opteron beim Encoden von Videomaterial mit DivX und Xvid durchaus auf dem Niveau eines 2,8 GHz Pentium 4 liegt, zeigen sowohl das MPEG2-Programm "TMPGenc" als auch Sisoft Sandra 2003 ca. 30 Prozent weniger Leistung bei Verwundung von SSE2 gegenüber MMX für Integer-Berechnungen. Daneben gibt es immer wieder Benchmarks in denen ein Opteron trotz SSE2, auch in Fließkomma intensiven Berechnungen, weit hinter den Pentium 4 zurückfällt. Bereits die ersten Reviews des Opteron erzeugten einigen Wirbel um die SSE2 Fähigkeiten. Seit dem Artikel von "the Inquirer" scheint die Schwäche allerdings endgültig bewiesen zu sein. Welche Gründe könnte es dafür geben? Zuerst sollte man zwischen Integer- und Fließkomma-Berechnungen unterscheiden. SSE2 kann hierbei Beides, und damit (integer) MMX ersetzen, wenn auch nicht ohne einige Anpassungen am Code. Zur Erinnerung, MMX arbeitet mit maximal 64-Bit großen Datenblöcken, SSE2 kann davon 2 in ein 128-Bit Register unterbringen. Es ist also durch SSE2 möglich, statt 2 einzelnen 64-Bit MMX-Operationen, eine 2(64-Bit) SSE2-Operation anzusetzen. Es fallen einige vorher benötigte Register-Operationen weg, wodurch sich ein spürbarer Performance-Vorteil ergeben sollte. Zumindest beim Pentium 4 ist dies auch der Fall. Der K8 zeigt aber nun anscheinend schlechtere Werte als zuvor mit MMX. Eine mögliche Lösung findet sich in den Dokumenten von AMD. Dort heißt es, dass bei bestimmten Konstellationen hinsichtlich des Codes, zusätzliche Wartezyklen entstehen. Dieses Problem könnte aber in einer zukünftigen Revision des K8 gelöst werden. Eine weitere Möglichkeit aus der Gerüchteküche wäre, dass der K8 bei SSE2-Integer-Code die 2(64-Bit) an Daten nicht in einem Durchgang abarbeiten kann, im Gegensatz zum Pentium 4. Auch hier würde viel Zeit verloren gehen, die am Ende die Leistung unter das MMX-Niveau drücken könnte. Verwunderlich ist nur, dass AMD Gerüchten zu Folge, nahezu alle Funktionseinheiten neu "designed" hat. Solch ein ungewolltes Problem sollte also nicht auftreten. Bisher warten wir auf eine Auflösung, ob es sich wirklich nur um ein behebbares Problem oder doch eine Limitierung in Hardware handelt. Zumal sich in dieser Hinsicht bisher nur ungenügende Antworten finden lassen.
Und doch nicht langsam!
Bei Fließkommaberechnungen dagegen sieht das Ganze etwas anders aus. Dabei gibt es prinzipiell zwei Möglichkeiten SSE2 zu nutzen. Die eine arbeitet mit Vektoren und entspricht der eigentlichen SIMD-Idee. SSE und SSE2 nutzen die FPU/ s der CPUs, um mehrere Datenpakete in einem Schwung zu berechnen. Daher auch "Single Instruction Multiple Date genannt". Das andere Verfahren Ändert nichts an der grundlegenden Arbeitsweise der FPU, kann diese aber effizienter nutzen. Wer jetzt aufgrund der vielen Bits und Skalar- sowie Vektor-Code, in den nächsten Zeilen den Anschluss verliert, der kann diesen Teil Überspringen und zum etwas gemäßigteren Fazit Übergehen. SIMD-Berechnungen wie SSE rechnen dabei mit 32-Bit Daten (32-Bit Präzision) und 128-Bit Registern. Dies erlaubt es, 4(32-Bit) Pakete in ein Register zu packen und in einem Durchgang zu berechnen. Es ergibt sich die theoretisch 4-fache Leistung gegenüber normaler Berechnungen durch die FPU. Das klingt zuerst nach einer ganzen Menge. Im Gegensatz zu SSE, kann die FPU aber auch an 64-Bit Daten arbeiten und rechnet intern sogar mit 80-Bit.
Ein entscheidender Vorteil für Anwendungen, die eine hohe Rechengenauigkeit benötigen. Um diese Schwachstelle von SSE auszumerzen, bringt Intel also SSE2. Da weiterhin die schon vorhandenen 128-Bit Register genutzt werden, können außer den bisherigen 4(32-Bit) auch 2(64-Bit) Pakete bearbeitet werden. Bei 64-Bit Genauigkeit ist der theoretische Performancefaktor aber nur um den Faktor 2 gegenüber der FPU größer, wenngleich auch dies nicht zu verachten ist. Der Vorteil ist des Ganzen, ist wie schon gesagt, eine höhere theoretische Leistung. Nachteile sind der enorme Aufwand um Code für SIMD anzupassen und ein praktischer Leistungsgewinn der deswegen meistens nur im Bereich von 5 bis 15 Prozent liegt. Zudem zeigt sich, dass Vektorcode für SIMD-Berechnungen zu erhalten, im Generellen keine leichte Aufgabe ist. Bisher ging es nur um SIMD-Berechnungen mit 2 oder 4 Datenpaketen, daher auch "Packed-SSE2" oder "Vektor-Code" bezeichnet. SSE2 bringt aber wie erwähnt noch einen weiteren interessanten Modus mit sich. Es ist möglich, SSE2 für die üblichen FPU Berechnungen, also für Skalare, zu benutzen. Dabei arbeitet man wieder an einzelnen 32-Bit- oder 64-Bit-Daten, umgeht aber durch SSE2 geschickt einige unangenehme Eigenheiten der x87 FPU (x87 bezeichnet den Coprozessor für x86-CPUs ohne FPU, z.B.: der 386. Da die FPU heute in die CPU integriert ist, wird sie mit "x87" bezeichnet). Im Skalar-Modus lassen sich zwar keine 2 oder 4 Pakete auf einmal berechnen, dafür arbeitet die FPU schneller und effizienter als zuvor im x87-Modus. Im Gegensatz zu SIMD-Code, haben Compiler zudem weniger Mühen, skalaren SSE2-Code zu erzeugen. Der größte Vorteil bleibt jedoch, dass im skalaren SSE2-Modus, die FPU erst richtig zeigen kann was in ihr steckt. Für den P4 und K8 wirkt sich SSE2 dabei folgendermaßen aus:
> Bei Packed-SSE2 (SIMD) können 2/ 4 FP-Operationen pro Takt gleichzeitig ausgeführt werden. Neben der Leistung der FPU-Einheiten zählt hierbei vor allem Takt und Bandbreite.
> Bei Scalar-SSE2 weiterhin nur 1 FP-Operation pro FPU, dafür viel effizienter als zuvor. Der K8 hat hierbei eine dem P4 stark überlegene FPU.
Das SSE2-Fazit
Hier liegt auch das Problem des K8. Bei richtigem SIMD SSE(2) ist der K8 nicht großartig in der Lage mehr Arbeit pro Takt zu verrichten als der P4. Was hier hauptsächlich zählt sind Speicherbandbreite und pure Taktrate. Beides hat der Pentium 4 im Überfluss. Es ist also nicht verwunderlich, dass ein 1,8 GHz Opteron, einem 3GHz Pentium 4 nicht das Wasser reichen kann. Es ist aber trotzdem erstaunlich, dass er in vielen Fällen, so z.B.: beim Sciencemark 2.0, an einen 2,8 GHz P4 Xeon heranreicht. Da aber nicht jedes Programm die gleichen Befehle und Berechnungen nutzt, pendelt sich der Opteron im Durchschnitt zwischen einem gleichgetakteten Pentium 4 und bzw. mit mehreren hundert MHz Unterschied ein. Dies war so bisher auch in den benutzten Benchmarks zu sehen. Völlig unterschiedlich sieht die Sache dagegen beim zweiten, dem skalaren SSE2-Modus aus. Wie oben erwähnt geschildert, fällt hierbei ein großer Teil des alten x87-Ballasts der FPU weg. Im Gegensatz zu SIMD SSE2, kann jetzt zwar nicht an mehreren Daten gleichzeitig gearbeitet werden, dafür arbeitet die FPU effizienter als zuvor mit all dem Ballast. Die FPU des K8 wird dadurch geradezu entfesselt, was sich im Sciencemark 2.0 Benchmark mit nahezu identischen Werten zum SIMD SSE2-Code bemerkbar macht. Der Pentium 4 dagegen erreicht hier nicht einmal knapp die Hälfte seines vorherigen Wertes. Der schwachen FPU kann auch Skalar-SSE2 nicht mehr großartig helfen. Der K8 Überzeugt also speziell bei skalarem SSE2-Code. Kein Wunder also, dass AMD selbst fordert, so oft wie möglich diesen SSE2-Modus statt die pure FPU zu nutzen. Allerdings ist skalarer SSE2-Code nicht wirklich häufig anzutreffen, da der Pentium 4 nicht besonders schnell damit ist. Erst seit dem K8 würde es sich lohnen solchen Code zu wirklich nutzen. Man kann also hinsichtlich der Fließkomma SSE2-Performance festhalten:
> Bei SIMD Vektor Code liegt der K8 je nach Anwendung knapp oder weit vor einem Pentium4 identischer Taktrate.
> Bei Skalar-Code erreicht der K8 nahezu die gleiche Leistung wie beim Vektor-Code, und übertrifft die Leistung eines Pentium 4 bei Skalar-Code damit bei Weitem.
Je nach Art der SSE2-Optimierung zeigt der K8 also vergleichbare bis überlegene Leistung selbst gegenüber höher getakteten Pentium 4-CPUs. Die SSE2 Fertigkeiten des K8 können also zumindest bei Fließkommaberechnungen kaum als schwach bezeichnet werden. Wenn überhaupt, liegt das Problem einerseits in der zu geringen Taktrate des K8, die sich bei Vektor-Code nachteilig gegenüber dem Pentium 4 auswirkt, auf der anderen Seite in der Hand der Programmierer. Wird nämlich im Zuge der SSE2-Optimierungen gleich für den Pentium 4 handoptimiert oder SSE2 nur bei einer Intel-CPU aktiviert, kann der K8 natürlich nur schwerlich punkten.
Warum nutzt AMD wieder ein Keramik-Package?
Zu guter Letzt wird dem aufmerksamen Beobachter nicht verborgen bleiben, dass AMD für den K8 wieder ein Keramikgehäuse nutzt. Dieses wurde zum Release des Athlon XP von einem Gehäuse aus organischem Material abgelöst. Das sorgt vor Allem für eine Kostenersparnis seitens AMD. Warum sollte AMD also zum kostspieligeren und veralteten Gehäuse zurückkehren? Die mutmaßlichen Gründe sind besonders für zukünftige Athlon 64 Besitzer eventuell nicht unbedingt erfreulich, sollte AMD auch dort gezwungen sein, dieses Package zu verwenden.
Des Kaisers neue Kleider
Da wir gerade bei hohen Taktraten und purer Rechenleistung sind, lohnt es sich vielleicht, auf den Heatspreader des K8 hinzuweisen. Beschädigte CPUs die durch DAUs dahingerafft wurden, sollten damit der Vergangenheit angehören. Doch während sich der User bereits auf Heatspreader bei Athlon 64-CPUs freuen darf, wundern sich Einige über das Material unter dem Heatspreader. Das sogenannte Package (Gehäuse), welches die eigentliche CPU - das DIE - beherbergt, und auf welchem letzten Endes der Heatspreader sitzt, besteht nun plötzlich wieder aus Keramik. Ein Package aus organischem Material (Plastik), wie es beim Pentium 4 oder Athlon XP vorzufinden ist, ist kostengünstiger und scheint zumindest für Intel aus qualitativer Sicht den Ansprüchen zu genügen. Es gibt jedoch Meinungen, nachdem die eigentliche Opteron-CPU schon teuer genug in der Fertigung für AMD sei, da spielt es wohl keine große Rolle mehr, auch ein teureres Package zu nutzen. Dies mag auch stimmen, trotzdem stellt sich die Frage: Warum unbedingt wieder Keramik? Auch hier gibt es keine endgültige Antwort, weder seitens AMD noch aus anderen Quellen. Es gibt jedoch eine Menge von Meinungen und Spekulationen. Die erste Überlegung wäre natürlich, dass Keramik durch all die Anschlüsse, Verdrahtungen und Pins wieder von Nöten wird, um das komplexe Gebilde stabil genung zu halten. Wie jedoch Intel mit dem Pentium 4 bewiesen hat, sollte es keinerlei elektrischer Probleme mit dem momentanen Package geben. Eine weitere populäre Meinung, hält Keramik der mechanischen Eigenschaften wegen, für die bessere Wahl. Als Server-CPU muss der Opteron nicht nur schnell, sondern auch ausfallsicher sein. Grade für Server-CPUs sind immens große Kühlkörper, mit entsprechendem Gewicht, keine Seltenheit. Keramik könnte nötig werden um dem hohen Anpressdruck von Kühlkörpern für Opterons standzuhalten. Denn je größer die Kühlfläche des Kühlers ist, desto schwerer wird der Kühler. Diese Möglichkeit scheint mit Hinsicht auf den Opteron als Server-CPU doch sehr einleuchtend.
Das Kraftwerk
Wieso die Zurückhaltung seitens AMD? Hinsichtlich der Angaben zur Verlustleistung und Gründen für das Keramik-Package, hält AMD die Informationssperre weit auf. Bei nur einer einzigen Angabe von 89 Watt Wärmeverlustleistung für alle Opterons, unterstützt man geradezu die Panikmache um Verlustleistung und Package. Eine Wärmeverlustleistung von 89 Watt für alle bisherigen Opterons klingt zwar etwas ungewöhnlich, AMD hat jedoch schon früher CPUs verschiedener Taktraten und gleicher Wärmeverlustleistung auf den Markt gebracht. Sollten die Opterons allerdings wirklich alle diesen gigantischen Wert aufweisen, könnte sich Keramik doch in thermischer Sicht als nützlich erweisen. Im Gegenzug würde dies aber auch bedeuten, dass der Athlon 64 mit schweren thermischen Problemen kämpfen müsste. Dies ist jedoch weder beim Opteron noch Athlon64 der Fall. Eigentlich sollte man ja einen spürbaren Rückgang in der thermischen Verlustleistung erwarten. Nicht umsonst, setzt AMD dafür auf einen SOI-Herstellungsprozess (Silicon-On-Insulator). Dieser verringert unter Anderem, ungewollte Leckströme und lässt eine niedrigere Versorgungsspannung zu. Allerdings sei anzumerken, dass AMD einen etwas "schwächeren", sogenannten "partially depleted" SOI-Herstellungsprozess benutzt. Den wesentlich effizienteren "fully depleted" SOI-Herstellungsprozess soll es erst später geben, man ist seitens AMD noch nicht so weit. Dieser erlaubt eine weitere Reduzierung der Versorgungsspannung und Wärmeverlustleistung. Trotz SOI überraschten die Opterons dennoch mit einer vergleichsweisen hohen Kernspannung von 1,55 Volt und angeblichen 89 Watt Wärmeverlustleistung. Intel reichen diese 1,55 Volt auch ohne SOI für gigantische 3 GHz. Zum Vergleich, der Opteron taktet bisher nur mit 2,2 GHz. Bei unseren Kollegen von "Ace's Hardware" untersuchte man nach großem Drängen der Community, die Opteron-Testsysteme von Newisys daher etwas genauer auf Wärmeverlustleistung der beiden enthaltenen CPUs. Dabei ließ man sich vom eingebauten Newisys-System-Management unterstützten, welches in der Lage ist; Temperatur der CPUs und die gesamte Leistungsaufnahme des Systems anzuzeigen. Somit konnte man durch Beobachtung der verbrauchten Systemleistung bei ausgelasteten CPUs, die mögliche Wärmeverlustleistung der 1,8 GHz Opterons näherungsweise bestimmten. Das Ergebnis ist eine Schätzung, die bei ca. 50 bis 60 Watt liegt. Damit zerstreuen sich vorerst die Befürchtungen, schon die ersten Opterons könnten am Thermischen-Limit arbeiten. Es bleibt eigentlich nur noch die Frage, warum AMD für alle CPUs genau 89 Watt angibt? Nachdem man die Wärmeverlustleistung nun unterhalb dieser Angabe halbwegs bestimmen konnte, bleibt dafür eigentlich nur noch eine Stelle als maximal thermischer Leistungsverlust für die ganze Opteron-Familie übrig. Bei einer Server-CPU z.B.: macht dies durchaus Sinn, ein auf maximale Verlustleistung ausgelegtes System kann somit alle zukünftigen Opterons ohne Modifikationen aufnehmen. Geht man davon aus, dass die Messungen hinsichtlich der Verlustleistung näherungsweise korrekt sind, und betrachtet man die möglichen Multiplikatoren für den CPU-Takt und die maximale Wärmeverlustleistung, dürfte der schnellste Opteron im bisherigen 0.13µ SOI-Herstellungsprozess daher wohl ein 2,4 bis 2,6G Hz Model sein. Es scheint wirklich, dass damit auch Athlon 64 User etwas aufatmen könnten. AMD sollte über 2,2 GHz noch etwas Reserven haben. Und dass sich selbst über 80 Watt Wärmeverlustleistung ebenfalls kühlen lassen, zeigt ja bereits Intel mit den 3 GHz Modellen seines Pentium 4. Der Athlon 64 läuft also kühler als Intels schnellste Rechenkünstler. Wie um dem noch Eines draufzusetzen, führt AMD mit dem Athlon 64 die "Cool & Quite" Technologie ein. Die CPU kann sich bis auf 800 MHz runtertakten und die Versorgungsspannung senken, wenn sie wenig zu tun hat. Die Leistungsaufnahme sinkt gewaltig und die Drehzahl des Lüfters kann reduziert werden. Vorerst bleibt diese Funktion aber den Athlon 64 vorbehalten. Erst die neue 90 nm Generation Namens "San Diego" wird dem Athlon FX dieses Technolgie bescheren.
 
Bild: Der AMD "Athlon 64" sowie der High-End "Athlon 64 FX-51" sind neben dem Opteron weitere Vertreter aus der K8-Familie.
Quintessenz
Für Einige der noch offiziell unbeantworteten Fragen über den K8, gibt es also bereits sehr gute Ansätze. Ob sich diese allerdings als 100 Prozent korrekt erweisen, wird sich in naher Zukunft durch AMD selbst zeigen müssen. Einzig das Problem mit SSE2 als MMX-Ersatz bleibt bisher völlig unzureichend erklärt. Sobald sich auf diesem oder einer der anderen Gebiete etwas ergibt, werden wir die Sache erneut durchleuchten. Bis dahin sind vielleicht auch schon neue interessante Fragen aufgetaucht die es zu betrachten gilt.
|
N
R
