prescott - und die kommenden monate

[Treverer]

ich möchte - verspätet - ein paar gedanken zum prescott loswerden, die die nächsten monate betrifft.

- desktop -

es wird wohl zu recht auf vielen hardware-sites angenommen, der prescott skaliere besser mit dem takt, als es der northwood machte, so daß erst die höheren taktregionen sein wirklichen potential zeigen würden.

die gründe für seine bessere skalierung sind vor allem der größere L1 und L2-cache und die bessere sprungvorhersage. beschleunigter fsb bzw. schnelleres ram mit der einführung neuer chipsätze für ddr2 erhöhen ebenfalls die skalierfähigkeit.

die entscheidende frage ist jedoch nicht, ob der prescott besser skaliert als der bisherige northwood-kern, sondern ob er dies besser macht als die hammer-cores. klar, skalierung hängt auch immer ab von der software, aber es geht hier um die grundtendenz...

was dagegen spricht, daß der prescoot hier besser abschneidet als der athlon64 ist die integrierte northbridge desselbigen und die zusätzliche anbindung des i/o durch einen hyperlink.

faktisch sieht es doch derzeit so aus:

athlon64 3200+ läuft mit 2,0GHz, angenommene 2,6GHz in 130nm verfahren bedeuten 30% taktsteigerung. nehme ich den prescott mit 3,0GHz und erhöhe um den faktor 1,3, so bin ich bei 3,9GHz angelangt. selbst wenn der prescott genausogut skalieren würde wie der athlon64 - was ich bezweifle -, er könnte die leistungsdifferenz, die derzeit zwischen prescott@3,0 und athlon64@2,0 besteht nicht aufholen. diese leistungsdifferenz ist im vergleich zum northwood-core ha sogar noch größer. ein athlon64@2,6GHz trüge zu recht die bezeichung 4000+.

was sind die maßnahmen die intel deswegen unternimmt? vor allem wohl die einführung von ddr2 inklusive erhöhung des front-side-busses. wobei noch unklar ist, inwiefern mehr bandbreite fehlt und erhöhte latenzzeiten vernachlässigbar sind.

aber auch amd ist ja nicht untätig und unternimmt maßnahmen, um intel zu kontern: der sockel 939 bzw. die einführung eines athlon64 mit dual-channel für desktop-systeme, also unregistered-ram. dies bedeutet eine erhöhung der verfügbaren bandbreite UND eine verringerung der latenzzeiten. beides läßt die cpu wieder besser skalieren. auch wird dann noch nicht teureres ddr2 benötigt. die bereits bekannte erhöhung des hyperlink-taktes auf 1GHz sorgt ebenfalls für eine bessere skalierung, wenngleich der meßbare effekt wohl in den meisten benchmarks kaum 1% ausmachen wird. aber in zeiten, wo meß-unterschiede unterhalb der streuung benutzt werden, um performance-"sieger" zu küren, zählt jedes quentchen. die bereits vorhandene skalierungs-schere zwischen hammer- und prescott-core wird jedenfalls anwachsen mit zunehmenden takt.

ein wichtiger weiterer grund hierfür ist das verhältnis cp-takt/ram-takt. wenn ich bei dem beispiel von amd@2,0GHz und intel@3,0GHz bleibe, den takt um 30% erhöhe und von dual-channel DDR400 ausgehe, dann zeigt sich, amd beginnt mit dem Faktor 2GHz/800MHz = 2,5; intel beginnt mit 3/08=3,75. würde es bei DDR400 bleiben erreicht amd 2,6/08=3,25 und intel heftige 3,9/08=4,88. wir wissen ja noch, wie der pIII unter den FSB100 leiden mußte, aber auch die P4 mit SDRam bzw. DDR-single-channel. intel kann sich dies kaum nochmals erlauben, DDR2 klopft an der tür...

was den desktop-markt betrifft, so muß man wegen der gemachten gründe wohl feststellen, daß amd beste chancen auf ein gutes jahr hat. wichtigste voraussetzung ist hier die erfolgreiche einführung einer 2,6ghz cpu in 130nm. würde dies dieses jahr schon in 90nm gelingen, soll es auch niemanden stören, außer intel. wenn amd erst bei 2,8GHz den 90nm prozess benötigt, umso besser, denn dies erhöht den spielraum nach oben. natürlich vorausgesetzt, 90nm wird bei amd im gegensatz zu intel zu einer deutlichen leistungsaufnahmereduzierung führen.

intel hat mit dem prescott maßnahmen ergriffen, um gegen zu halten. doch diese maßnahmen reichen anscheinend nicht. sie bräuchten erheblich höhere taktraten, nämlich deutlich über 4ghz hinaus. doch aufgrund der bereits hohen thermischen belastung in den prescotts scheint mir dies unmöglich für sie zu erreichen sein in den bisherigen fertigungsprozess.

