Replik

Kollege Möllenkamp wird ja nicht müde, Suns Weitsicht zu betonen, CMT eingeführt zu haben. Dies will ich ihm oder Sun ja auch gar nicht nehmen; allerdings ist mir diese fragliche Architektur mit dem so treffenden Namen »Niagara« bislang den Beweis schuldig geblieben, daß sie auch irgendetwas zur Errettung der Menschheit aus welcher, ggf. auch selbst-induzierten, Gefahr auch immer beitragen würde.
Irgendwo wird Sun dies selbst eingesehen haben, bietet Sun Deutschland doch »Rabatte auf Sun Server&Workstations mit Intel, AMD und UltraSPARC Prozessoren« im Sun Startup Essentials-Programm an; die Zeiten, in denen Startups mit Sun-Hardware (damals gleichzusetzen mit der (Super-, Ultra-)SPARC-Architektur) loslegten, sind meiner Beobachtung nach jedenfalls lange vorbei.
Sicherlich ist die Idee bestechend, daß eine CPU tatsächlich und nicht nur quasi-parallel arbeitet, also in einem Taktschritt wirklich mehrere Dinge unabhängig von einander durchführt. Nur, wie Sun schon bei der Prognose »eine FPU reicht für alle n Cores, im Internet nutzt man kaum Floatingpoint« zur T1-CPU falsch lag (teilweise wird extensiv Integer-über-Floatingpoint gemacht, da dies auf herkömmlicher Architektur zu besserer CPU-Auslastung führt, bei der T1 aber eher zur vollständigen Blockade; »In conclusion with the UltraSPARC T2 we have solved the issue of limited floating point capability that was an issue on the original T1.«), auch bei der T2 konnte ich in einem vorab definierten Szenario mit gegebener Software keinen Vorteil der »Threads« der T2-CPU messen.
Ich behaupte ja nun nicht, daß sie nicht da wären, die Threads — auch Intels HyperThreading-Notnagel kann zu einem Gesamtperformancepuls führen, wenn die Software die Besonderheiten kennt. Sehr schön war das mit frühen, nicht auf HT vorbereiteten Linuxkernels zu sehen: Der Kernel sah 4 CPUn (zwei reale und eben zwei virtuelle) und verteilte tapfer die Workload auf die 4 Prozessoren; leider waren zwei davon alles andere als performant und zu allem Überfluß gab’s Abhängigkeiten bei den Caches und dergleichen. Kurz: von einem Performancegewinn konnte man nicht sprechen, damals war es sinnvoller, HT zu deaktivieren — nachdem der Linuxkernel gelernt hat, daß CPU(-Kern) nicht gleich CPU ist, kann HT einen Vorteil bringen.
Mein Problem mit Niagara ist, daß ich mich weniger über coole Errungenschaften von Sun um ihrer Selbst willen freuen kann, wie man das im Hause Sun noch kann — ich habe in der Regel eine konkrete Software, die nun auf dem Niagara-Blech rennen soll, denn FSC wie Sun entsorgen zunehmend die traditionellen Einstiegs- und Midrangeserver zugunsten der Niagara-Linie. Und noch jedes Mal hat die Niagara-Maschine die Erwartungen nicht erfüllt, sei es OSS, die mit nicht-Nigara-optimiertem gcc kompiliert/von einer anderen Sun-Maschine kopiert wurde, sei es eine kommerzielle Software, die je Thread fast-linear skalieren sollte, nach Erreichen der Core-Anzahl allerdings nur noch nicht gravierend langsamer wurde.
Wer eine Nische gefunden hat, wo er massig Niagaras drin versenken kann: schön für ihn; ich konnte eine solche Nische leider noch nicht finden, somit sind diese Server für mich letztlich mehr als flüssig. Und deshalb bleibe ich auch bei meiner Ansicht, daß der zu beschreitende Weg in Richtung massiver Multicores gehen muß; 4, 8, 16, 32 Cores auf einem Chip, gerne — aber vollfunktionsfähige Cores bitte, mit sattem Registersatz und voller Taktfrequenz. Single-Thread-Performance ist – meiner Ansicht nach jedenfalls – heute auch wichtig, eine 10 GHz-CPU mit 10 Cores a 1 GHz klingt zwar toll, wird aber keine Geschwindigkeitsrekorde mit $SINGLETHREADAPPLICATION aufstellen …
YMMV. Don’t drink and drive — take drugs and fly ;)