Unterschied GPU und CPU

[hesTeR-]

Hallo zusammen,

kann hier jemand evtl. erklären worin der Unterschied von GPU und einer CPU liegt und warum sich CPUS zb. auf über % ghz betrieben lassen aber GPUs nicht?

Zudem die Frage warum nutzt man GPUs zum minen und nicht CPUs und auch in Autos glaube ich wird Nvidea immer stärker.

Danke

[Baalzamon]

Hallo zusammen,

kann hier jemand evtl. erklären worin der Unterschied von GPU und einer CPU liegt und warum sich CPUS zb. auf über % ghz betrieben lassen aber GPUs nicht?

Zudem die Frage warum nutzt man GPUs zum minen und nicht CPUs und auch in Autos glaube ich wird Nvidea immer stärker.

Danke

Moderne GPUs sind wahre SIMD (https://en.wikipedia.org/wiki/SIMD) Monster. CPUs sind (normalerweise) nicht so spezialisiert, da sie ein viel größeres Aufgabenspektrum performant abdecken müssen.

Das ist imho zumindest der Grund, weswegen sie zum Mining eingesetzt werden.

[Monger]

CPUs sind heute enorm komplexe Maschinen. Da drin gibts Caches, Busse mit unterschiedlichen Taktfrequenzen, verschiedene Abstraktionsebenen...

Auf gewissen Teilstrecken ist die CPU ja weit, weit höher getaktet als auf der Packung steht. Auf anderen nicht.

GPUs sind architekturell viel, viel simpler, und können sich deshalb viele Probleme sparen.

[HisN]

Warum taktet dann ein simpleres Produkt keine 5Gz wie das hochkomplexe? *ggg*

[TheCounter]

Das ist imho zumindest der Grund, weswegen sie zum Mining eingesetzt werden.

Es kommt immer auf den verwendeten Algorithmus an, aber ja.

Deswegen ist man beim Bitcoin Mining auch auf hochspezialisierte ASICs umgestiegen, die nur für diese eine Aufgabe entwickelt wurden und sonst nichts können.

[Opprobrium]

Warum taktet dann ein simpleres Produkt keine 5Gz wie das hochkomplexe? *ggg*

Weil im "simpleren" Produkt tausende simple statt wenigen komplexen Cores stecken.

So hat Big Navi 5x so viele Transistoren wie ein Zen 3 Chiplet mit 8 CPU Kernen (4,15 vs 21 Mrd), und nVidias Ampere A100 hat gar 54 Milliarden. So ein Big Navi Chip zieht dann auch locker mal ein vielfaches des Strombedarfs einer Zen 3 CPU mit zwei Chiplets und I/O Die aus der Steckdose.

Die grad rausgekommenen 6700XT haben ja kleinere Chips, können daher auch höher takten und haben schlechtere Performance/Watt als die 6800er

Auch ist hohe Taktbarkeit nicht immer ein Indikator für hohe Performance, das hatte Intel damals mit dem Pentium 4 eindrucksvoll bewiesen.

[D N]

Wenn man sagt, daß Gpu`s mit einer Fehlertoleranz arbeiten, aber Cpu`s nicht.

Hat das evtl. mit der "Geschwindigkkeit" zu tun ?

[seaFs]

Laienhaft formuliert.

CPUs sind für seriell abzuabreitende Aufgaben da. Berechnungen, die komplex sind und viele Anweisungen haben, sich aber schlecht bis gar nicht parallelisieren lassen. Hier kommt es auch auf Latenzen beim Speicherzugriff an. Wichtig ist, dass die Daten in kurzer Zeit da sind.
Ideal wäre auch heute noch ein einziger, extrem hochgetakteter CPU-Kern. Allerdings ist seit mitte der 2000er Jahre die Fahnenstange so ziemlich erreicht, was den Takt angeht (knapp 8GHz ALU-Takt beim Pentium 4), bedingt durch die Verlustwärme, die man vertretbar abführen kann. Das hat sich bei moderaten 4 - 5GHz eingependelt und die CPUs gingen eher in die Breite (Kernanzahl), um die Rechenleistung zu erhöhen.

Bei GPUs geht es um das genaue Gegenteil: Es ist ein massiv paralleler Prozessor, der versucht, so viel wie möglich weniger komplexe Aufgaben gleichzeitig zu bearbeiten. Deshalb liegt hier der Fokus mehr auf enormer Speicherbandbreite und weniger auf geringen Wartezeiten bei der Datenübertragung vom/zum Speicher.
Der Unterschied ist hier, dass die Verlustleistung in den letzten 15 Jahren massiv gestiegen ist und damit auch immer höhere Taktraten möglich sind.

CPU und GPU sind zwei völlig verschiedene Konzepte zur Berechnung völlig verschiedener Probleme.

[Baalzamon]

Es kommt immer auf den verwendeten Algorithmus an, aber ja.

Deswegen ist man beim Bitcoin Mining auch auf hochspezialisierte ASICs umgestiegen, die nur für diese eine Aufgabe entwickelt wurden und sonst nichts können.
Du hast natürlich recht, dass es vom verwendeten Algorithmus abhängt, da hätte ich mich vielleicht präziser ausdrücken können.

Wenn man sagt, daß Gpu`s mit einer Fehlertoleranz arbeiten, aber Cpu`s nicht.

Hat das evtl. mit der "Geschwindigkkeit" zu tun ?
Was meinst du mit 'Fehlertoleranz'?

Afair benutzen GPUs ganz 'normale' ALUs die ein eindeutiges Ergebnis berechnen und kein 'dein Ergebnis ist irgendwo zwischen x und y'. Fände ich auch arg merkwürdig. Nach allem was ich über Hardwarearchitektur weiss, funktionieren Prozessoren nicht so. ;)

