GPU und CPUs

[Kaiser Ming]

sollten zusammenwachsen
wäre im Endeffekt effektiver
und man könnte auch über die CPU auf schnelle Einheiten zugreifen
statt über umständliche GPU Programmierung
man bräuchte dafür allerdings eine neue Architektur

[xPandamon]

Gibt es doch, nennt sich APU. Nur kann sowas nicht die erforderliche Performance bieten, es wäre zu teuer und gäbe gegebenenfalls Kompatibilitätsprobleme. Eine Konsole kommt wohl noch am ehesten an deine Idee dran von der Umsetzung, da ist eben alles auf diese eine Konfigurationen optimiert.

[nate]

> Gibt es doch, nennt sich APU.

APUs, so wie sie derzeit angeboten werden, sind nur CPUs und GPUs auf dem selben Die oder Package. Das einzige, was da irgendwie zwischen den beiden Welten konvergiert, ist die Tatsache, dass beide den gleichen Speicher verwenden. Die Kerne sind aber nach wie vor physikalisch und vom Programmiermodell völlig verschieden.

[yinyangkoi]

Physikalisch sind sie identisch

[Kaiser Ming]

xPandamon schrieb:
--------------------------------------------------------------------------------
> Gibt es doch, nennt sich APU. Nur kann sowas nicht die erforderliche

das meine ich aber nicht
die sind da einfach nur zusammengeklebt



2 mal bearbeitet, zuletzt am 05.01.21 18:59 durch Kaiser Ming.

[ms (Golem.de)]

Nein, das sind monolithische Dies.

Marc Sauter, Sr Editor
Golem.de

[Cerdo]

Kaiser Ming schrieb:
--------------------------------------------------------------------------------
> sollten zusammenwachsen
> wäre im Endeffekt effektiver
> und man könnte auch über die CPU auf schnelle Einheiten zugreifen
> statt über umständliche GPU Programmierung
> man bräuchte dafür allerdings eine neue Architektur

Warum will ich im Betriebssystem tausende identische Berechnungen auf unterschiedlichen Daten machen (SIMD)? Andersrum ist eine GPU für die üblichen Operationen der CPU völlig ungeeignet. Die ist auch überhaupt nicht "schneller" als die CPU, wenn man die blanken Rechenoperationen betrachtet.

Es hat schon einen Grund, warum man die beiden trennt und sie zu kombinieren ist für die meisten Anwendungsfälle überhaupt nicht sinnvoll.

[Renegade3349]

Gab es da nicht vor ein paar Jahren eine Lösung mit Intel CPU und AMD GPU wo die CPU zumindest direkt an den HBM2 Speicher angebunden war? Ist zwar dann nur so etwas wie L3 oder 4 Cache, aber immerhin.
Interessant wäre es schon zu sehen ob man manche der beidseits vorhandenen Funktionen auf einer Seite zusammenlegen könnte um dafür häufiger genutzte Funktionen zu erweitern, aber das wäre halt in vielen Fällen ein Rückschritt in der Leistung...

[nate]

> Physikalisch sind sie identisch

Überhaupt nicht. Außer dass da im Inneren irgendwo ALUs für Integer und Floating Point im Kern werkeln, unterscheiden sich CPU- und GPU-Cores fundamental.

CPUs sind auf Latenz optimiert, Durchsatz ist zweitrangig.
GPUs sind rücksichtslos auf Durchsatz optimiert, Latenz spielt gar keine Rolle.

Schon deshalb handelt es sich dabei um völlig verschiedene Architekturen. Ich finde den Gedanken auch spannend, diese beiden Welten irgendwann in einem gemeinsamen Design unter einen Hut zu bringen, aber bisher habe ich noch nicht einmal Ansätze für so etwas gesehen. (Mit Ausnahme von Intel MIC, alias LRB/KNF/KNC/KNL, aber da ging es auch nicht um ein "konvergentes" Design, sondern eher um "lasst uns mal schauen, ob wir GPUs Konkurrenz machen können, wenn wir einfach ganz viele CPUs mit super-breiten Vektoreinheiten auf ein Die packen".)

[xPandamon]

Wenn nicht APUs, dann sowas wie Apples M1. Wo man wieder beim Performanceproblem ist :)

[nate]

> Wenn nicht APUs, dann sowas wie Apples M1.

