Prozessorgeflüster
Die 32-nm-Prozessoren, mit denen Intel nun die Ära der x86-CPUs mit integrierter Grafik einläutet, halten sich nicht unbedingt an alte Versprechen – aber die Sünden von gestern holen Intel jetzt wieder ein.
- Andreas Stiller
Vor gerade mal eineinhalb Jahren veröffentlichte Intel unter „Detecting Multi-Core Processor Topology in an IA-32 Platform“, wie man korrekt und zukunftssicher die CPU-Topologie bestimmen kann, um seine Software auf jedem System optimal verteilen zu können. Wer sich darauf verlassen hat, tja – der wird nun eines Besseren belehrt: Die Arrandale- und Clarkdale-Prozessoren verhalten sich zumindest in den von uns bislang getesteten Systemen wie Quad-Cores mit herausgestrichenen Kernen und der von Intel seinerzeit vorgestellte „robuste Algorithmus“ liefert somit „Löcher“ bei den Core-IDs. Nun gibt es bei dieser neusten Prozessorgeneration zwar eine schöne Erweiterung des CPUID-Befehls, die alternativ über die Topologie Auskunft liefern kann – aber „Alt-Software“ fällt möglicherweise mit den „Löchern“ erst einmal auf die Nase.
Auch die beworbenen neuen Krypto-Befehle der Prozessoren konnten noch nicht wirklich überzeugen. Zwar sieht der Code damit weit eleganter aus – aber wirkliche Performance-Vorteile in realen Applikationen wie Winzip 14 konnten wir bislang nicht ausmachen (siehe S. 90). Aber gut, das sind nur kleinliche Mäkeleien, ansonsten schlagen sich die neuen Dual-Core-Prozessoren mit ihrem im Gehäuse integrierten Grafikchip recht gut und dürften den Markt der preiswerten Home- und Business-PCs in kürzester Zeit aufrollen. Dafür reichen allein ihre technischen Daten und Preise aus, weitergehende verkaufsfördernde Maßnahmen, wie sie Intel früher offenbar für nötig befand, dürften Schnee von gestern sein.
Doch die Vergangenheit holt Intel auch nach der Versöhnung mit AMD ein, schließlich will die von Obama eingesetzte Chefin der Antitrust-Abteilung im Justizministerium, Christine Varney, auch in den USA mit europäischem Besen kehren. Die Kommissare der Wettbewerbsbehörde FTC sehen jedenfalls genügend Gründe, um Intel noch mal vor den Kadi zu zerren. Ihre Klageschrift ist geradezu eine Kanonade heftigster Anschuldigungen, schlimmer noch als diejenige, die AMD damals verfasst hat, erweitert nun auch um Nvidia und GPUs. Die FTC klagt indes nicht vor einem Bundesgericht, sondern gemäß einer nur selten genutzten Klageform nach Sektion 5 des Federal Trade Commission Act vor einem „FTC Administrative Law Judge“. In den letzten 30 Jahren hat die FTC mit solchen Klagen allerdings nie Erfolg gehabt, stets wurden die Urteile in den späteren Berufungsverfahren vor einem normalen Bundesgericht abgeschmettert. Darauf will Intel-Chef Otellini jedoch nicht warten. Er setzt sich jetzt schon kräftig zu Wehr und bezeichnete die FTC-Klage als einen fehlgeleiteten Vorgang.
So ganz unrecht hat er wohl nicht, insbesondere der von der FTC geforderte Maßnahmenkatalog geht zum Teil weit über sonst übliche Regularien hinaus. Die Kommissare wollen Intel unter anderem zwingen, die Lizenzpolitik zu ändern und x86-Technologie, etwa CPU-Interfaces, an Drittfirmen herauszugeben – Nvidias Chef Jen-Hsun Huang reibt sich da schon die Hände.
Stellvertretend für den Tenor der Klageschrift möchte ich mal einen Punkt aufgreifen, an dem c't indirekt beteiligt ist. So haben wir Anfang 2005 erstmals öffentlich die Unfairness der Intel-Compiler beklagt, die damals bestimmte höhere Optimierungsweihen den Fremdprozessoren vorenthielten. Mit einem einfachen Patch konnten wir diesen Ausschluss unterlaufen, mit dem Erfolg, dass einer der über 20 Benchmarks der SPEC-CPU2000-Suite, 181.mcf, auf einem Opteron um 31 Prozent schneller lief.
Defekte Compiler
Die FTC spricht nun in diesem Zusammenhang von schadhaften (defective) Compilern. Viele Design-Änderungen am Compiler hätten laut FTC allein das Ziel gehabt, die Konkurrenz schlecht aussehen zu lassen. Intel habe dann mit missweisenden oder falschen Statements über Benchmarkergebnisse ihrer Prozessoren geglänzt, ohne darauf hinzuweisen, dass der Performance-Vorsprung weitgehend oder gänzlich durch die eingesetzten Compiler bedingt war. Intel solle nun die defekten Compiler kostenlos durch funktionsfähige ersetzen, Firmen für den Aufwand der Neukompilation entschädigen und deren Kunden informieren, die minderwertige Software gegebenenfalls zu wechseln. Und natürlich dürfe Intel in Zukunft keine derartig diskriminierenden Produkte mehr auf den Markt bringen.
Intel hielt dem immer entgegen, dass man wegen der Produkthaftung nur Features freischalten könne, die auch hinreichend validiert worden sind. Zu speziellen Optimierungen für konkurrierende AMD-Prozessoren mit entsprechend hohem Validierungsaufwand konnte sich die Firma einfach nicht durchringen.
Trotzdem war nach unseren Messungen der von Intels „defektem“ Compiler erzeugte Code zumeist auch auf Opteron-Systemen schneller, als der „heile“ von Microsoft, PGI oder GNU. Anders als Intel – die Firma wollte natürlich wie IBM, Sun und all die anderen auch ihre Prozessoren im besten Lichte erscheinen lassen – haben wir jedenfalls mit verschiedenen Compilern und insbesondere mit kompatiblem Code ohne zusätzliche Spezialoptimierung gemessen.
Kommerzielle Software, die die FTC als Geschädigte wohl im Sinn hat, verzichtet auf spitzfindige Optimierungen ohnehin fast immer – wer will schon, dass seine Software nur auf wenigen Prozessortypen vernünftig läuft? Anders als bei den CPUs war und ist Intel bei den Compilern weit von einer marktbeherrschenden Stellung entfernt; ihr Einsatz ist weitgehend auf High Performance Computing beschränkt. Ansonsten herrscht bei C/C++ unter Windows Microsoft VC und unter Linux GNU C/C++.
Und das mir bekannte, dem Opteron vorenthaltene Feature – eine Cache-Optimierung für schlecht organisierte Datenstrukturen – kam nur sehr selten zum Tragen (eigentlich nur bei dem erwähnten SPEC-Benchmark). Mit dem c't-Patch konnten jedoch performancebewusste Entwickler diese Einschränkung auf einfache Weise umgehen. Da wird nicht arg viel „Defektes“ in freier Wildbahn zu finden sein. Die FTC schießt also mit recht großen Kanonen und so ein wenig über das Ziel hinaus. Dennoch sollte sich Intel überlegen, die Compiler-Entwicklung vielleicht in eine eigene Firma abzuspalten oder zumindest neutraler zu gestalten. Vielleicht wird man dann eines Tages auch das Flag /Bulldozer bei den Intel-Compilern finden. (ps)