[D N]

Prozessoren sind unterschiedlich und werden auch unterschiedlich programmiert.....

[Baalzamon]

Prozessoren sind unterschiedlich und werden auch unterschiedlich programmiert.....
Das beantwortet meine Frage leider nicht, was du mit 'Fehlertoleranz' meinst.

Afair unterscheiden sich ALUs von CPU und GPU nicht (wenn dann nur marginal, die zugrundeliegende Technik ist dieselbe wie schon seit Anbeginn moderner CPUs).

Natürlich ist eine GPU keine CPU und umgekehrt, aber das war ja auch nicht mein Punkt. Mein Punkt ist, dass die Recheneinheit in CPU oder GPU natürlich dasselbe Ergebnis auspucken, wenn man sie mit denselben Daten füttert.

[D N]

Das beantwortet meine Frage leider nicht, was du mit 'Fehlertoleranz' meinst.

Afair unterscheiden sich ALUs von CPU und GPU nicht (wenn dann nur marginal, die zugrundeliegende Technik ist dieselbe wie schon seit Anbeginn moderner CPUs).

Natürlich ist eine GPU keine CPU und umgekehrt, aber das war ja auch nicht mein Punkt. Mein Punkt ist, dass die Recheneinheit in CPU oder GPU natürlich dasselbe Ergebnis auspucken, wenn man sie mit denselben Daten füttert.
jein

[D N]

kannst keine Cpu mit Gpu-Daten beschicken
also nicht mit den gleichen Instruktionen

umgekehrt natürlich auch nicht

[Tobalt]

GPU habe wie gesagt mehr Kerne und sind mehr auf SIMD ausgelegt. Deshalb können sie viel niedriger takten. Niedriger Takt ist ja erstmal immer zu bevorzugen für maximale Performance. Bei CPUs kann man leider nicht zugrunde legen, dass alles mit dem SIMD Hammer erschlagen werden kann und man wird hier zu hohem Takt gezwungen.

Dieser hohe Takt steigert die Komplexität weil viel mehr pipelining nötig ist.

Würde man GPUs gleichermaßen stark pipelinen, würde der Takt auch entsprechend steigen. Insgesamt wäre die Performance aber schlechter als mehr SIMD bei weniger Takt

[Baalzamon]

