Warum Prozessor-Chipfläche begrenzt



  • Hallo Leute,

    bei dem Unterschied zwischen CPU und GPU liest man in der Regel so etwas wie

    "bei CPUs wird die vorhandene Chipfläche fokussiert für Caches, Speicherverwaltung etc genutzt"

    genau wie

    "bei GPUs wird die vorhanden Fläche fokussiert für viele parallele Ausführungseinheiten benutzt".

    Was ich mich jetzt frage ist, warum man die Chipfläche nicht einfach vergrößert und von den Vorteilen beider Architekturen profitiert.
    Das einzige was ich hierzu finden konnte ist, dass solch ein Chip wesentlich teuer ist (hat hier jemand von euch eine Vorstellung wie viel teurer?) und dass die Übertragungswege rein physikalisch länger werden was für länger Übertragungszeiten sorgt (weiß auch hier jemand wie stark sich das bemerkbar machen würde?).
    Sind das die einzigen Gründe?

    Grüße 🙂



  • Gast123 schrieb:

    ... und dass die Übertragungswege rein physikalisch länger werden was für länger Übertragungszeiten sorgt (weiß auch hier jemand wie stark sich das bemerkbar machen würde?).

    Lichtgeschwindigkeit = 299.792.458 m/s
    Bei 4 GHz (299792458 / 4000000000 = 0.074) schafft das Licht nur noch 7 cm pro Takt.
    Ein Stromimplus* bewegt sich langsamer als Licht durch die Leiter und viel größer können Chips nicht mehr werden, ohne dass man an diese Grenze kommt. (Ein Prof hat es uns mal so erklärt und nach seiner Erklärung kam raus, dass man ziemlich an der Grenze ist, die genauen Zahlen weiß ich nicht mehr).

    *Ich weiß nicht ob Stromimplus der korrekte physikalische Begriff ist, ich meine nicht die Geschwindigkeit mit der Elektronen wandern, sondern wie schnell sich die "Information im Leiter" bewegt, das der Strom eingeschalten wurde.



  • Japp verstanden, du meinst die Ausbreitungsgeschwindigkeit des elektromagnetischen Feldes (also Licht) im Leiter.



  • ben Sie einen Benutzernam schrieb:

    Ein Stromimplus* bewegt sich langsamer als Licht durch die Leiter und viel größer können Chips nicht mehr werden, ohne dass man an diese Grenze kommt.

    Das Argument sehe ich nicht ganz ein. Wer sagt, daß alle Kerne des Chips sich gegenseitig impulieren können müssen?
    Und wenn man vom zentralen Takt abkommt (nur sehr teuer, oder?), wo ist dann noch die Grenze?



  • Da stelle ich die Frage in den Raum wie werden dual CPU Mainboards verwaltet. Die haben doch bestimmt auch nur einen Takt?



  • Es gibt noch weitere Gruende und ich weiss nicht, welcher der wirklich limitierende ist. Zum Beispiel die Frage wie hoch die CPU-Ausbaeute ist. Das kann man sich ganz einfach ueberlegen. Angenommen, auf einem Wafer sind 500 CPUs und 100 davon sind fehlerhaft, weil im Herstellungsprozess bei einer Belichtung oder aehnlichem irgendwo ein Staubkorn im Weg war. Wenn die CPUs jetzt als Beispiel 4 mal so gross waeren, dann waeren nur noch um die 125 CPUs auf dem Wafer. Die Anzahl der Fehler auf dem Wafer bliebe aber konstant und wuerde sich eben auf diese 125 CPUs verteilen. Man waere von einer Situation der Art "Die meisten CPUs sind funktionstuechtig" zu einer Situation der Art "die CPU-Ausbaeute ist sehr gering" gekommen. Wenn man der Einfachheit halber annimmt, dass man nur noch eine Ausbaeute von 25 CPUs hat, vorher aber eine Ausbaeute von 400 CPUs hatte, dann hat sich dadurch der CPU-Preis auf das 16-fache erhoeht.

    ichhoffedasistrichtig schrieb:

    Da stelle ich die Frage in den Raum wie werden dual CPU Mainboards verwaltet. Die haben doch bestimmt auch nur einen Takt?

    Auf dem Mainboard nutzt man einen niedrigeren Takt.



  • ichhoffedasistrichtig schrieb:

    Da stelle ich die Frage in den Raum wie werden dual CPU Mainboards verwaltet. Die haben doch bestimmt auch nur einen Takt?

    Die CPUs arbeiten ja nicht wirklich zusammen. Das Betriebssystem teilt Aufgaben zu und diese werden größtenteils unabhängig voneinander abgearbeitet.
    Deswegen finde ich auch das "Geschwindigkeit durch geringen Abstand"-argument unnötig. Wenn man mehr Kerne hat, die größtenteils unabhängig voneinander arbeiten, kann man innerhalb der Kerne alles lokal halten, aber trotzdem auf größerer Fläche arbeiten.



  • Wenn ich euch richtig verstehen spielt also nur das finanzielle und die Lichtgeschwindigkeit eine Rolle?



  • 1qayWIN schrieb:

    Wenn ich euch richtig verstehen spielt also nur das finanzielle und die Lichtgeschwindigkeit eine Rolle?

    "Die Ausbaeute" ist kein rein finanzielles Argument, sondern durchaus auch ein technisches. Jenseits davon wird es noch diverse weitere Argumente geben. Zum Beispiel die Waermemenge, die abgefuehrt werden muss.

    Allerdings wachsen CPU und GPU in letzter Zeit durchaus immer weiter zusammen. Was Parallelitaet betrifft, haben wir in den letzten Jahren ja schon gesehen, dass immer mehr Rechenkerne auf den CPUs zu finden sind. Und auch davor wurde in CPUs bereits Parallelverarbeitung genutzt. ...in Form von Pipelining. Neuere Entwicklungen integrieren voll funktionsfaehige Grafikeinheiten auf den CPUs. Diese sind zwar noch nicht so leistungsstark wie separate Grafikchips, aber ich denke, auf Dauer wird man da nur noch einen Chip haben, auf dem beides integriert ist.



  • Gast123 schrieb:

    Hallo Leute,

    bei dem Unterschied zwischen CPU und GPU liest man in der Regel so etwas wie

    "bei CPUs wird die vorhandene Chipfläche fokussiert für Caches, Speicherverwaltung etc genutzt"

    genau wie

    "bei GPUs wird die vorhanden Fläche fokussiert für viele parallele Ausführungseinheiten benutzt".

    Was ich mich jetzt frage ist, warum man die Chipfläche nicht einfach vergrößert und von den Vorteilen beider Architekturen profitiert.

    Bei GPUs ist es einfach, die Leistung zu erhöhen, in dem man einfach immer weitere Recheneinheiten anfügt, dadurch wächst dann die Fläche. Der Limitierende Faktor ist hier dann die Ausbeute im Zusammenhang mit den Kosten pro Chip pro Wafer sowie der Stromverbrauch und die Abführung der Wärmenenergie.

    Bei CPUs funktioniert das so aber nicht mehr, da diese als Allzweck CPUs nicht parallel arbeitenund man nicht einfach immer mehr Recheneinheiten dranhängen kann. Piplining und MultiCores haben hier bestenfalls Alibifunktion, deren Anzahl ist bestenfalls im unteren zweistelligen Bereich, vergleichen mit den vielen > 1000 Recheneinheiten einer GPU.
    Dazu kommt, dass man das möglichst Kompakt halten muss, wegen der Ausbreitung elektromagnetischer Signale in der CPU und zentral gehalten werden die Daten im Cache und den Registern. Da kann man einfach nicht die Recheneinheit x mm vom Cache oder noch schlimmer Register entfernt hinbauen, das schadet der Performance.
    Die Recheneinheiten müssen also auch möglichst dicht und kompakt zusammenliegen.



  • Gregor schrieb:

    Neuere Entwicklungen integrieren voll funktionsfaehige Grafikeinheiten auf den CPUs. Diese sind zwar noch nicht so leistungsstark wie separate Grafikchips, aber ich denke, auf Dauer wird man da nur noch einen Chip haben, auf dem beides integriert ist.

    Das Hauptproblem bei integrierten GPU-Kernen ist die Anbindung an den Video-Speicher, der typischerweise nur normaler Hauptspeicher ist. Da nutzt es dann auch nichts den GPU-Kern leistungsfähiger zu machen weil hier die Bandbreite der limitierende Faktor wird. Erschwerend kommt hinzu das sich hier dann CPU und GPU die Bandbreite teilen müssen.

    Zum Vergleich: der Sandybridge CPU BUS schafft 96GB/s Durchsatz. Das müssen sich aber alle angeschlossenen Kerne teilen. Die GTX Titan hat dagegen 288.4 GB/s Bandbreite allein fürs V-Mem. Selbst wenn man die GPU der Titan also in eine CPU einbauen könnte, würde die Grafik immer noch um mindestens 66% langsamer sein als auf der Grafikkarte, vorausgesetzt das die übrigen Kerne den BUs nicht benutzen... Dabei ignoriere ich gerade obendrein das die Bandbreite zum Hauptspeicher meistens noch geringer ist. Mein "Gaming-RIG" schafft da gerade mal 54 GB/s.



  • volkard schrieb:

    ben Sie einen Benutzernam schrieb:

    Ein Stromimplus* bewegt sich langsamer als Licht durch die Leiter und viel größer können Chips nicht mehr werden, ohne dass man an diese Grenze kommt.

    Das Argument sehe ich nicht ganz ein. Wer sagt, daß alle Kerne des Chips sich gegenseitig impulieren können müssen?

    Das Argument ist auch nicht von mir, sondern von einem Prof aus dem E-Technik Fachbereich. Der hat/hatte auch Kontakt zu Chipentwicklern und kennt sich mit dem Entwurf solcher relativ gut aus, er machte einem ziemlich kompetenten Eindruck. Ich kenne mich mit Chipentwurf garnicht aus und weiß nicht wie einzele Kerne miteinander verbunden sein müssen, damit sie noch Effizent arbeiten können. Aber da auch 3D Chips entwickelt werden, wird schon was dran sein. http://en.wikipedia.org/wiki/Three-dimensional_integrated_circuit



  • loks schrieb:

    Das Hauptproblem bei integrierten GPU-Kernen ist die Anbindung an den Video-Speicher, der typischerweise nur normaler Hauptspeicher ist. Da nutzt es dann auch nichts den GPU-Kern leistungsfähiger zu machen weil hier die Bandbreite der limitierende Faktor wird. Erschwerend kommt hinzu das sich hier dann CPU und GPU die Bandbreite teilen müssen.

    Zum Vergleich: der Sandybridge CPU BUS schafft 96GB/s Durchsatz. Das müssen sich aber alle angeschlossenen Kerne teilen. Die GTX Titan hat dagegen 288.4 GB/s Bandbreite allein fürs V-Mem. Selbst wenn man die GPU der Titan also in eine CPU einbauen könnte, würde die Grafik immer noch um mindestens 66% langsamer sein als auf der Grafikkarte, vorausgesetzt das die übrigen Kerne den BUs nicht benutzen... Dabei ignoriere ich gerade obendrein das die Bandbreite zum Hauptspeicher meistens noch geringer ist. Mein "Gaming-RIG" schafft da gerade mal 54 GB/s.

    Klar, separate, spezialisierte Chips werden immer einen derartigen Vorteil haben. Die Frage ist allerdings, wie groß dieser Vorteil ist bzw. in Zukunft sein wird.

    Jenseits davon ist Bandbreite nicht alles. In CPUs wird wesentlich stärker auf Speicherhierarchien gesetzt. Du hast da große Caches. Und wenn ich an Intel's Crystalwell denke, dann sind inzwischen Cache-Größen von 128MB für integrierte Grafikeinheiten real. Wenn man in der Datenverarbeitung dann irgendeine Art von Speicherlokalität ausnutzen kann, wird man enorm von Caches profitieren. Die Speicherbandbreite lässt sich eigentlich nur dann direkt mit der Problemstellung in Bezug setzen, wenn es sich bei der Problemstellung um die Verarbeitung von Streaming-Daten handelt: Man muss einen großen Speicherbereich in Speicherreihenfolge durchwandern. Wenn man hingegen lauter zufällige Zugriffe auf den Speicherbereich hat, dann hat man bei jedem einzelnen Zugriff erstmal die Latenzzeit des Speichers als Limit gegeben. Hinzu kommt, dass gleich eine ganze Speicherzeile übertragen wird, obwohl man vielleicht nur einen kleinen Teil davon braucht. Eine hohe Bandbreite bringt in so einem Fall nicht so viel.

    Bei der Verarbeitung von Grafikdaten für 3D-Spiele kann man natürlich jede Menge Parallelität ausnutzen. Was mir nicht klar ist, ist, ob man hierbei auch problemlos den Speicher in Speicherreihenfolge durchlaufen kann. Das ist etwas, was ich erstmal anzweifle. Wenn man das aber nicht kann, dann schmeißt man einen Großteil der Speicherbandbreite weg. Die verfügbare Bandbreite ist dann alleine kein gutes Vergleichskriterium, wenn man auf der anderen Seite eine Architektur hat, die jenseits der Speicherbandbreite zum Hauptspeicher auch noch große Caches vorzuweisen hat.



  • Gregor schrieb:

    1qayWIN schrieb:

    Wenn ich euch richtig verstehen spielt also nur das finanzielle und die Lichtgeschwindigkeit eine Rolle?

    "Die Ausbaeute" ist kein rein finanzielles Argument, sondern durchaus auch ein technisches. Jenseits davon wird es noch diverse weitere Argumente geben. Zum Beispiel die Waermemenge, die abgefuehrt werden muss.

    Allerdings wachsen CPU und GPU in letzter Zeit durchaus immer weiter zusammen. Was Parallelitaet betrifft, haben wir in den letzten Jahren ja schon gesehen, dass immer mehr Rechenkerne auf den CPUs zu finden sind. Und auch davor wurde in CPUs bereits Parallelverarbeitung genutzt. ...in Form von Pipelining. Neuere Entwicklungen integrieren voll funktionsfaehige Grafikeinheiten auf den CPUs. Diese sind zwar noch nicht so leistungsstark wie separate Grafikchips, aber ich denke, auf Dauer wird man da nur noch einen Chip haben, auf dem beides integriert ist.

    Zur Ergänzung: Man hat durchaus versucht, viel größere Flächen zu produzieren, das nennt man Wafer-scale integration: https://en.wikipedia.org/wiki/Wafer-scale_integration

    Eine weitere Limitierung der Chipgröße stammt von der Größe der Fotomaske, die i.d.R kleiner als der gesamte Wafer ist. D.h, der Wafer ist zwar physisch zusammenhängend, aber es existieren keine Verbindungen an den Grenzen der Fotomaske. Es gibt zwar Methoden, einen produzierten Wafer zu prozessieren und z.B. benachbarte, unabhängig belichtete Bereiche zu verbinden, das ist aber nicht üblich und bedeutet zusätzlichen Aufwand.



  • vielleicht hilft es andersrum zu denken:
    wozu sollten die chips groesser werden?
    normalerweise doch nur um synergieen zu nutzen (z.b. shared caches, busses, logik etc).

    aber wenn man sich groessere chips anschaut, dann ist das weniger und weniger der fall. moderne multi core chips (sowohl cpu als auch gpu) haben bis zum memory controller alles separiert (und diese sind bei groesseren chip ueberproportional aufwendiger). manchmal sind grosse chips auch nur noch ueber die normalen externen interfaces verbunden (QPI/HT) und dann ist das einzige was sie teilen nur von nachteil: stromversorgung und abwaerme (wobei es heute sogar fuer einen einzigen chip schon unmengen spannungsquellen gibt damit sie nicht durch ihr eigenes arbeiten schwankungen widerfahren).

    bei grossen chips geht man dann dazu ueber eher ineffiziente architekturen einzusetzen (z.b. ringbus statt cross bars) um die sache noch im vernuenftigen rahmen zu halten (ringbus hat unabhaengig von der einheiten zahl eine konstante anzahl verbindungen, crossbars haben eher quadratische steigerungen).
    offensichtlich teilen sich beim ringbus die einheiten die bandbreite und die latenz wird mit der anzahl der hops ueberproportional steigen (mehr hops * mehr requests).
    deswegen macht es sinn mehr chips auf ein board zu pappen statt sie zusammen auszuliefen. selbes prinzip gilt dann natuerlich auch fuer boards. irgendwann ist es zu aufwendig so ein board zu basteln und dann verbindet man die eher als ein grosses zu bauen.



  • Auskenner schrieb:

    Bei CPUs funktioniert das so aber nicht mehr, da diese als Allzweck CPUs nicht parallel arbeitenund man nicht einfach immer mehr Recheneinheiten dranhängen kann. Piplining und MultiCores haben hier bestenfalls Alibifunktion,...

    Sie mögen von der Architektur Nachteile haben, das mehr Kerne aber nichts bringen stimmt genauso wenig. Wir nutzen z.B. alle Kerne für das Kompilieren aus, und auch wenn nicht jeder Kern +100% des ersten bedeutet ist der Leistungsgewinn von jedem weiteren Kern spürbar gewesen (nimmt aber im Verhältnis immer etwas mehr ab - dennoch ist noch Platz nach oben).



  • Vielleicht sollte man die Frage anders formulieren:

    State of the Art:

    CPU: weniger Funktionseinheiten, die dafür eine sequentielle Abfolge von Befehlen sehr schnell bearbeiten können (durch Pipelining, Caches, etc.)

    GPU: sehr viele Funktionseinheiten, die dafür eine sequentielle Abfolge von Befehlen i.d.R. wesentlich langsamer bearbeiten können als die Funktionseinheiten der CPUs (die Kraft kommt aus der Parallelität)

    Frage:
    Warum kann man die Vorteile beider Architekturen (CPU & GPU) nicht vereinen, also eine Art Multi-Core Prozessor entwickeln mit zig 100 Kernen?
    Dann hätte man wie bei der GPU sehr viele Funktionseinheiten und könnte stark parallel arbeiten und zudem den Vorteil, dass jeder Kern alls Vorteile von CPU Kernen besitzt, d.h. Pipelining, Caches etc.

    Grüße



  • Vielleicht sollte man die Frage anders formulieren:

    State of the Art:

    CPU: weniger Funktionseinheiten, die dafür eine sequentielle Abfolge von Befehlen sehr schnell bearbeiten können (durch Pipelining, Caches, etc.)

    GPU: sehr viele Funktionseinheiten, die dafür eine sequentielle Abfolge von Befehlen i.d.R. wesentlich langsamer bearbeiten können als die Funktionseinheiten der CPUs (die Kraft kommt aus der Parallelität)

    Frage:
    Warum kann man die Vorteile beider Architekturen (CPU & GPU) nicht vereinen, also eine Art Multi-Core Prozessor entwickeln mit zig 100 Kernen?
    Dann hätte man wie bei der GPU sehr viele Funktionseinheiten und könnte stark parallel arbeiten und zudem den Vorteil, dass jeder Kern alls Vorteile von CPU Kernen besitzt, d.h. Pipelining, Caches etc.

    Grüße


  • Mod

    armarani schrieb:

    Frage:
    Warum kann man die Vorteile beider Architekturen (CPU & GPU) nicht vereinen, also eine Art Multi-Core Prozessor entwickeln mit zig 100 Kernen?
    Dann hätte man wie bei der GPU sehr viele Funktionseinheiten und könnte stark parallel arbeiten und zudem den Vorteil, dass jeder Kern alls Vorteile von CPU Kernen besitzt, d.h. Pipelining, Caches etc.

    Gibt es doch. Nennt sich Supercomputer*. Brauchen nur wenige Leute. Kostet sehr viel Geld.

    *: Gleich kommt irgendein Klugscheißer, dass das nicht die Definition von "Supercomputer" ist, obwohl praktisch jeder Supercomputer (außer die neuen Super-GPU-Cluster) heutzutage so gebaut ist.



  • armarani schrieb:

    Vielleicht sollte man die Frage anders formulieren:

    State of the Art:

    CPU: weniger Funktionseinheiten, die dafür eine sequentielle Abfolge von Befehlen sehr schnell bearbeiten können (durch Pipelining, Caches, etc.)

    GPU: sehr viele Funktionseinheiten, die dafür eine sequentielle Abfolge von Befehlen i.d.R. wesentlich langsamer bearbeiten können als die Funktionseinheiten der CPUs (die Kraft kommt aus der Parallelität)

    Frage:
    Warum kann man die Vorteile beider Architekturen (CPU & GPU) nicht vereinen, also eine Art Multi-Core Prozessor entwickeln mit zig 100 Kernen?
    Dann hätte man wie bei der GPU sehr viele Funktionseinheiten und könnte stark parallel arbeiten und zudem den Vorteil, dass jeder Kern alls Vorteile von CPU Kernen besitzt, d.h. Pipelining, Caches etc.

    Um pro Core schnell zu sein brauchst du Branch-Prediction, Out-of-Order-Execution, Register-Renaming, µOP-Caches, möglichst grosse per-Core Caches usw.
    Alle diese Dinge brauchen einiges an Power und einiges an Die-Fläche.

    Weiters möchte man in der CPU eine möglichst starke Cache-Coherency haben und/oder möglichst schnelle Synchronization-Primitives (CAS) haben. Weil das nötig ist damit SMP multithreading angenehm schnell läuft. Was die Pipelines und die ganze Speicheranbindung mächtig verkompliziert => noch mehr Core-Fläche und Power.

    In der CPU macht man den Tradeoff: viel Power/Fläche für diese Optimierungen verbraten, dafür nicht so viele Cores. Weil ja die meisten Programme eh nicht so viele Cores auslasten können, es dafür aber wirklich viele Programme gibt die von einem oder zwei superschnellen Cores mächtig profitieren.

    In der GPU macht man den Tradeoff: viele dieser Optimierungen weglassen bzw. kleiner dimensionieren, dafür viele viele Cores im selben Power/Die-Fläche Footprint unterbringen. Weil sich das mit den meisten Shader-Programmen gut verträgt (kurze Shader-Programme die aber prozentuell sehr viele aufwendige Instruktionen ala Multiplikation/Division/transzendente Funktionen verwenden, vergleichsweise wenige und gut vorhersehbare Speicherzugriffe).

    => Wie soll man das bitte kombinieren können?
    Man macht diese Tradeoffs ja nur, weil man eben nicht unendlich Power und/oder Die-Fläche zur Verfügung hat.
    😕

    Das beste was man machen kann ist also vermutlich Hybride zu bauen, die ein paar wenige "full featured" CPU Cores haben und dazu einen Haufen abgespeckter GPU Cores. Was natürlich schon lange passiert ist - z.B. Intels Core i mit integrierter "HD" Grafik.

    Angenehmer wären natürlich Chips wo die "abgespeckten" Cores das selbe Instruction-Set verarbeiten könnten wie die "dicken" Cores auch die selbe Cache-Coherency haben. Dann könnte man nämlich lässig den Scheduler des OS so anpassen dass er die Threads mit hoher Priorität auf den dicken Cores scheduled, und die mit niedrigerer Priorität auf den abgespeckten. Und könnte ganz normalen OS Threads verwenden um massiv parallele Berechnungen zu machen. Ganz ohne spezielle Frameworks oder Compiler die speziellen GPU-Code erzeugen und Daten rumschaufeln damit sie irgendwelche Berechnungen auf der GPU ausführen können.

    Beides ist aber ein Problem. Wenn man die "dicken" Cores dabei nicht kastrieren will, muss man die "abgespeckten" Cores alleine für das volle Instruction-Set und die Cache-Coherency so aufblasen, dass sie schon wieder viel zu dick sind als dass man sehr viele davon auf einen Chip bringen würde.
    Und wenn man die "dicken" Cores kastriert, dann kann man kein normales Windows/Linux/... mehr drauf laufen lassen. Womit sich der einzige echte Vorteil den diese Chips hätten in Luft auflöst.


Log in to reply