Evolutionäre Leistungserhöhung von PCs

Von Andreas Buschmann

Nach dem Motto, wir wissen alles besser als die Hersteller, hier ein kurzer Abriß, wie man in den nächsten Jahren PCs bauen kann, die mehr Performance haben als PCs heute.

Erst mal vorab, ich bin voreingenommen, und mag PCs nicht so besonders. Ich finde die Architektur häßlich. Trotzdem bin ich der Meinung die PC Architektur hat noch Reserven:

Ich beschäftige mich hier primär mit PC Servern, da ich mich damit besser auskenne als mit Spiele Rechnern.

Erst mal einige Limits:

  1. Die Taktfrequenz bei x86 CPUs ist wie bei allen anderen CPUs an ein oberes Limit im Bereich 3-4GHz gestoßen. Wenn man versucht eine CPU schneller zu takten wird sie zu heiß.
  2. Die mögliche Leistung, die man zuverlässig kühlen kann ist seit 10 Jahren auf 100-130 Watt pro Sockel beschränkt. Wenn man mehr Leistung verwenden will, braucht man eine Wasserkühlung, die das komplette Rechnersystem sehr viel komplexer macht.(Ich weiß das die (Wasser-)Kühlsysteme für Übertakter noch bezahlbar sind, aber wenn man Server bauen will, die mit Wasser gekühlt werden, und die zuverlässig sein sollen, muß das gesamte Serverdesign sowie das Rackdesign darauf ausgerichtet sein.)
  3. Die Strukturbreite hat heute 32nm erreicht (für Teile der Chips). Ein Verkleinerung auf 25nm bzw. 23nm ist in Arbeit.Für eine Verkleinerung auf 18nm wird geforscht, aber die UV Lithographie stößt an ihr Limit, und muß vermutlich durch eine andere Technik ersetzt werden. Damit werden die Produktionsanlagen für die 18nm Technik wieder sehr viel teurer als die z.Z. genutzten Produktionsanlagen.d.h. u.U. kann nur ein Konsortium aus IBM + Intel + weiteren Herstellern es sich überhaupt leisten eine solche Anlage zu bauen.Oder es dauert einfach deutlich länger als bisher, bis eine Anlage für die nächst kleinere Technologie bezahlbar wird.

    d.h. ich nehme an, daß es in nächster Zukunft eine Strukturbreite geben wird, die etliche Jahre lang nicht durch die nächst kleinere Strukturbreite abgelöst wird.

  4. Alle Server heute, und insbesondere alle PC basierenden Server sind limitiert über die Zeit in der ein Wort aus dem RAM geholt werden kann.
    Ein RAM Zugriff dauert etwa 100-200 CPU Zyklen.
    Ein L2 Cache Zugriff dauert etwa 25 CPU Zyklen.
    Ein L1 Cache Zugriff dauert etwa 10 CPU Zyklen.
  5. Alle Server heute, und insbesondere alle PC basierenden Server sind limitiert über die Bandbreite, mit der Daten aus dem RAM gelesen werden können.