kannst keine Cpu mit Gpu-Daten beschicken
also nicht mit den gleichen Instruktionen
Von Instruktionen habe ich auch nie gesprochen. Ich rede über Hardware, konkret über die ALU (https://de.wikipedia.org/wiki/Arithmetisch-logische_Einheit).

Und natürlich kann ich Daten von einer GPU oder CPU berechnen lassen. Ob meine CPU 1+1 rechnet oder meine GPU 1+1 ist vollkommen wumpe. Beide werden als Ergebnis genau 2 auswerfen, ganz ohne Fehlertoleranz.

Ich weiss leider immer noch nicht was du eigentlich sagen wolltest, da du meine Frage was du mit 'Fehlertoleranz' eigentlich meinst und wieso das in Zusammenhang mit der Geschwindigkeit steht, nicht beantwortest.

Um sinnvoll mit dir in einen Dialog zu kommen müsste ich dieses Verständisproblem jedoch erst beseitigen.

[D N]

Bei CPUs kann man leider nicht zugrunde legen, dass alles mit dem SIMD Hammer erschlagen werden kann und man wird hier zu hohem Takt gezwungen.

man kann auch anders programmieren

egal, wenn mann eine Gpu machen lässt, dann ist sie mehrfach effizienter als eine Cpu

Aber eine Gpu muss auch nicht bis in das Byte genau rechnen....

[Baalzamon]

man kann auch anders programmieren
Auch wenn du anders programmierst, ändert das nichts an der Hardware und das GPU nunmal starke SIMD-Rechnerer sind.

egal, wenn mann eine Gpu machen lässt, dann ist sie mehrfach effizienter als eine Cpu
Für Spezialfälle die sich gut parallelisieren lassen (d.h. die Ergebnisse sind unabhägig voneinander berechnbar) ist das richtig, verallgemeinern lässt sich das mMn aber nicht.

Aber eine Gpu muss auch nicht bis in das Byte genau rechnen....
Hast du einen Link der näher beleuchtet was du meinst?

[Palpatin]

Soviel niedriger Takten aktuelle GPUs nicht mehr und es gibt CPU Architekturen die deutlich niedriger als X86 Takten. Als 2004 der Prescott mit 3,8GHZ auf dem Markt kam waren GPUs gerade mal bei ~600MHZ. Aktuell haben Navi 22 mit 2,6GHZ und X86 bei ~5GHZ, ARM bei ~3GHZ......

[D N]

Und natürlich kann ich Daten von einer GPU oder CPU berechnen lassen. Ob meine CPU 1+1 rechnet oder meine GPU 1+1 ist vollkommen wumpe. Beide werden als Ergebnis genau 2 auswerfen, ganz ohne Fehlertoleranz.



Gpu`s werden mit einer Fehlertoleranz prorammiert.

Deswegen sind es Rechenmonster zusamen mit ihrem Aufbau

[D N]

Hast du einen Link der näher beleuchtet was du meinst?

In Bezug zu den Gpu`s weiß das eigendlich jeder

[Opprobrium]

In Bezug zu den Gpu`s weiß das eigendlich jeder

Beste Antwort :up: Weiß auch jeder, daß zwischen d und t eigentlich kaum ein Underschiet exisdierd und so ein Apostroph wichtig ist um ein Plural-S zu kennzeichnen. Vor allem in der deutschen Rechtschreibung.

[D N]

Beste Antwort :up: Weiß auch jeder, daß zwischen d und t eigentlich kaum ein Underschiet exisdierd und so ein Apostroph wichtig ist um ein Plural-S zu kennzeichnen. Vor allem in der deutschen Rechtschreibung.
ein Bit und ein Byte sind der Cpu wichtig, bei einer Gpu wird anders progammiert.....

[Baalzamon]

Gpu`s werden mit einer Fehlertoleranz prorammiert.

Deswegen sind es Rechenmonster mit ihrem Aufbau
Sie sind imho in erster Linie Rechenmonster weil sie stark auf SIMD spezialisiert sind und hauptsählich eben für diese Rechenoperationen benutzt werden.

In Bezug zu den Gpu`s weiß das eigendlich jeder
Ich weiss es nicht.

Wenn das 'common knowledge' ist und du dich da, wie du dich in meinen Augen darstellst, auskennst sollte es dir doch nicht schwerfallen deine Aussagen mit ein paar unabhängigen Fakten zu belegen.

Ich weiss auch immer noch nicht was du mit 'Fehlertoleranz' meinst. Was verbirgt sich denn hinter dem Begriff konkret für dich?

Es mag ja sein, dass man bestimmte Berechnungen in einer früheren Iteration abbrechen kann, da die Zielgenauigkeit ausreichend erricht wurde. Das ist aber inhärent im Berechnungsalgorithmus und hat nichts mit der Hardware zu tun, z.B. gaußsches Eliminationsverfahren vs. newtonsche Näherungsverfahren.

Ist es das was du mit Fehlertoleranz meinst?

ein Bit und ein Byte sind der Cpu wichtig, bei einer Gpu wird anders progammiert.....
das hast du jetzt schon mehrfach behauptet ohne zu konkretisieren was du damit eigentlich meinst.

Du kannst auch CPUs unterschiedlich programmieren, mit Assembler oder C oder Java oder Turbo Pascal. Das ändert aber nichts an der Hardware und wie diese funktioniert, so lese ich deine Posts allerdings. Vielleicht magst du das ja mal kurz aufklären.

[D N]

Du kannst auch CPUs unterschiedlich programmieren, mit Assembler oder C oder Java oder Turbo Pascal. Das ändert aber nichts an der Hardware und wie diese funktioniert, so lese ich deine Posts allerdings. Vielleicht magst du das ja mal kurz aufklären.
Es geht hier um die Unterscheidungen zwischen Cpu`s und Gpu`s.

Das ist beantwortet

Womit man einen Code schreibt ist egal

[Tobalt]

Soviel niedriger Takten aktuelle GPUs nicht mehr und es gibt CPU Architekturen die deutlich niedriger als X86 Takten. Als 2004 der Prescott mit 3,8GHZ auf dem Markt kam waren GPUs gerade mal bei ~600MHZ. Aktuell haben Navi 22 mit 2,6GHZ und X86 bei ~5GHZ, ARM bei ~3GHZ......

Das wurde aber mit massiv höherer Leistungsaufnahme erkauft. Früher war die GPU mal wirklich ein Koprozessor. Heute verbrät die GPU den Löwenteil der Leistung.

Wenn das Powerbudget hart limitiert wär, würde der Takt viel niedriger liegen und die Chips breiter und damit teurer sein. Dass die GPU heute höher takten, liegt nur daran dass die Nutzer eher bereit sind, hohe Stromkosten zu akzeptieren als hohe GPU-Kosten.

Bei CPUs hat man halt fast keine Wahl, außer den Takt zu prügeln.. Nur alle paar Jahre macht es Sinn das Design dezent zu verbreitern, weil der CPU Code mittlerweile wieder etwas paralleler wird.

[Baalzamon]

Es geht hier um die Unterscheidungen zwischen Cpu`s und Gpu`s.
Geht es um die Unterscheidung der Hardware oder der Algorithmen die benutzt werden?

Womit man einen Code schreibt ist egal
Im Grunde bin ich da bei dir.

[D N]

Geht es um die Unterscheidung der Hardware oder der Algorithmen die benutzt werden?



Kannst keine Cpu prorammieren mit einem einzigem bit-fehler

Eine gpu ja

[D N]

Geht es um die Unterscheidung der Hardware oder der Algorithmen die benutzt werden?


Das ist eine gute Frage :)

Würde gern eine Gpu progammieren können, weil es extrem von den aufgabenerledigungen her ist.

Aber es geht nicht.

[Baalzamon]

Kannst keine Cpu prorammieren mit einem einzigem bit-fehler

Eine gpu ja
Ich verstehe immer noch nicht was du damit genau meinst. Ich bin Programmierer, aber ich 'programmiere' keine bit-fehler und wenn doch, dann ist das ein Bug. ;)

Das ist eine gute Frage :)
OK, wenn du selber nicht weisst worüber du eigentlich reden möchtest, dann bin ich nicht überrascht das wir kein für mich befriedigendes Gespräch auf die Reihe bekommen und du meine Fragen nicht beantwortest.


Würde gern eine Gpu progammieren können, weil es extrem von den aufgabenerledigungen her ist.

Aber es geht nicht.
Ich habe schon Algorithmen für GPUs geschrieben. Zugegebenermassen ist das schon ~15 Jahre her, aber die generelle Methode ist immer noch dieselbe.

[seaFs]

Ich finde die Frage vom TE auch interessant und würde mich über ein paar gediegene Hintergrundinformationen freuen.

[Korfox]

Der TE twittert trollt doch. Sowas im Religionsforum :)

[Simon Moon]

OK, wenn du selber nicht weisst worüber du eigentlich reden möchtest, dann bin ich nicht überrascht das wir kein für mich befriedigendes Gespräch auf die Reihe bekommen und du meine Fragen nicht beantwortest.


Das hat man schon nach dem ersten Post gesehen.



Eine GPU rechnet selbstverständlich ebenso genau wie eine CPU. Es hängt halt vor allem davon ab, wie du sie programmierst. Ich denke D N spielt auf die Video-Encoding Funktion von NV Grafikkarten ab, dabei boten diese je nach Architektur und Codec keine Losless Formate an: https://en.wikipedia.org/wiki/Nvidia_NVENC


Ich kann dir jetzt aber nicht sagen, ob da NV einfach ein kürzeres Zahlenformat und damit Rundungsfehler in Kauf genommen hat oder ob es da Probleme gab die Encoding-Algorithmen direkt in den Shadern abzubilden.

[hesTeR-]

Moin,

Ich Trolle nicht, das hier ist auch das wissenschaftliche forum. Leider sind die Erklärungen zumindest für mich noch zu kompliziert.

[D N]

[QUOTE=Simon Moon;12629103]Ich denke D N spielt auf die Video-Encoding Funktion von NV Grafikkarten ab, dabei boten diese je nach Architektur und Codec keine Losless Formate an: https://en.wikipedia.org/wiki/Nvidia_NVENC


nein, diese Chips waren früher auch nur auf den Karten, aber nicht innerhalb der Gpu

[Simon Moon]

Moin,
Ich Trolle nicht, das hier ist auch das wissenschaftliche forum. Leider sind die Erklärungen zumindest für mich noch zu kompliziert.

Ich versuchs mal so knapp wie möglich, aber etwas ausholen muss ich wohl. Also, im Prinzip sind beidese Prozessoren, führen also logische Operationen aus und geben ein Resultat weiter, nur der ursprüngliche Zweck war ein ganz unterschiedlicher. Bei einer CPU ging es anfänglich darum, dass diese möglichst einfach zu programmieren ist. Dadurch entwickelte sich eine Schnittstelle, der Befehlssatz (z.b. x86) der definiert, welche Signale welche Funktion auslösen. Nun war und ist natürlich das Ziel, zu schauen, dass der eigentlich Rechenkern möglichst ausgelastet ist und dafür kamen dann noch weitere Logik-Elemente dazu. Da ist ein Cache, welcher Daten die gleich wieder gebraucht werden können vorhält, eine Einheit sortiert die einkommenden Aufgaben vor und so Zeugs. Dann kommen noch Logiken für spezielle Berechnungen dazu, etwa für Fliesskomma-Zahlen. Schlussendlich ist sind es diese Sachen, welche bei heutigen CPUs den weitaus grössten Teil des Dies ausmachen.



Die GPU kommt nun aber von einer spezialisierten Aufgabe. Als 3D Spiele aufkamen, bemerkte man, dass die CPU für jeden Pixel auf deinem Monitor berechnen musste, welcher Punkt aus dem 3D Model nun hier auftrifft. Der Ablauf war dabei jedes mal derselbe und dadurch wurde es ineffizient wiederholt die ganze komplexe CPU Logik zu durchlaufen. Man nahm nun einfach die notwendigen Rechenschritte die es für einen Pixel brauchte und bildete das in einem Chip nach. Dieser musste nun nicht bei jeder neuen Pixelberechnung erst wieder den Ablauf mitgeteilt bekommen und übernahm einfach stur das Polygonmodell-Model welches von der CPU berechnet wurde. Als nächstes baute man dann 2, 4, 8 usw. dieser Pixel-Pipelines zusammen und die machten eigentlich nichts wesentlich anders als zu schauen, was da nun für ein Teil des Polygons jetzt genau da auf dem Bildschirm trifft, während sich die CPU wieder um alles andere kümmerte. Das ist heute als Rasterazation-Teil bekannt in der Grafikkarte. Bald merkte man aber, dass man das Polygomodell, sowie die Texturen ja sowieso in den Arbeitspeicher der Grafikkarte laden musste, wieso sollte man da nicht auch noch Berchnungen aufführen? Und damit war dann T&L bei der ersten Geforce geboren. Dabei handelte es sich im Prinzip um einen rudimentären Prozessor in der Grafikkarte der dynamisch ins Rendering eingreifen konnte, davor war es allenfalls möglich vordefinierte Funktionen wie Anisotropische Filter dazu zu schalten.



Trotzdem war die T&L Einheit noch sehr rudimentär. Die länge der Abläufe vorgegeben und die Möglichkeiten wie man auf die Szene eingreifen konnte beschränkt. Durch die 4 - 8 Pixelpipelines, welche pro Takt entsprechend einen Pixel berechnen konnten, waren aufwändige Berechnungen an jedem einzelnen Pixel auch gar nicht möglich mit dieser T&L Einheit. Mit der Zeit jedoch konnte man immer mehr und immer komplexere Einheiten, heute Shader genannt, einbauen. Daher sind diese auch entsprechend parallel ausgelegt, damit man die Pixel nicht nacheinander bearbeiten muss. In jedem Pixelshader liegt dann aber im Prinzip wieder eine winzige CPU. Diese können mittlerweile sogar schon richtigen Programm-Code ausführen, siehe z.b. CUDA:

https://en.wikipedia.org/wiki/CUDA


Aus dieser Situation hast du in einer Grafikkarte nun so 1000 - 2000 kleine Rechenwerke, denen man aber noch genau vorgeben muss, was sie rechnenen sollen, während eine CPU damit zwar keine Probleme hat, aber eben nur beschränkt in der Parallelität ist.




nein, diese Chips waren früher auch nur auf den Karten, aber nicht innerhalb der Gpu


Du meinst Decoder-Chips wie mal entsprechende MPEG2 Decoder Karten relativ verbreitet waren?

[hesTeR-]

Danke Simon, das macht es zumindest etwas greifbar.

[00-Schneider]

Warum takten GPUs jetzt nicht so hoch wie CPUs?

bzw.: Wieso brauchen GPUs trotz deutlich weniger Takt eine ähnlich gute Kühlung wie CPus?

[Tobalt]

Weil hoher Takt nur eine Notlösung für nicht-parallel Aufgaben ist. GPU haben das nicht nötig. Sie haben viele parallele Einheiten, die insgesamt dann eben auch 100W+ verbrauchen

[Simon Moon]

Warum takten GPUs jetzt nicht so hoch wie CPUs?

bzw.: Wieso brauchen GPUs trotz deutlich weniger Takt eine ähnlich gute Kühlung wie CPus?


Wärme entsteht dort, wo auch etwas berechnet wird. Eine GPU hat im Verhältniss einfach viel mehr Transistoren die für Logik da sind, während bei einer CPU noch verhältnismässig viel Cache dabei ist.

[Baalzamon]

Wie seaFs (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12628774#post12628774) und Simon Moon (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12629271#post12629271) schon gesagt haben, auch wenn die Komponenten grundsätzlich dieselben sind, ist der Aufbau von CPU und GPU unterschiedlich.

Ein Bild (https://commons.wikimedia.org/wiki/File:Cpu-gpu.svg) dazu:
https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=74658&stc=1&d=1616235531

So wie ich das verstehe:

Die Transistoren in heutige Prozessoren brauchen für jeden Takt eine kleine Stromzufuhr, d.h. mMn je mehr Transistoren auf kleinem Raum und je höher der Takt desto mehr Abwärme wird produziert (ganz grob).

Wie Opprobium schrieb (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12628743#post12628743) haben GPUs heutzutage deutlich mehr Transistoren verbaut als CPUs. Dadurch lässt sich der Stromhunger und die Wärmeentwicklung moderner Grafikbeschleuniger erklären.

Obwohl eine einzlne ALU der GPU dank ihres eingeschränkten Intruktionsset deutlich weniger Transistoren hat als eine CPU-ALU, ist es schlicht die Anzahl an ALUs die den Unterschied macht.

Ich denke die Taktung resultiert daher aus einer Kosten-Nutzen Rechnung bzgl. wieviel Wärme ist sinnvoll abtransportierbar und wieviel Strom darf sinnvollerweise verbraucht werden.

[RavenTS]

Sind die Erläuterungen auf Wikipedia denn nicht verständlich?

GPU: https://de.wikipedia.org/wiki/Grafikprozessor

CPU: https://de.wikipedia.org/wiki/Prozessor