Prozessorgeflüster

Chiphersteller Intel ist kurz davor, seine Spitzenposition bei den Halbleitern zu verlieren. Nach den Hochrechnungen der Auguren wird Samsung jetzt an Intel vorbeiziehen und die Führungsposition so schnell auch nicht wieder abgeben. Wie es bei Wallstreet Online heißt, habe Intel offenbar „seinen Platz in der Post-PC-Ära noch nicht gefunden“. Drohnen, VR, AI, autonome Autos – aber, wo geht die Reise hin?

Das vermeintliche Zugpferd IoT scheint auch nicht so der Renner zu sein. Und so verscherzt es sich Intel verstärkt mit vielen Entwicklern. Nach der kurzfristigen Absage des IDF – für das zahlreiche Entwickler schon gebucht hatten – folgt nun die Einstellung der IoT-Entwickler-Boards Edison, Galileo und Joule (siehe S. 40). Da wird der PR-Chef von Intel-EMEA, Markus Weingartner, sich wohl mittelfristig nach einem Raspi oder was anderem Verlässlichen umsehen müssen, um sein – überaus leckeres – Bier in der Garage weitgehend automatisiert brauen zu lassen, was derzeit ein Edison erledigt [1].

Vielleicht zaubert Intel aber auch demnächst noch was epochal Neues aus dem Hut, soll doch ein „revolutionärer neuer Mikroprozessorkern das nächste Jahrzehnt befeuern und Erfahrungen bieten, von denen wir heute träumen“. So stand es jedenfalls in einer Job-Beschreibung unter Job-ID JR0001863 für einen Pre-Silicon Validation Engineer in Hillsboro für den Next Generation Core (NGC). Die markige Ausschreibung war des Guten wohl zu viel und so ist sie schnell wieder aus dem Web verschwunden.

Ob bei NGC wohl die Ideen mit Translation und Optimierung zur Laufzeit mit einfließen sollen, die Transmeta-Gründer Dave Ditzel einst beim Crusoe-Prozessor Anfang des Jahrtausends eingebracht und später bei Intel weiterentwickelt hat? Soweit man weiß, hatte sein Team bei Intel ein Design mit hervorragenden Simulationswerten vorgelegt, aber offenbar war es zu revolutionär für die konservativen Chefs – es verschwand in der Schublade und Ditzel und mehrere seiner Mitkämpfer verließen enttäuscht die Firma und widmeten sich anderen Aufgaben.

Ditzel kam jetzt zur ISC 17 (siehe S. 18) nach Frankfurt, um in der Session über Speichersysteme in HPC als President und CEO von Esperanto Technologies über „revolutionäre“ neue Möglichkeiten zu sprechen, Energien vor allem bei der 3D-Speicheranbindung einzusparen. ThruChip Interface (TCI) – so heißt sein Vorschlag für drahtlos via Magnetfeld induktiv angekoppelte 3-D-Stacks von Speicherchips. Bei 7-nm-Fertigung soll TCI nur ein Siebzigstel der Energie aktueller 3D-Technik mit Silizium-Durchkontaktierung (Through Silicon Via:TSV) verbrauchen. Die technischen Details zu TCI hatte Ditzel schon auf der Hot-Chips 2014 vorgestellt, neu sind seine revolutionären Energiedaten.

Nebenbei rührte Ditzel auch stark die Werbetrommel für RISC V als eine hochqualitative, lizenz- und gebührenfreie RISC-ISA, für die es mit BOOM-4w (Berkeley Out-Of-Order Machine) inzwischen eine sehr performante und energieeffiziente Out-of-Order-Implementierung gibt.

Derweil rütteln an Intels gutem Ruf aber auch andere Dinge, etwa missglückte Stapelläufe von offenbar noch unfertigen Produkten wie dem Skylake X (siehe S. 102) oder gar Bugs, so wie der beim Skylake (inklusive X), den ich schon im vorvorigen Prozessorgeflüster als „problematisch“ eingestuft hatte. Er tritt gelegentlich unter „komplexen mikroarchitektonischen Bedingungen“ bei eingeschaltetem Hyper-Threading und bei bestimmten 8- und 64-bittigen Registerzugriffen innerhalb einer kurzen Schleife auf. Damals brachte ich noch die Hoffnung zum Ausdruck, dass die BIOSse den möglichen Workaround auch eingebaut haben – so siehts aber derzeit kaum aus, insbesondere nicht beim Kaby Lake, der ebenfalls vom Bug betroffen ist.