- server -

dies alles betraf den desktop-markt. wie sieht es aus auf dem servermarkt? man kann feststellen, daß amd mit der einführung der opterons dort sehr gut gepunktet hat. sie zwangen intel, die xeon-serie von damaligen rund 2,0ghz schnellstes auf 2,8ghz zu bringen. hinzu kam die erhöhung des fsb, mittlerweile eine erhöhung des taktes auf 3,2ghz und die erhöhung der caches (korrekt: einführung von l3 - die sich ja in den p4ee wiederfinden). intel mußte also kontern, hat es relativ erfolgreich getan - und fast sein ganzes pulver verschossen. amd braucht die opterons nur auf 2,4ghz zu erhöhen und schon hat intel wieder deutlich das nachsehen.

eine erhöhung des hyperlinks um 20% auf 1ghz in mehrprozessorsystemen wiederum wird - anders als in einprozessor-systemen - sich sehr stark auswirken auf die gesamtgeschwindigkeit des systemes. an der ram-geschwindigkeit wird vorerst bei amd kaum gedreht werden können, während bei intel noch die erhöhung des fsb auf 800mhz aussteht. ich bezweifle aber, daß dies auch nur die steigerung des hyperlinks wettmachen kann. vielleicht schafft intel noch 3,4ghz xeons mit altem northwood-core inkl. fsb800. dies verlangt aber ein neues, teures board und neues ram - warum sollte ein käufer da nicht gleich zur besseren amd lösung greifen?

wenn amd einen athlon64@2,6ghz liefern kann, dann wird dies wohl auch opterons mit solchem takt geben. die xeons werden dagegen nicht ankommen können, auch nicht wenn sie den neuen prescott-core hätten. den alle xeon-systeme kranken daran, daß ihre cpu´s sich die bandbreite zum ram teilen müssen, was bekanntlich bei den opteron-systemen nicht der fall ist. dies bedeutet zuallererst einmal, daß die xeon-systeme grundsätzlich schlechter skalieren mit takt und cpu-anzahl als dies beim opteron der fall ist. das desktop-problem ist also hier nochmals verschärft zu ungunsten intels. dies ist bei den benchmakrks deutlich zu erkennen. und es wird noch schlimmer, wenn ein numa-os verwendung findet, welches die nutzung des (lokalen) rams optimiert. ich denke 5% mehrleistung sind niedrig angesetzt, aber entscheidender ist erneut, daß solch ein numa-os die skalierung der cpus mit takt und anzahl verbessert.

dies gilt ebenfalls für etwas bisher nicht von mir erwähntes: 64bit. es heißt, die code-länge bei 64bit erhöht sich in etwa um 15% bei amd64 bzw. x86-64-code. (bei einem itanium ist diese erhöhung um ein vielfaches höher). interpretieren kann man diese erhöhung auch als reduzierung von ram-bandbreite und cache-größe - faktisch also contraproduktiv insbesondere was die skalierfähigkeit betrifft. doch auf der anderen seite steht wiederum die (seltene?) möglichkeit, daß durch verwendung von 64bit großen registern seltener auf cache und/oder ram zugegriffen werden muß. dadurch, daß amd jedoch im 64bit modus die anzahl der verfügbaren register verdoppelt hat, wird aus dem seltenen fall ein üblicher - nur bei neu-kompilierter software versteht sich. netto hierbei erneut 5% geschwindigkeitszuwachs zu veranschlagen ernscheint mir nicht zu hoch. bei sse optimierter software erwarte ich sogar ein desaster - für intel. nicht, daß amd sie weit überholt - aber enorm aufholt, wo sie jetzt zurück liegen.

dies nur nebenbei. denn wieder ist entscheidend, daß vor allem die skalierung mit dem takt durch 64bit verbessert wird - für desktop- und multiprossersysteme. bei numa-os nur bei letzterem - aber verbunden mit der erhöhung des hyperlinktaktes wohl mit großem erfolg.

die einführung von x86-64-code bei intel ändert an diesen schlechten skalierungs-aussichten gar nichts. wohl eher im gegenteil: x86-64-code hat, wie erwähnt, den nachteil, länger zu sein. da die derzeitigen intel-prozessoren bandbreitenhungriger sind als die amd-prozessoren leiden sie folglich stärker darunter. verstärkt wird dies nochmals dadurch, daß die intel caches inklusive aufgebaut sind, die verlängerung des codes also zu einem effektiv noch kleinerem cache führt, als dies bei amd der fall ist (im verhältnis nämlich zum zu "cachenden" ram ).