Beziehen Sie sich dabei auf den Deerfield, die leistungsärmere und preisgünstigere Version des Madison?
Dies ist in der Tat ein erstes Beispiel. Man verbreitert die Produktpalette und erzeugt gewisse Überschneidungen.
Natürlich weiß keiner, ob ein Client je 64 Bits benötigen wird, doch könnten Server – sofern die Technologie eine allgemeine Anwendung findet – sie mit Sicherheit nutzen.
Wenn man auf eine verstärkte Überscheidung setzt, muss man auch in der Lage sein, eine Preiskonsistenz zu gewährleisten. Wer glaubt, dass der Itanium aufgrund der Chipgröße oder der Leistung für alle Zeiten ein Nischenprodukt für den High-End-Bereich bleiben wird, der irrt sich.
Planen Sie, die Technologie der physikalischen Adressierung im Xeon auszubauen? Gegenwärtig reicht sie bis 36 Bits, wodurch ein Speicher von 64 GB ermöglicht wird. Werden Sie diesen Wert weiter erhöhen, oder wird der Itanium von oben her diesen Bereich abdecken?
Diese Frage wird mir häufig gestellt. Wir waren hinsichtlich der architektonischen Merkmale der nächsten Generation des Xeon tatsächlich eher vorsichtig, doch sollte man daraus nicht den Schluss ziehen, dass der einzige Vorzug des Itanium in seiner physikalischen 64-Bit-Adressierung liegt. In ihm steckt noch viel mehr Potenzial. Er beseitigt einige der Schwachstellen, die seit langem (an den IA-32-Chips) kritisiert wurden: Die Anzahl der Register ist begrenzt, das Produkt besitzt keine ausreichende arithmetische Kapazität – und wie lassen sich die RAS-Funktionen von Komponenten integrieren?
Ich garantiere Ihnen, dass die IA-32-Produktlinie noch ein langes Leben vor sich hat. Ihr interessantester Aspekt liegt in der Threading-Technologie. Außerdem sind verschiedene Virtualisierungstechnologien in der Entwicklung. Ein erstes Beispiel hierfür war LaGrande (eine zukünftige Sicherheitsfunktion), und es werden weitere Features folgen.
Werfen wir einen Blick zurück: 1991 überdachte man bei Intel das weitere Vorgehen, wobei die Entwicklungsgruppe in Oregon angab, die 32-Bit-Familie auf 64 Bit erweitern zu können, wogegen eine andere Gruppe in Santa Clara den späteren Itanium empfahl. Aus welchen Gründen entschied sich Intel schließlich für den Itanium?
Das war ein heiß diskutiertes Thema. Die Frage lautete: Wie konnten wir eine 32-Bit-Architektur weiter entwickeln? Wie konnte man mit den bestehenden Strukturen und Artefakten der Architektur zurechtkommen? Dabei ging es um die enorme Anzahl an Adressen, Segmentierungen in der Adressstruktur und so weiter und so fort. War all dies möglich, und zwar wie bei der P6-Architektur bereits umgesetzt?
Die P6-Familie ist ein echtes Wunderwerk. Ich bin stolz, mit ihr in Verbindung gebracht zu werden. Wir verwendeten die Kernelemente und konnten daraus einen Großteil der Bestandteile des Pentium III, des Xeon und sogar des Celeron erstellen. Das war fantastisch. Die Frage ist: Wie konnte man diesen Vorgang in einer Umgebung divergierender Desktop- und Großrechnersysteme wiederholen? Ein äußerst kompliziertes Problem. Der Desktopbereich steht weiter unter Preisdruck, während sich die Großrechner wie Server immer stärker auf bestimmte Nischen spezialisieren.
Ich glaube, dass uns einfach irgendwann klar wurde, dass wir tatsächlich das Auseinanderdriften unserer Linien zulassen mussten. Dazu sind eben spezielle Server-Prozessoren erforderlich, ebenso wie der Schritt zu neuen technologischen Generationen – all dies in der Hoffnung, dass eines Tages Querverknüpfungen entstehen.
Es gab da allerdings das Problem der Inkompatibilität der Software. Wie lief das ab? Haben Sie Streichhölzer gezogen, wer den Entwicklern beibringen musste, dass alle Anwendungen neu geschrieben werden sollten?
Ich weiß es nicht. Ich war nicht von Anfang an in der Itanium-Entwicklung tätig. Zuerst stand ich auf der anderen Seite, in der 32-Bit-Gruppe. Und wir hatten sehr gute Argumente, wie unsere Entwicklungsstrategie weiter gehen sollte. Das Unternehmen hat schließlich klugerweise akzeptiert, dass eine Architekturumstellung erforderlich war und die Software-Industrie einbezogen werden musste. Wir haben dafür die grundlegende Technologie um die Compiler herum geschaffen.
Mich würde interessieren, wie Sie die zukünftige Bedeutung des IA-32 Execution Layer einschätzen, der die Ausführung des IA-32-Codes auf einem Itanium ermöglicht.
Bei sich überschneidenden Anwendungsbereichen oder in konsolidierten Umgebungen könnten zukünftige Server älteren Code enthalten, den man nicht in nativen Code konvertieren will. Entsprechende Beispiele gab es in der Vergangenheit schon häufig. Manche Mainframe-Rechner führen 20 Jahre alten Cobol-Code aus, dessen Entwickler nicht mehr verfügbar sind. Entweder haben sie das Unternehmen längst verlassen oder sind im Ruhestand. Man weiß nicht einmal, worauf der Code basiert – man weiß nur, dass er funktioniert.
Den Ansatz der Kompatibilität verfolgten wir also lediglich bei den ersten Mitgliedern der Itanium-Familie, dann haben wir uns, wie geschildert, auf andere Aspekte konzentriert: Eine Software-Umgebung, die mit der Entwicklung der Komponenten mitwachsen kann.
Die Kompatibilität war ohnehin nicht gerade herausragend.
Die Kompatibilität war in Ordnung. Doch die Leistung war, nun ja, ein wenig begrenzt. Jedenfalls haben wir einige wirklich interessante Konzepte zur Erweiterung der Hardware mit anderen Mitteln.
Weitere Artikel zum Thema
Neueste Kommentare
Noch keine Kommentare zu Intels Server-Offensive
Kommentar hinzufügenVielen Dank für Ihren Kommentar.
Ihr Kommentar wurde gespeichert und wartet auf Moderation.