Welche Optionen gibt es jetzt im Rahmen dieser Limits:

  1. Erhöhung der Bandbreite zum RAM: Jetzt wo der RAM Controler bei AMD und Intel wieder auf den CPU die gewandert ist, gibt es die Möglichkeit mehrere komplette RAM Anbindungen auf einem CPU die zu implementieren.Ein Beispiel ist die Sun T2000, die vier komplette DDR2 RAM Anbindungen hat, die jeweils mit zwei oder vier Modulen bestückt werden können.Mehrere RAM Anbindungen auf einem CPU die zu implementieren ist möglich, und vervierfacht die Bandbreite zum RAM, ist aber kostspielig:
    1. Die vielen zusätzlichen Pins benötigen Fläche auf dem CPU die. Dazu muß man entweder den CPU die vergrößern (teuer), oder andere Komponenten weglassen. (Verkleinerung des Cache oder 4 CPU Kerne statt 6 Kerne.)
    2. Die vielen zusätzlichen Pins benötigen Platz auf dem Mainboard oder dem CPU Board. d.h. die Anzahl der Layer auf dem Board kann sich verdoppeln. Sun hat für das CPU Board der T2000 ein 24 Layer Board benötigt, und das Mainboard in ein CPU Board und ein I/O Board geteilt, wobei das letztere nur 12 Layer benötigte.Mehr Layer machen ein Motherboard deutlich teurer.
    3. Die vier RAM Anbindungen müssen immer alle gleich bestückt sein, sonst funktioniert das Interleaving nicht.Um die Komplexität der RAM Controller etwas zu vermindern, müssen alle RAMs gleich groß sein, und alle das selbe Timing haben.Üblicherweise ist sind nur zwei Ausbaustufen möglich:
      – Eine RAM Bank an jedem der RAM Controller bestückt
      – Zwei RAM Bänke an jedem der RAM Controller bestückt
      und beide Bänke müssen gleich bestückt sein.

      d.h. es können nur eine sehr eingeschränkte Auswahl an RAM Konfigurationen in einem Server unterstützt werden.

      d.h. für ein RAM Upgrade müssen ggf. alle RAM Module ersetzt werden.

      Sun hatte damals mit der T1000 einen Server auf den Markt gebracht, bei dem zwei von den vier RAM Controlern deaktiviert waren. Möglicherweise wurden dazu Ausschuß CPUs verwendet, bei denen nicht alle RAM Anbindungen funktioniert haben.

    • Dies bringt höhere Kosten für die längere (Vor-)Finanzierung der CPUs, und für die Lagerhaltung von mehr montierten Servern mit sich. (um verschiedene CPU Geschwindigkeiten liefern zu können.)

Die hohe Anzahl von Pins macht es u.U. notwendig, daß die CPU auf dem Motherboard oder dem CPU Board verlötet ist.

  • Das bringt im PC Geschäft, wo die CPUs einen hohen bis merklichen Anteil am Endpreis eines Servers haben, das Problem mit sich, daß die CPU eher ins System integriert werden muß, als wenn sie gesteckt würde.
  • Für diese höheren Kosten bekommt man nun ein System mit der vierfachen RAM Bandbreite, wie einen z.Z. üblichen PC Server. d.h. im besten Fall die vierfache Leistung, ggf. auch die vierfache Menge an verfügbarem RAM.
  • Die große Frage ist, lohnt sich das finanziell für den Anbieter? Oder ist das ein Nieschenprodukt?
  • z.Z. kann ein Teil dieses Marktes bedient werden, indem der User einen vier Sockel Server kauft statt einen single Sockel Server; bzw. einen acht Sockel Server statt einen zwei Sockel Server.
  • Der große Vorteil dieser Option ist, daß sie keine Anpassung am Betriebssystem erfordert.

1-2 10GBit Ethernet Interfaces auf die CPU verlegen:

Der Platzbedarf für diese Interfaces ist deutlich kleiner als für einen RAM Controller, d.h. eine kleine Verkleinerung des Cache oder eine kleine Vergrößerung der Chipfläche könnte ausreichen.

  • Das lohnt sich aber nur für Server, die diese 10GBit Interfaces auch benötigen.
  • Die CPU wird dabei immer mehr zu einem SOC (System on a Chip), da high speed Interfaces vom Bus in die CPU selbst wandern.
  • Mit dieser Änderung bleibt auf dem Bus mehr Bandbreite für den Plattenzugriff oder für weitere 10GBit Ethernet Interfaces frei.
  • Hier wird nicht der komplette Ethernet Controller in die CPU integriert, sondern nur die Teile, die sich problemlos in CMOS Technik fertigen lassen. Der PHY ist immer ein extra Chip, der in einem anderen Prozeß gefertigt wird als die CPU.
  • Diese Option erfordert ggf. einen neuen Treiber für 10GBit Ethernet, ggf. reicht aber eine Modifikation an einem vorhandenen Treiber aus.

