Intel bekommt neue Konkurrenz

 157 total views,  4 views today

Intel konnte sich fast ein Jahrzehnt ausruhen: Mit der Core-Mikroarchitektur hatte man 2006/7 den Erzrivalen AMD abgehängt. Dessen Marktanteil schrumpft seitdem laufend. Gleichzeitig gelang es durch immer stromsparende Prozessoren auch einen Fuß ins Segment der leichten Mobilgeräte zu fassen. Es gibt inzwischen Smartphones mit x86-Prozessoren und bei den Tabletts dominiert Intel sogar. Die Firma ruht sich nicht aus. Die derzeit in 14 nm gefertigten Broadwell-Prozessoren sind noch stromsparender als die 22 nm Generation und die nächste Generatio Skylake wird da sicher nicht schlechter sein. Inzwischen wildert Intel mit dem Galileo und Edison sogar im Arduino Markt. Kurzum: es läuft gut, die Umsätze sind konstant hoch und vor einem Quartal konnte man sogar den 15 Jahre alten Umsatzrekord brechen.

Doch immer wenn es toll läuft, gibt es Konkurrenten die auch ein Stück vom Kuchen abhaben wollen und in den letzten Monaten gab es zwei Ankündigungen die das Zeug haben, Intel in einigen Segmenten Marktanteile abzujagen. Die erste war die Ankündigung von ARM für einen Serverprozessor. ARM ist kein Prozessorhersteller, sondern entwickelt Prozessordesigns, die es dann an Hardwarehersteller verkauft, die diese dann meistens noch spezifisch anpassen z.B. bei Handys den Sende-/Empfangsteil an die verwendete Funkfrequenz und Kodierungsstandard anpassen. ARM bietet mehrere Generationen an, in 32- oder 64 Bit Architektur und mit Taktfrequenzen von einigen Zehn bis über 1000 MHz, die von dem einfachen Mikrocontroller für integrierte Geräte bis hin zum Tablett-PC Prozessor alles abdecken. Selbst Intel war einmal ARM Lizenznehmer und fertigte die XScale Prozessoren, das war zu einer Zeit als man selbst keine entsprechend stromsparenden Prozessoren im Portfolio hatte.

ARM hat einige besonders leistungsfähige Prozessoren schon füer den Servermarkt positioniert. Bisher hat er aber wenig Erfolg gehabt. Der Hauptvorteil der ARM-Architektur ist dass sie viel stärker aufs Stromsparen ausgelegt ist als Intels Prozessoren, besonders die Serverprozessoren der Xeon Linie. Die Leistung hinkt dagegen deutlich den Xeons hinterher. In einem kompletten Server in dem auch Speicher, Chipsatz, Festplatte Strom schlucken, ist der Vorteil deutlich geringer und in der Disziplin Rechenleistung/Watt konnte ARM nicht gegen Intel bestehen. Es gab einige Erfolge, die vor allem darauf beruhten, dass man mehr Prozessoren in eine Höheneinheit packen konnte und so pro Volumen mehr Rechenleistung erhielt, da man keine oder nur eine pasivre Kühlung brauchte.

Nun gibt es einen zweiten Anlauf. ARM bringt eine neue Architektur auf den Markt die nur zum Teil auf der bisherigen ARM-Architektur beruht. Diese wurde in den frühen Achtzigern entwickelt und war ursprünglich eine 32-Bit-Architektur, inzwischen gibt es auch einen 64 Bit Ableger. Der Befehlssatz wurde erweitert, doch im Prinzip könnte man immer noch die alten Programme aus den Achtzigern ausführen. Die neue setzt dies letzte ARM V8 Version ein, aber führt eine neue (Web-ARM, WARM genannt) zusätzlich ein, die nur 16 Bit Breite hat. Sie nutzt eine Untermenge der ARM-Befehle, führt aber neue ein, für die Verarbeitung von 8 und 16 Bit breiten Daten. Besonders auffällig sind die Stringbefehle, die man auch von der x86-Architektur kennt. ARM kannte als RISC-Architektur solche Spezialbefehle nicht. Die neue WARM Architektur verfügt dagegen über Befehle um Speicherblöcke zu kopieren, mit einem Wert zu überschreiben und einen Speicherblock nach einem String zu durchsuchen. Für den Datentyp String wurde das C++-Standardlib Format genutzt (vor dem String zwei Referenzfeldern mit Länge und Referenzzähler, nicht Nullterminiert).

