Disclaimer:

Das hier Folgende sind überdachte Vermutungen bezüglich der Performance des FPU des Pentium 4, die sich auf die öffentlich zugängliche Entwickler-Dokumentation der Firma Intel beziehen.

Ich habe gerade die neuesten Tests und Kommentare über die FPU des P4 gelesen - die Ergebnisse sind enttäuschend, aber nicht wirklich überraschend. Lassen Sie mich das kurz erläutern:

Ich arbeite als Softwareentwickler für die Musiksoftwarefirma FXpansion Audio; in unserer Ecke der Computerindustrie ist der entscheidende Faktor der die Performance der Software bestimmt, die FPU und unser Code hat gewöhnlich eine Menge an von Hand optimiertem x87 FPU-Assembler-Code.

Wenn wir diesen Code schreiben, zielen wir natürlich auf den P6-Kern ab; meistens sind die Charakteristika des Athlon ähnlich ausreichend, so dass er durch seine bessere Gesamtperformance mit dem P6-Kern mithalten kann, auch wenn der Code auf P6 ausgerichtet ist.

Der P4 aber ist eine ganz andere Sache, und das ist der Grund: FP benutzt meistens die FADD/FSUB- und FMUL-Anweisungen; andere, wie z. B. FDIV werden so wenig wie möglich verwendet, da sie ohnehin langsam sind. Für schnellen FP ist also die wichtigste Sache FADD- and FMUL-Performance.

Diese Anweisungen sind oft recht komplex und es dauert einige Zyklen, bis das Ergebnis einer Berechnung am anderen Ende wieder herauskommt und zur Weiterverarbeitung bereitsteht.

Ein Beispiel:

a = a + (b * c)
Der Prozessor kann den "a=a+"-Abschnitt nicht erledigen (FADD), bis er das Ergebnis von (b*c) kennt (FMUL). Die Zeit, die es dauert, bis das Ergebnis bekannt ist, nennt man Latenz. Und sie wird in Zyklen gemessen. In der Zwischenzeit jedoch, kann der Prozessor andere Berechnungen machen, die das Ergebnis nicht benötigen (z.B. e=(f*g)); das ist es, was man unter dem Prozess des "Pipelining" versteht.
Für einen PPro 2/3 (P6-Kern) ist die FMUL-Latenz 5 und die FADD-Latenz ist 3. Ein typisches Stück P6-Code könnte also so aussehen:

temp = b * c // FMUL, latency 5
do_something_else
do_something_else
do_something_else
do_something_else
a = a + temp // FADD, latency 3
do_something_else
do_something_else
store (a)
. = 9 clocks

(do_something_else bedeutet dabei so viel wie: "mach was anderes")

Ein guter Programmierer ist in der Lage, das Letzte aus dem Prozessor herauszuholen, indem er die Latenzzeit mit andern nützlichen Dingen nutzt, während (b*c) und a=a+temp berechnet wird.

Nun werfen wir einen Blick auf den P4. Sein längerer Pipeline-Prozess, der aus mehreren, einfacheren Stufen besteht, gestattet viel höhere Geschwindigkeiten als ein P6-Kern. Da aber jede einzelne Stufe weniger tut, müssen die Befehle über mehrere Stufen, bis sie durch die Pipeline sind und so entsteht größere Latenz. In der FPU des P4 ist die Latenz bei FMUL 7 und bei FADD 5, bei P III hingegen 5 und 3.

Hier also der selbe Code, der auf einem P4 läuft:

temp = b * c // FMUL, latency 7
do_something_else
do_something_else
do_something_else
do_something_else
*****
*****
a = a + temp // FADD, latency 5
do_something_else
do_something_else
*****
*****
store (a)
. = 13 clocks
(wiederum heißt: do_something_else: "mach was anderes")

Das erste, was bemerkenswert ist: Der Code braucht länger, bis er ausgeführt ist. Normaler Weise sollte das kein Problem sein, könnten Sie sagen, da man die "Lücken" mit andern nützlichen Operationen füllen könnte. Die gesamte Rechengeschwindigkeit ist genau so groß (in Operationen pro Sekunde), weil der Chip immer noch eine Anweisung pro Takt ausführen kann (einfach dargestellt). Beachten Sie aber bitte die Zeilen, die mit ******* markiert sind.

Die Sache ist die, dass an diesem Stück P6-Code der Programmieren 4 Takte Arbeit vergeben hat, während das FMUL-Ergebnis ausgerechnet wird, und zwei Takte für FADD. Der P4 braucht aber länger als das, ist also zwei Takte unbeschäftigt am Ende von FMUL und ebenso 2 Takte bei FADD.

Ergo: Bei korrekt optimiertem P6-Kern-Code, der auf Ppro2/3-Prozessoren ausgelegt ist, was bei den meisten FPU mit guter Performance der Fall ist, läuft der FPU-Kern des P4 bis zu 50% langsamer als der entsprechende P III - und das Takt für Takt.

Je weniger genau der Code auf P IIIs abgestimmt ist, desto geringer dramatisch ist der Unterschied. Aber bei Dingen wie MPEG4, wo es auf jede Operation ankommt, ist der P4 mit dem Code für den P III alles andere als gut genützt.

Die gute Nachricht für Intel ist dabei, dass die meisten Codes umgeschrieben werden können, so dass diese Performance-Schwäche ausgeglichen werden könnte. Mit ein wenig Sorgfalt kann der Unterschied zum P III so auf etwa 10% reduziert werden, was ausreichend sein dürfte, um den P 4 auf dem Markt zu platzieren, wenn seine anderen Vorteile berücksichtigt werden.

Die Frage ist nur: Wird das irgend jemand interessieren? Speziell für Athlon geschriebener Code kann bis zu 50% schneller sein als jeder Intel-Prozessor. Wenn sich Athlons weiterhin gut verkaufen und P4s nicht, dann wird man schon sehen, wie sich die Dinge entwickeln werden.

Ich persönlich hoffe, dass Intel als Sieger davonkommt, und das aus zwei Gründen: Erstens, weil das P4-Speicher-Subsystem eine gute Sache ist, und das Gesamtkonzept ausbaufähig für hohe Taktfrequenzen. Und zweitens wäre es für uns Performance-Freaks eins schlechte Nachricht, wenn Intel ohne Konkurrenz P4s auf den Markt schleudert, die eigentlich nur deswegen mit Handbremse fahren, weil die Codes sie nicht ausreichend unterstützen. Diese Nachricht wäre ebenso schlecht wie die von einem AMD ohne Konkurrenz, damals, als es noch keine Athlons gab.
Die Zauberformel heißt doch:
Schnelle P4s = schnellere und billigere Athlons = glückliche User

http://www.fxpansion.com