Das größte Problem mit dieser Option ist, daß ein neuer Sockel erforderlich ist.

Einführung einer Kontext ID in der CPU:
Eine CPU ohne Kontext ID muß beim einem Kontextwechsel den Cache (wenn virtuell) und die TLB Einträge verwerfen. Bei der PC Architektur werden physikalische Adressen gecached, d.h. nur die TLB Einträge müssen gelöscht werden. Das neu Laden der TLBs kostet aber schon genug Zeit, um eine PC CPU egal ob von Intel, AMD oder VIA für harte Echtzeit Anwendungen unbenutzbar zu machen.
Eine Kontext ID ist eine kleine Zahl, die mit einem Kontext assoziiert wird, und Bestandteil eines TLB oder Cache Eintrags ist. Eine typische Größe ist 8 Bit für 15 Kontexte oder 10 Bit für 63 Kontexte. Da mittlerweile alle PC CPUs Hyperthreading können sind in der Regel 8 zusätzliche Bits ausreichend um genug Kontexte zu unterstützen.

Funktion: Jedem Prozeß, der vom Betriebssystem lauffähig gemacht wird, wird eine Kontext ID zugewiesen und in das Kontext ID Register geladen. (00 oder FF) steht für ohne Kontext ID. Wenn die CPU jetzt eine TLB Eintrag neu lädt (oder bei virtuellem Cache eine Cache Zeile), dann wird dem Verwaltungs Eintrag für diesem TLB Eintrag (oder Cache Zeile) die Kontext ID hinzugefügt. Bei einem Vergleich einer Adresse mit einem TLB Eintrag wird die Adresse logisch um die Kontext ID verlängert. Das bewirkt, das nur Adressen mit der selben Kontext ID matchen. Der Vorteil ist, daß bei einem Prozesswechsel nicht die komplette TLB invalidiert werden muß, sondern daß TLB Einträge für mehrere Prozesse gleichzeitig in der CPU bleiben können. Damit werden Prozesswechsel schneller.

Wenn ein Prozeß lauffähig gemacht werden soll, und keine freien Kontext IDs mehr vorhanden sind, muß mindestens eine Kontext ID recyclet werden. Dazu sind Befehle erforderlich, die entweder die ganze TLB löschen, oder alle Einträge mit einer bestimmten Kontext ID. Danach müssen die TLBs für den neuen lauffähigen Prozeß neu aus dem RAM geladen werden.

  • Vorteil: Prozesswechsel werden schneller.
  • Vorteil: Applikationen müssen nicht angepaßt werden.
  • Nachteil: Alle Betriebssysteme müssen angepaßt werden.
  • Der Entwicklungsaufwand ist nicht ganz klein, und die Verifizierung des Memory Management ist aufwendig.
  • Bei der Produktion entstehen keine höheren Kosten, da die benötigte Fläche eher klein ist.
  • Vorteil: Wenn man die Kontext ID einmal hat, kann man auch darüber nachdenken virtuell adressierten Cache zu verwenden. Der hat aber so große Auswirkungen auf das Memory Modell, daß man dabei die Rückwärtskompatibilität für Software verliert.