Die OCaml-Leute vom Debian-Projekt hatten bei ihrem Compiler schon Anfang des Jahres gelegentliche mysteriöse Segment-Fehler festgestellt, die nach Abschalten von Hyper-Threading spurlos verschwanden und bestimmte Code-Segmente als wahrscheinlichen Verursacher ausgemacht. Ich hab den verdächtigen Code mal mit gemischten rax- und ah-Operationen unter Windows nachprogrammiert und stundenlang einen Skylake Core i7 6700 auf allen „Pötten“ getriezt, bekam immerhin einmal eine mysteriöse Exception. Für Skylake-Systeme im Sockel 1151 mit CPUID 0x506E3 und 0x406E3 (Mobile-Version) hat Intel im Mai einen fehlerbereinigenden Microcode 0xBA in Microcode-20170511.tgz für Linux bereitgestellt, wobei je nach Distribution die Einbindung etwas unterschiedlich verläuft. Bei Kaby Lake (0x806E9 und 0x906E9) sollen es die Revisionen 0x5D/0x5D richten, die aber noch nicht in Intels Microcode-Datenbank enthalten sind.

Wer Windows fährt und nicht warten will, bis Microsoft (oder besser noch die Board-Hersteller) ein Update liefern, kann mit dem VMware-Treiber cpumcupdate32/64.sys den neuen Microcode aus der Linux-Datenbank transient nachladen, so wie in „Prozessor-Patches“ in c’t 7/16 beschreiben. Oder man muss eben Hyper-Threading im BIOS-Setup komplett abschalten.

SPEC CPU2017

1989, 1992, 1995, 2000, 2006 – eigentlich war von der Standard Performance Evaluation Corporation (SPEC) geplant, so alle vier bis fünf Jahre eine neue Version der CPU-Benchmark-Suite herauszubringen, doch diesmal hat es geschlagene elf Jahre gedauert, bis sich nach langem zähen Ringen die Mitglieder auf eine aktualisierte Version, auf Laufregeln und Fair Use geeinigt haben. Kein Wunder, sind doch Firmen wie Intel, AMD, ARM, IBM, Oracle, Cavium, Nvidia, HPE, Dell EMC, Lenovo, Inspur … alle unter einen Hut zu bringen – und das dauert. Heraus kommt dann aber jedes Mal eine ziemlich einzigartige, quelloffene Benchmark-Suite, hinter der ein maximal breiter industrieller und akademischer Rückhalt steht und der, wie CPU2006 mit über 44.000 zumeist sogar kostenpflichtigen Einreichungen zeigt, auch sehr intensiv genutzt wird.

Wie gehabt teilt sich die Suite in Integer und Gleitkomma auf, es gibt jetzt aber unterschiedliche Codepfade für Geschwindigkeit (speed) und Durchsatz (rate).

SPECint bietet wieder ein breites Spektrum von Standardaufgaben, wie Videokompression, Routenplanung oder Compiler. Neu ist etwa ein Sudoko-Löser (in Fortran!). SPECfp enthält überwiegend Applikationen aus dem HPC-Bereich (in C/C++ und Fortran), auch Ray-Tracer (povray) und 3D-Rendering (Blender).

Multithreading per OpenMP und Autoparallelisiering sind für speed erlaubt, OpenMP ergibt aber nur bei SPECfp wirklich Sinn, da nur hier alle Applikationen das in HPC sehr verbreitete Multithreading Framework unterstützen.

Traditionell nimmt man einen sehr alten SPARC-Rechner (Sun Fire V490) als Vergleichssystem, sodass es recht unwahrscheinlich ist, Zahlen unter 1 zu bekommen.

Für eine Handvoll Systeme vom Desktop PC (ASUS Z170M-PLUS mit Intel Core i7-6700K) bis zum HPE Superdome (384 Kerne, Xeon E7-8890 v4) wurden auf spec.org zum Start schon Ergebnisse veröffentlicht. Für neue Einreichungen gilt erst einmal für einen Monat eine Pause („Dark Period“). Spannend wär ja AMDs Epyc – AMD hat bei meinem Besuch in Austin tolle CPU2017-Werte angedeutet, aber auf die muss man noch ein wenig warten. (as@ct.de)