Du meinst, SoCs mit Arm- anstatt x86-ISA für die CPUs? So wie bei Qualcomm, MediaTek, Samsung, HiSilicon, RockChip, Allwinner, Amlogic, NXP, nVidia, Marvell, Broadcom und bestimmt zwei Dutzend weiteren?

[Kaiser Ming]

ms (Golem.de) schrieb:
--------------------------------------------------------------------------------
> Nein, das sind monolithische Dies.

falsch kommentiert?
oder nicht verstanden?

[Kaiser Ming]

Cerdo schrieb:
--------------------------------------------------------------------------------
> Kaiser Ming schrieb:
> ---------------------------------------------------------------------------
> -----
> > sollten zusammenwachsen
> > wäre im Endeffekt effektiver
> > und man könnte auch über die CPU auf schnelle Einheiten zugreifen
> > statt über umständliche GPU Programmierung
> > man bräuchte dafür allerdings eine neue Architektur
>
> Warum will ich im Betriebssystem tausende identische Berechnungen auf
> unterschiedlichen Daten machen (SIMD)? Andersrum ist eine GPU für die
> üblichen Operationen der CPU völlig ungeeignet. Die ist auch überhaupt
> nicht "schneller" als die CPU, wenn man die blanken Rechenoperationen
> betrachtet.
>
> Es hat schon einen Grund, warum man die beiden trennt und sie zu
> kombinieren ist für die meisten Anwendungsfälle überhaupt nicht sinnvoll.

Wenn du recht hättest würde es CUDA nicht geben.
Im Zweifel einfach mal googeln.

[Cerdo]

Kaiser Ming schrieb:
--------------------------------------------------------------------------------
> Wenn du recht hättest würde es CUDA nicht geben.
Danke, ich kenne und nutze CUDA und OpenCL seit Jahren professionell. Du weißt auch, wofür man das verwendet?
> Im Zweifel einfach mal googeln.

[gorsch]

Ja, wäre im Prinzip nett, aber wenn das wirklich so vorteilhaft wäre, würdest du das in den ARM CPUs sehen. Die sind ja schon hochintegriert aber selbst da sind GPU-Kerne und CPU-Kerne getrennt. Tatsächlich kommen eher sogar noch mehr CPU-Kern-Typen hinzu (big.LITTLE).

Du kannst einen Kern entweder in die Breite (SIMD) oder Tiefe (Pipelines) optimieren, je nach Anwendungsfall. Ein Kern, der in der Mitte läge, würde in keinem Anwendungsfall optimal rechnen.

[yumiko]

Softwareseitig nennt sich das OpenCL, da ist es aber egal wo und welche Hardware genutzt wird.

[Kaiser Ming]

Cerdo schrieb:
--------------------------------------------------------------------------------
> Kaiser Ming schrieb:
> ---------------------------------------------------------------------------
> -----
> > Wenn du recht hättest würde es CUDA nicht geben.
> Danke, ich kenne und nutze CUDA und OpenCL seit Jahren professionell. Du
> weißt auch, wofür man das verwendet?


CUDA nutzen heisst nicht verstehen, da reichts schon einen Browser benutzen.

Reden wir aneinander vorbei?

[Kaiser Ming]

gorsch schrieb:
--------------------------------------------------------------------------------
> Ja, wäre im Prinzip nett, aber wenn das wirklich so vorteilhaft wäre,
> würdest du das in den ARM CPUs sehen. Die sind ja schon hochintegriert aber
> selbst da sind GPU-Kerne und CPU-Kerne getrennt. Tatsächlich kommen eher
> sogar noch mehr CPU-Kern-Typen hinzu (big.LITTLE).

Wie ich schon sagte bräuchte es dafür eine neue Architektur sowas macht man nicht mal ebend.
ARM macht perse die klassische Architektur nur als RISC.



>
> Du kannst einen Kern entweder in die Breite (SIMD) oder Tiefe (Pipelines)
> optimieren, je nach Anwendungsfall. Ein Kern, der in der Mitte läge, würde
> in keinem Anwendungsfall optimal rechnen.

Glaub du hast das Thema nicht verstanden.
Mir gings um die Recheneinheiten der Grafikchips nicht um SIMD.
Einfach gesagt warum ist ein Grafikchip bei Videokomprimierung 10x schneller als ne CPU.