11 thoughts on “Evolutionäre Leistungserhöhung von PCs

  1. Das größte Nadelöhr in einem PC ist wohl nicht die CPU, sondern der RAM. Seit Jahren steht der bei der gleichen Netto-Geschwindigkeit. Mit DDR2 und 3 hat sich zwar die Taktfrequenz recht werbewirksam erhöht, was aber durch entsprechend mehr Wartezyklen wieder ausgeglichen wird. Die Netto-Taktfrequenz steht seit Jahren bei rund 100MHz, bei billigerem RAM noch deutlich darunter.
    Eine Verbesserung könnte erreicht werden, wenn der RAM gleich mit in die CPU wandert. Chipintern wäre eine größere Busbreite auch kein so großes Problem wie extern.
    Klar kostet das mehr Chipfläche, aber für viele Anwendungen würde schon ein CPU-Kern reichen, die restliche Fläche könnte dann für RAM verbraten werden.

    Technisch wäre es auch durchaus möglich, inerhalb der RAM-Chips die Busbreite zu erhöhen. Dann könnte der hohe externe Bustakt auch wirklich genutzt werden, und steht nicht nur als Werbegag auf dem Papier. Aber die Hersteller wollen eben nicht.

  2. Die Festplatte ist ein ebensolches Nadelöhr, mindestens. Die Transferraten sind seit 10 Jahren nicht mehr wesentlich angestiegen, ebenso die mittleren Zugriffszeiten und Latenzzeiten.
    Lediglich die Schnittstellen wurden werbewirksam verschnellert. UDMA133 – SATA I – II -III. Dabei erreichen heutige Desktop-Festplatten real gerade mal einen Durchsatz, der UDMA100 ausreizt.

    SSDs erreichen schon beeindruckende Verbesserungen (besonders bei den Zugriffs- und Latenzzeiten), sind aber pro GB noch >20mal so teuer.

  3. Betreffen RAM Geschwindigkeit:
    Das RAM ist in den letzten 10 Jahren etwas schneller geworden, aber unwesentlich.
    Daher ja mein Vorschlag die Bandbreite zum RAM zu vervierfachen.

    Das RAM auf den CPU Chip zu verlagern ist bei embedded CPUs Standart.
    Das Problem ist, daß nicht mehr als 8-32 MByte auf den CPU Chip passt, also wird es als Cache genutzt.
    Für (preiswerte) DRAMs braucht man andere Prozesse als für die CPU selbst, daher ist das RAM auf den CPUs immer deutlich teurer als externes RAM.
    Wenn auf dem Chip nur eine CPU bleibt, statt 4-6, wird das auf dem Chip verfügbare RAM nicht mal verdoppelt.

    Auf den RAM Chips ist die Busbreite seit Jahren > 1024 Bit. Daher kam ja schon vor 15-25 Jahren mehrfach der Vorschlag, man möge eine kleine CPU auf jeden RAM Chip bauen. Konnte sich nie durchsetzen, die single thread Performance ist lausig im Vergleich zu einer Sun T1 CPU.

    Die Festplatte ist auf Servern nicht wirklich ein Problem.
    Wenn die Bandbreite nicht ausreicht macht man RAID0 / RAID5 / RAID6 über hinreichend viele Platten. Damit haben wir 1999 ohne Probleme unkomprimiertes HDTV auf einem Festplattenrecorder aufnehmen und abspielen können. (160 – 240 MByte/s)

    Probleme macht die Zugriffszeit der Festplatten bei Datenbanktransaktionen.
    Da werden teilweise über hundert Festplatten in einem System betrieben, und von jeder Platte nur 1-10 GByte genutzt.
    Auf Datenbankservern und großen Fileservern helfen SSDs als Cache richtig gut,
    weil plötzlich die Turnaround Zeiten für die Schreibzugriffe deutlich kleiner werden. ZFS ist ein richtig gutes Verkaufsargument für Solaris.

    Auch ich hatte Kunden, denen die (SATA) Plattensysteme beim Schreiben zu langsam waren.
    Wenn dann statt dessen SAS Platten eingebaut wurden, oder die Anzahl der Platten verdoppelt bis verdreifacht wurden ging alles schon viel besseer.

    Ein großes Problem bekommt man jedoch, wenn der RAID Controller nicht gut genug ist. Ich habe mindestens ein Array, das ich nicht gleichzeitig lesen und schreiben darf, da dann die Performance auf 10% einbricht.

  4. Bei den Fakten ist eine Zahl falsch oder zumindest irreführend: Bei L1-Cache-Hit sind heutige CPUs deutlich schneller als 10 Zyklen. Soweit ich mich jetzt nicht total täusche, können Intel-CPUs pro Takt sogar zwei Reads aus dem Daten-Cache und einen Read aus dem Code-Cache abwickeln.

    Allerdings kommen da noch Latenzen hinzu, für die Address-Berechnung, und für den Transfer des Requests zum Cache, und für den Ergebnis-Transfer zurück. Je nach konkreter Anwendung spürt man diese Latenzen – dann kommt man tatsächlich auf 5 bis 10 Zyklen – oder nicht.

    Was in den letzten Jahren zudem deutlich schneller geworden ist, ist die maximale Datenrate zwischen CPU und Hauptspeicher. Zudem wird eine Art „Mini-Cache“ auch in den Hauptspeicher verlagert, der zumindest Zugriffe auf die aktuelle Speicherseite deutlich beschleunigt. Schließlich wird die erhöhte Speicherbandbreite genutzt, um auf Verdacht Speicherbereiche vorzuladen, die wahrscheinlich bald benutzt werden können.

    Kontext-IDs scheinen mir ein interessantes Konzept. Die Frage ist aber, ob dieses bei 64-Bit-CPUs überhaupt nötig ist: Stattdessen kann ja einfach das Betriebssystem den Prozessen disjunkte virtuelle Speicherbereiche zuordnen. Das Mapping dieser virtuellen Adressen zu realen Adressen ist dann immer eindeutig. In der Folge muss man also auch beim Kontext-Switch keine TLB-Einträge vernichten.

    Da es in der CPU (einige wenige) Register gibt, mit denen die überhaupt zugreifbaren Speicherbereiche bezeichnet werden, sollte auch mit diesem Konzept die gegenseitige Sicherheit vor Speicher-Überschreibungen gewährleistbar sein.

    Probleme kann es allerdings beim Laden von DLLs geben: Es ist ja durchaus sinnvoll, DLLs in allen Prozessen auf dieselbe Adresse zu laden, um nur einmal relozieren zu müssen. Dann muss man aber in den veränderbaren Datenbereichen der DLLs copy-on-write verwenden, und dann braucht man doch wieder verschiedene reale Adressen für dieselbe virtuelle Adresse…

    Aber auch hier sind Lösungen denkbar, die freilich auch in den Compiler eingreifen: DLLs könnten mit unveränderlichen Teilen in einen gemeinsamen Speicherbereich und mit veränderlichen Teilen in den privaten Speicherbereich geladen werden. In einem Register könnte dann die Basisadresse dieses privaten Speicherbereichs stehen. Natürlich dürfen auf diesem Weg nur DLLs geladen werden, die für alle lesbar sind; im gemeinsamen Speicher sind natürlich alle DLLs sichtbar, die von irgendeinem Prozess geladen wurden.

    Kai

  5. Ach ja, noch ein Nachtrag: Mehrere Speicherkanäle sind inzwischen ja ebenfalls Standard: Bis zu drei bei Intel (weswegen der Sockel 1366 auch so viele Pins hat …) und zwei bei AMD. Witzigerweise erlauben dann viele Intel-Boards auch noch drei Module pro Speicherkanal, so dass man bei einem Dual-CPU-Board dann im Vollausbau auf so krumme Speicherwerte wie 72 GB kommt: 2 CPUs x 3 Kanäle x 3 Module x 4 GB = 72 GB.

    Kai

  6. Ich denke man muss unterscheiden. Bei einigen Bemerkungen hier wurden einige Dinge durcheinander geworfen, vielleicht auch weil „Server“ nicht genau beschreibt was die Maschine macht.

    Wenn es ein Datenbankserver ist, dann profitiert er von vielen und schnellen Festplatten.

    Ein Webserver braucht dagegen viel RAM, zumindest wenn vorwiegend statische Seiten ausgeliefert werden. Jeder Seitenaufruf initiiert einen Prozess.

    Datenbank- und Webserver können recht gut Mehrkern-CPU’s auslasten weil die meistens viele anfragen haben und die gut verteilen können.

    Bei Anwendungen wo gerechnet werden muss ist es deutlich komplizierter. Im Prinzip diktiert die Anwendung die Anforderungen.

    Im Prinzip hat Andreas recht – höhere Bandbreite gleich mehr Dampf. Ich habe das glaube ich auch schon mal im Blog aufgegriffen. Das gibt es auch schon bei Grafikkarten. Der GT100 Chip bindet seinen DDR5 Speicher mit 384 Bit an. Ich glaube irgendwo habe ich auch schon von 512 Bit Bussen gelesen.

    Um aber mal vom Server auf den PC zu springen: Wir haben hier seit einigen Jahren das Problem, dass eigentlich Mehrkern-CPU’s kaum ausgelastet werden können. Es gibt zwar zig Prozesse bei einem heutigen Multitasking Betriebssystem aber jeder braucht meist nur wenig CPU Power. Abseits der „üblichen“ Paradeanwendungen wie Videoschnitt oder Rendering (Wie viel % der User machen das?) ist es praktisch kaum möglich Anwendungen zu parallelisieren – beim Office kann der Spellchecker und die Neuformatierung im Hintergrund laufen – aber das wars dann auch. Ansonsten ist die Anwendung abhängig von den Eingaben und wartet.

    Beim Browser kann man jede Seite in einem Prozess auslagern, den Flash Player ebenso, aber wie viele Seiten liest man gleichzeitig und wie lange beschäftigt das Laden einer Seite den Prozessor?

  7. Eine Möglichkeit zur weiteren Auslastung von Mehrkern-CPUs ist mir gerade auch noch eingefallen: Spracherkennung. Und zwar so, wie sie in den alten Star Trek Serien zu sehen ist, oder bei den (An-)Droiden in Star Wars.
    Wenn man Computer irgendwann so baut, das sie fast ausschliesslich per Sprache gesteuert werden können, wird man dafür zwar auch hoch spezialisierte Chips einsetzen, die es ja im übrigen auch schon gibt. Aber soweit ich informiert bin, brauchen heutige Spracherkennungsprogramme die nicht, sondern verlassen sich auf die Rechenpower der CPU.

  8. Tja aber selbst in Star-Trek haben die das Interface von der „orignal“ Serie zur „Next Generation“ umgestellt von Spracheingabe auf Touchscreens.

    Im ernst: Ich habe das vor mehr als 10 Jahren mal ausprobiert. Das klingt toller als es ist. Selbst wenn sie zu 100% funktionieren würde finde ich hemmt es wenn man im Hintergrund weiss, der Computer hört alles mit. Bedienung läuft meistens schneller über Maus/Shortcut als über Kommandos und es wäre ja schon ein Fortschritt wenn die Computer schon Umgangssprache verstehen würden. Wie maschinelle Übersetzungen zeigen verstehen sie das bis heute nicht.

    Mir würde schon reichen wenn ich für mein aktuelles buch mal folgendes in den Browser eintippen könnte: „Ich suche ein hochauflösendes Bild der S190A Kamera von Skylab von Cape Cennedy“.

    Schon daran scheitern heute Rechner.

  9. In einem Muß ich Kai wiedersprechen: RAM ist immer noch genau so langsam wie vor 10 Jahren. Schneller geworden ist nur der Bustakt, aber was nützt das? Ein Fahrrad wird ja auf der Autobahn auch nicht schneller.

    Bei dem neuen Sockel G34 von AMD gibt es sogar schon 4 Speicherkanäle. Viel mehr dürfte dann aber in absehbarer Zeit nicht drin sein.
    Bei einem fasse ich mir allerdings an den Kopf: Die Sockel G34-CPUs hat jeder bessere Händler im Angebot, aber kaum einer auch ein dazu passendes Board. Richtig tolle „Fachleute“.

Schreibe einen Kommentar zu Hans Antworten abbrechen

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.