ARM will den größten Teil des Servermarktes anpeilen, das sind nicht Server die in Rechenzentren viel rechnen, sondern die Webserver, Internetknoten, aber auch die Server von großen Internetanbietern und Suchmaschinenbetreiber. Für das Design will ARM z.B. Google, Facebook, Apple und Amazon konsultiert haben. 80% des Rechenzeit ihrer Server, das hat Google veröffentlich entfällt auf die Verarbeitung von Byte und 16-Bit Werten, vor allem Stringoperationen wie Verketten, Durchsuchen, Kopieren. Ein ähnliches Bild gilt bei Webservern, dei statische HTML-Seiten ausliefern aber auch bei aktiven Seiten dominieren Datenbankabfragen, die letztendlich auch Stringverarbeitung bedeuten. Daher hat man die Architektur auf Unicode (16-Bit Breite) und Zeichenkettenverarbeitung optimiert. Da im englischsprachigen Bereich aber auch noch die Byteweise Verarbeitung dominiert beherrscht der Prozessor auch dies. Die Adressierung erfolgt byteweise.

Doch damit alleine kann man sicher keinen Blumentopf gewinnen. Daher setzt ARM auf das schon verfügbare Big-Little Konzept. Dieses wurde für Mobilgeräte entworfen, um deren Batterielebensdauer zu erhöhen. Es wird ein sehr leistungsfähiger Kern mit einem weniger leistungsfähigeren kombiniert. Der erstere, mehr stromverbrauchende, kann bei geringer Last (z.B. telefonieren, MP3 Anhören komplett abgeschaltet werden. Wird er benötigt (Videos anschauen, Spielen) so kann er aktiviert werden. Hier kombiniert ARM allerdings einen 32 oder 64 Bit ARM Kern der neuesten Generation (v8) mit dem WARM (Web-ARM) 16 Bit Kern. Ein Die zerfällt in 4 Sektoren, die jeweils einen 64-Bit, zwei 32-Bit oder acht 16-Bit Kerne aufnehmen können. Der Hersteller kann so die Rechenleistung anpassen zwischen hoher Fließkomma und 32-Bit Integerperformance oder der schnellen Verarbeitung von Strings. Jede Sektion hat eigene Caches. Bei der WARM Sektion hat jeder Kern einen 32 KByte großen Codecache und einen gemeinsamen 2 MByte großen Datencache. Die Taktfrequenz ist auch unterschiedlich hoch. die WARM Kerne arbeiten mit 666, 800 oder 1066 MHz, den Standardfrequenzen für DDR3-RAM. Jede Sektion kann zwei DDR3- Kanäle ansprechen, zusammen bei vier Sektionen also acht. Die ARM-V8 Kerne sind höher getaktet und laufen mit 1,5 oder zweifachem Taktmultiplikator.

Was neu erstellt werden muss ist sie Software. Der Befehlssatz der ARM-Architektur wurde um zwei Befehle erweitert die den Beginn von Codeblöcken für den WARM-Teil und dessen Ende signalisieren. Mindestens ein konventioneller ARM-Kern muss im Die vorhanden sein, da er aktiv ist wenn der Rechner startet. er beinhaltet auch den Cachecontroller der jeweils in die Caches die Codesgemente lädt die zu dem jeweiligen Befehlssatz gehören.

ARM rechnet aufgrund der bisherigen Zusammenarbeit mit vielen Firmen damit einen signifikanten Anteil des Servermarktes zu erobern. Samsung und Qualcomm wollen im Frühling ernste Muster der WARM-Architektur ausliefern.

Deutlich weniger weiß man von dem neuen Kooperationsprojekt von NVidia und Via. Via hat Centaur Technologies übernommen, den einzigen X86-Konkurrenten der nach AMD noch verblieben ist. Ihr Via Namo Prozessor konnte sich jedoch mangels Rechenleistung nie durchsetzen. Auch der neueste Chip, der Via Eden ist nicht der große Renner. NVidia fertigt dagegen Grafikkarten deren pure Rechenleistung um ein vielfaches höher ist als die der leistungsfähigsten Intel-Prozessoren, deren Programmierung aber schwierig ist und besondere Bibliotheken benötigt. Via und NVidia wollen Ende des Jahres einen Prozessor vorstellen, der beides verbindet. Intern weist er sich als x86 Prozessor aus, intern verwendet er aber vom Via Eden nur die Bus-Interfache Unit, Speicherverwaltung und angehängte Einheiten wie den Prefetch. Der Befehlsdekoder übersetzt die x86-Befehle dagegen in Bündel von einfachen befehlen für die integrierte GPU welche die komplette Verarbeitung übernimmt. Deren Zahl ist hje nach Geschwindigkeit variabel. Das kleinste Modell hat 64 Einheiten, bis zu 1024 sollen in der ersten Generation möglich sein. Schon mit 64 Einheiten ist die noch namenlose CPU-GPU schneller als eine 6-Kern Core I7 CPU. Bei mehr als 256 Einheiten wil man auch die schnellsten Xeon CPUs abgehängt haben. Anvisierter Markt ist der von PCs, Notebooks, Tabletts. Hervorgehoben ist die breite Skalierbarkeit des Konzeptes. Anders eine zugesteckte Grafikkarte soll die neue CPU (noch ohne Namen) mehr Leistung auch in Alltagsaufgaben bringen.

Ob dies klappt wird sich zeigen, bisher konnte Via nämlich alle Performanceversprechen ihrer Chips nicht einlösen und die Programmierung von Grafikkarten-GPUs mit CUDA zeigte enorme Schwankungen in der nutzbaren Rechenleistung, stark abhängig vom Problem aber auch der Datenstruktur.

5 thoughts on “Intel bekommt neue Konkurrenz

  1. 1) string Operationen sind nicht mehr notwendig, seit es Befehle für find first zero byte gibt. Damit kann der Speicherinhalt in 64Bit Worten aus dem RAM gelesen werden.

    2) z.Z. kenne ich zwei Probleme die die Leistung von ARM CPUs limitieren:
    2a) die Bandbreite zum RAM
    2b) der Cache, der mit virtuellen Adressen arbeitet.

    zu 2a) das Problem läßt sich mit entsprechend breiter Anbindung des RAM mildern, die Technik ist bekannt, und wurde in den 90ern angewendet (SGI/MIPS hat bis zu 512 Bit breites RAM verwendet).
    Damit braucht man aber entsprechend viele Pins auf dem Chip, und einen entsprechend breiten Pfad zumindest bis zum 2nd level Cache. Solange das Haupteinsatzbgebiet von ARM der embedded Markt ist, ist aber jede Optimierung um mit 16Bit breitem RAM auszukommen interessanter. Thump und Thump2 wurden dafür entwickelt.

    zu 2b) x86 CPUs arbeiten im Cache mit physikalischen Adressen. ARM CPUs arbeiten im Cache mit virtuellen Adressen. Letzteres macht den Cache etwas schneller, und vermindert den Stromverbrauch. Der Nachteil ist, das bei einem Kontextwechsel der gesammte Cache invalidiert werden muß. Bei Sun/SPARC wurde das Problem mit einem Kontext ID Register und einem Kontext ID Feld als Adressbestandteil jeder Cache Zeile gelöst. 3 Bit erwiesen sich in den 90ern als zu wenig, mit 4 Bit ging es gerade so.
    Embedded Entwickler müssen z.Z. viel Aufwand treiben, um das neu Laden des Cache durch Kontextwechsel zu minimieren. (z.B. jeden Echtzeitprozess auf eine eigene virtuelle Adressen legen.)

  2. 16 Bit CPUs in der heutigen Zeit will ich nicht kommentieren.
    Das mit den CPU-GPU-Kombinationen hört sich zunächst mal sinnvoll an, hat aber gewisse Nachteile, wie du ja auch schon in deinem letzten Satz schreibst sind die ziemlich abhängig von den verwendeten Datenstrukturen und eigentlich nur für kurze Programme mit extremen Parallelisierungsgrad geeignet (liegt vielleicht daran das bei diesen riesigen Kernzahlen die Einzelkerne nicht so komplex sein können). Und wenn man schon so etwas baut, warum zur Hölle sollte man dafür x86 kompatible Kerne verwenden? Heutzutage ist der Befehlssatz des Prozessors eigentlich relativ egal, sobald es eine sinnvollen Compiler dafür gibt und x86 ist schon ein ziemliches Geschwür und sicherlich nicht dafür geeignet als Basis für einen massiven Multikernprozessor zu dienen.
    Eigentlich wundert es mich aber schon warum es weder von AMD noch von Nvidia solch einen Prozessor gibt. Mit Athlon oder ARM-Kern für das Betriebssystem, die Ablaufsteuerung oder nichtparallelisierbare Codeteile.

  3. @Andreas
    Die C-Strings werden heute gemieden, die meisten moderenen Stringbibliotheken setzen auf das Modell mit zwei Referenzfeldern mit den Inhalt Zähler (wie oft wird der String im Programm benutzt, geht das Feld auf 0, kann der Speicher freigegeben werden und Längenfeld, das bis zu 2 GByte große Strings erlaubt.

    Damit arbeitet C plus plus, Object Pascal und alle .NET Sprachen

    @Manuel
    Eine CPU ist am besten dann wenn ihre Verarbeitungsbreite der der Daten entspricht. Wenn das nicht der Fall ist wird es umständlich. Nehemen wir den Fall Du sollst im String „Otto Maier“ nach „Maier“ suchen. Die Organisation ist byteweise (8 Bit pro Zeichen)

    Eine 32 Bit CPU lädt nun die ersten vier Bytes „Otto“ in ein Register und die ersten 4 Bytes des Suchmusters „Maie“ in ein zweites – Ein Vergleich wird durchgeführt – keine übereinstimmung. Nun lädt sie die nächsten 4 Bytes “ Mai“ ins Register – wieder keine Übereinstimmung und bei den letzten „er“ und zwei undefinierte Bytes wird sie auch nicht fündig.

    Ihre 32 Bit Befehle nützen ihr hier genausoviel wie ein Bus der eine kleine Parklücke nutzen will, in die ein Smart reinpasst, nämlich gar nichts. Sie muss mühsam Byteweise den Inhalt ihrer Register verschieben und mit Paddingbytes auffüllen wenn sie keine 8-Bit befehle hat wie es bei RISC Architekturen wie dem Arm die Norm ist.

    Fazit: Auch heute lohnen sich noch 8 und 16 Bit CPUS, zumindest wenn man nur Zeichen verarbeiten muss

  4. zu den Vergleichsoperationen:
    wenn man 32Bit Operationen hat und keine schnellen Byte (Oktet) Verschiebeoperationen macht man vier Vergleiche hintereinander:
    Das erste Vergleichsregister enthält „Maie“.
    Das zweite Vergleichsregister enthält „?Mai“.
    Das dritte Vergleichsregister enthält „??Ma“.
    Das vierte Vergleichsregister enthält „???M“.
    Die Stellen mit ? werden beim Vergleich maskiert.
    (Bei litte endian CPUs ist die Reihenfolge der Buchstaben im Register spiegelbildlich.)
    Bei 64Bit CPUs macht man 8 Vergleiche pro geladenem Wort.

    Alternativ, wenn ein find first zero Byte Befehl existiert, kann man ein 32Bit Wort laden, und xor „MMMM“ nehmen. Wenn ein M gefunden wurde, näher prüfen, ansonsten das nächste Wort laden.

  5. Wenn Intel sich nicht anstrengt, den Stromverbrauch von Server-Chipsätzen und anderen wichtigen Server-Komponenten zu reduzieren, wird ARM künftig auch in dem Segment richtig wildern. Ein moderner Web-Server hat heute CPU, ein oder zwei 1-GBit-Ethernet-Ports, eine oder zwei SSDs und N herkömmliche Festplatten. Also nichts, was im idle-Betrieb notwendigerweise größere Mengen an Strom braucht: Die CPUs können alle runtertakten und unbenutzte Kerne ganz abschalten. Ethernet braucht höchstens noch 1 Watt pro Port, SSDs im idle weniger als ein halbes Watt, und die Festplatten kommen auch mit 1 Watt aus (Platte rotiert, aber keine Zugriffe), wenn man Notebook-Platten nimmt. Alle Daten, für die schneller wahlfreier Zugriff wichtig ist, liegen ja auf den SSDs, die herkömmlichen Platten dienen nur noch für Backup oder um große sequenzielle Files (Logfiles etc.) abzulegen.

    Mit anderen Worten: Mehr als 10 Watt idle wären für einen Server nicht nötig. Trotzdem liegen gängige Server eher bei 30 bis 50 Watt idle. Also müssen wir warten, bis ARM kommt, es richtig macht, und den idle-Server gar auf 5 Watt runterholt. Und ja, für Tk-Firmen, die demnächst für die 5G-Netze wahrscheinlich an die 100.000 Basisstationen in der Landschaft verteilen müssen (pro Netzbetreiber!), macht es schon einen Unterschied, ob die Dinger idle dann 20 Watt, 200 Watt oder 2000 Watt ziehen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.