Gewagte Frage: Warum gibt es noch CPUs?

Los

Los

Enthusiast
Thread Starter
Mitglied seit
13.09.2009
Beiträge
784
Ort
Rheinland-Pfalz!
Hi miteinander,

vielleicht mag diese Frage für die Cracks unter euch naiv klingen, aber nachdem ich mir gestern die Rechenpower aktueller CPUs und GPUs angeschaut habe (Knappe Erklärung: Das RC5-72-Projekt versucht den Key einer verschlüsselten Nachricht per Brute Force zu knacken ->www.distributed.net), stellt sich mir einfach die Frage: Warum werden nicht längst schon alle Rechenarbeiten komplett über die GPU abgewickelt? Diese ist ja augenscheinlich um ein vielfaches potenter als die CPU und damit dürfte bei weniger Stromverbrauch mehr Leistung möglich sein, was in jeder Hinsicht ein voller Gewinn währe.
Wenn jemand mich hierüber aufklären könnte, wäre ich sehr dankbar, scheinbar fehlen mir dazu die nötigen Infos ;)

Gruß,
Los

edit: Ich möchte hier eine freie Diskussion anregen und eigentlich keine Antworten á là "das ist so, find dich damit ab" erhalten - abfinden muss ich mich ohnehin damit ;) Mich interessiert einfach WARUM das so ist!
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
1. Nicht jeder Code ist schön parallelisierbar
2. Kompatibilität zu x86. Erklär mal deinem Chef, dass ihr jetzt alle Software neu kaufen müsst

Für wirklich rechenintensive Sachen geht der Trend zu GPU-Computing, aber eine CPU wird halt für das meiste immer noch gebraucht.
 
ich weiß darauf zwar keine antwort.
aber is eine sehr intersannte Frage :confused:

ich werds verfolgen =)
:banana:
 
zu 1.: Wenn GPU-Computing aber günstiger arbeiten würde, muss der Code nicht parallelsierbar sein um einen Vorteil davon zu haben.
zu 2.: Klar müsste man alles neu schreiben. Aber diese Umstellung ist nunmal ein Meilenstein und der Prozess hätte schon vor langer Zeit begonnen werden können und wäre dann jetzt abgeschlossen. Außerdem könnte man notfalls soft- oder hardwaretechnisch doch etwas zwischen OS und System schalten, das dem OS und damit der Software eine/mehrere CPU(s) vorgaukelt.

Mich wundert eben, dass mittlerweile zwar die GPUs mit den CPUs zusammengelegt werden, dass man aber immer noch an dem Konzept einer CPU festhält und die beiden Einheiten getrennt hält.
 
Zuletzt bearbeitet:
boxleitnerb hat es eigentlich schon geschrieben. VPUs wollen parallelisierten Code bzw. parallele Befehlsabarbeitung. Also ist einfach nicht alles möglich. Dazu kommt die niedrigere Genauigkeit bei Fließkommaberechnungen. CPU & VPU werden nach & nach ineinander verschmelzen. (AMD) Aber ohne CPU geht gar nichts. Dazu geben Intel & AMD in etwa die Marschrichtung für uns Nutzer vor. Da nützt es auch nichts, wenn ein kleines Unternehmen einen tollen Prozessor mit fremden Befehlssatz zur Verfügung stellt.
 
Zuletzt bearbeitet:
Los schrieb:
zu 1.: Wenn GPU-Computing aber günstiger arbeiten würde, muss der Code nicht parallelsierbar sein um einen Vorteil davon zu haben.
zu 2.: Klar müsste man alles neu schreiben. Aber dieser Prozess hätte schon vor langer Zeit in die Tat umgesetzt werden können und wäre dann jetzt abgeschlossen. Außerdem könnte notfalls man soft- oder hardwaretechnisch doch etwas zwischen OS und System schalten, dass dem OS und damit der Software eine/mehrere CPU(s) vorgaukelt.

Mich wundert eben, dass mittlerweile zwar die GPUs mit den CPUs zusammengelegt werden, dass man aber immer noch an dem Konzept einer CPU festhält und die beiden Einheiten getrennt hält.
Zum Vergrößern anklicken....

Wie "günstiger"? Ist Code nicht parallelisierbar oder nicht angepasst, ist da nix mit günstiger auf der GPU. Dann ist es einfach nur langsam bzw. Perf/W ist schlecht.

Und jede Firma hat die Ressourcen dafür? Es gibt ja nichtmal einen H264 Codec, der keine Artefakte beim Encodieren auf GPUs verursacht. Es ist schon so schwer genug, für Multicore zu optimieren...für Hunderte Cores erst recht.
 
Los schrieb:
zu 1.: Wenn GPU-Computing aber günstiger arbeiten würde, muss der Code nicht parallelsierbar sein um einen Vorteil davon zu haben.
Zum Vergrößern anklicken....

Eben doch. Eine GPU besteht aus vielen, vergleichsweise einfachen Kernen, die nur dann viel leistet, wenn eine Aufgabe auf diese vielen Kerne aufteilbar ist. Daher geht der Trend im HPC-Bereich auch auf GPUs. Ein CPU-Kern ist sehr komplex und kann komplexe Aufgaben bewältigen, leistet dann natürlich nicht so viel und braucht mehr Strom.
 
Rohe Leistung ist das eine. Universelle Einsetzbarkeit das andere.

Ein Formel-1 Bolide steckt einen VW Kombi locker in die Tasche. Jedoch ist der F1-Flitzer völlig ungeeignet um die Kids in die Schule zu Karren, Einkäufe/Getränkekisten zu transportieren, in den Urlaub zu fahren, ...

[edit] oops, als ich angefangen hab' warn's noch 4 oder 5 Posts weniger. :d
 
Zuletzt bearbeitet:
Warum ist GPU-Computing soviel schneller als CPU-Computing? Wenn ich das richtig verstanden habe, dann doch wegen der vielen parallel arbeitenden Kerne, oder? Wenn hier entsprechende Stromsparmechanismen implementiert würden, wäre es also auch möglich, günstig (=Leistung/Watt) zu arbeiten, oder ist das zu naiv gedacht?
 
GPU-Computing ist nur deswegen soviel schneller, weil eine GPU mehr Kerne hat und die Aufgaben, die eine GPU berechnet, massiv parallelisierbar sind. Und aufgrund der GPU-Eigenarten kann diese längst nicht alles, was eine CPU kann und wird es auch nie können. Oder anders: CPU/GPU-Systeme gleichen die Schwächen beider Teile aus.
 
Ja, ein bisschen schon. GPUs sind nur so schnell/effizient, weil sie spezialisiert sind auf parallele Probleme. Sind wenige Kerne ausgelastet, weil das Problem sich nicht in Häppchen unterteilen lässt, ist mit den Vorteilen vorbei.

Ob du jetzt 4 oder 8 CPU-Kerne/Threads auslastet ist ne andere Größenordnung als der Unterschied zwischen z.B. 512 Cuda Cores und 20 Cuda Cores. Faktor 2 gegen Faktor 25 salopp gesagt. Die restlichen 492 Cuda Cores drehen Däumchen. Und ein solcher Core ist alleine halt recht langsam, da ist eine CPU deutlich flotter.
 
du kannst deine wäsche von nem roboter waschen lassen oder von ner waschmaschine
die waschmaschine wird schneller sein

soll die waschmaschine aber was anderes machen als wäsche waschen wirds kompliziert
 
Wie schon mehrfach erwähnt, liegt das ganz einfach an der Art der Rechenwerke.

Stell dir eine Quadcore-CPU als kleines Team aus hochdotierten Wissenschaftlern vor.
Stell dir eine GPU als eine ganze Fabrikhalle voller untrainierter Arbeiter vor.

Aufgabe: Entwickeln sie einen militärischen Spionagesatelliten. Wer ist schneller?
Aufgabe: Etikettieren sie 50,000 Milchflaschen. Wer ist schneller?


Eine GPU hat deswegen so viel theoretische Rohleistung, weil sie soviele Kerne hat. Die einzelnen Kerne sind aber, gelinde gesagt, strunzdumm - nur als Gruppe taugen sie was, denn so bilden sie ein sehr breites paralleles Rechenwerk. Eine CPU ist deswegen langsamer, weil sie nur wenige Kerne hat. Aber jeder Kern ist ein extrem vielseitiges, hochkomplexes serielles Rechenwerk.

Um die tatsächliche Rohleistung zu vergleichen, musst du gleiche Kernzahlen vergleichen - also zum Beispiel eine einzelne Grafikkarte mit 400 Kernen gegen 100 Sandy Bridge Quadcores stellen. Da sieht dann die Rohleistung der CPU(s) im Vergleich plötzlich wieder ganz anders aus. Und Rohleistung alleine sagt noch nichts darüber aus, wieviel man davon tatsächlich umsetzen kann. So muss zum Beispiel bei einer simplen if/else-Konstruktion die gesamte Grafikkarte (überspitzt gesagt) eine Vollbremsung einlegen und warten, bis eine einzelne ihrer ziemlich ineffizienten Rechenkerne das Ergebnis der Bedingungsabfrage ausgerechnet hat. Eine CPU hat dagegen schon für alle drei möglichen Ergebnisse die nächsten fünf Schritte vorrausberechnet, bevor überhaupt klar ist, wohin der Sprung führt (siehe branch prediction, speculative execution).

Die Aufgaben einer CPU auf einer GPU durchzuführen ist in etwas so schnell, wie die Aufgaben einer GPU auf einer CPU durchzuführen. Allerdings erhofft man sich, in der Zukunft eine beliebige Aufgabe in parallele und serielle Teile auseinanderfriemeln zu können, um gleichzeitig CPU und GPU zu füttern und so schnellstmöglich zum Ergebnis zu kommen.
 
boxleitnerb schrieb:
1. Nicht jeder Code ist schön parallelisierbar
2. Kompatibilität zu x86. Erklär mal deinem Chef, dass ihr jetzt alle Software neu kaufen müsst
Zum Vergrößern anklicken....
Stimme beiden Punkten absolut zu. Punkt 1 gilt insbesondere im Bezug auf GPUs, wenn man versuchen würde, sämtliche Rechenarbeit auf die abzuwälzen. In vielen Bereichen sind CPUs immer noch deutlich performanter.

Punkt 2 hingegen ist wohl der Hauptgrund, warum es noch x86 gibt. Denn sonst könnte man schon längst beispielsweise auf der sehr viel effizienteren (Energieverbrauch/Rechenleistung) ARM-Architektur arbeiten. Der Trend geht ja auch in die Richtung, siehe Smartphones, Tablets & Co., aber auch das kommende Windows 8, das aktuellen Informationen zur Folge auch mit ARM umgehen kann (aber eben nur, wenn auch die Anwendung das unterstützt).

Die immer noch sehr wichtige x86-Kompatibilität dürfte wohl der Faktor sein, der momentan am meisten den Fortschritt im IT-Bereich zurückhält. Und natürlich tun einerseits die Hardware-Hersteller (allen voran Intel) alles, um x86 auch weiterhin als den vorherschenden Standard zu etablieren, aber auch die Softwarehäuser haben zum Großteil kein Interesse daran, ihren Code zu portieren (da vieles von Grund auf neu entwickelt werden müsste und man die dafür nötigen Kosten nur selten in Absehbarer Zeit wieder reingeholt werden können).

Das steht sich dann gegenseitig im Weg. Kein Softwarehaus wird es wagen, einen wichtigen Release (neue Software oder neue Version) ohne x86-Kompatibilität auf den Markt zu werfen, solange noch keiner die dazugehörige Hardware hat. Gleichzeitig wird sich aber auch keiner in seinen Home- oder Office-PC eine nicht-x86-konforme CPU bauen, solange kaum Software dafür vorhanden ist (und momentan, bis zum W8 release, nichtmal ein brauchbares Desktop-Betriebssystem).
 
Bei ARM soll aber manches nicht einfach umsetzbar sein. Das ist auch keine Allzweckwaffe.
 
ARM ist auch nur ein Beispiel. Kann man auch durch "beliebige neue Architektur mit nicht-x86-konformen Befehlssatz" ersetzen ;)
 
Vielen Dank für die Antworten, vaD an KeinNameFrei und Calef!
Dann gilt es abzuwarten, was die Jungs in der Zukunft aus der ganzen Sache machen ;)
 
Die werden garnichts machen.

CISC und RISC ist hier das Zauberwort.

GPUs können nur einfache Grundrechenarten ausführen. Wenn es darum geht bestimmte Aufgaben eines Betriebsystems umzusetzen würden sie solange brauchen, dass man glaubt, man hat einen alten Toaster vor der Nase.

Sprich, GPU können Rechnen, CPUs können verwalten.
Daher wird es auch nicht möglich sein ein Betriebssystem auf der GPU laufen zu lassen, dazu ist sie zu doof.

Prozessorarchitekturen sind ein sehr komplexes Thema, gerade bei solchen Teilen, da sollte man sich das ein oder andere Fachbuch besorgen, dann lernt man was.
 
underclocker2k4 schrieb:
Sprich, GPU können Rechnen, CPUs können verwalten.
Daher wird es auch nicht möglich sein ein Betriebssystem auf der GPU laufen zu lassen, dazu ist sie zu doof.
Zum Vergrößern anklicken....

Das würde ich so nicht ganz unterschreiben.
Ich würde behaupten, dass man theoretisch nahezu jeglichen Code auf eine andere Architektur portieren kann, sofern man genug Zeit und Mühe reinsteckt.

In der Praxis gebe ich Dir natürlich insofern Recht, als dass ein Betriebssystem extrem langsam auf einer GPU laufen würde weil alles, laienhaft gesagt, permanent hin und her übersetzt werden müsste, damit auch die relativ doofen GPU Kerne das verstehen.
 
Warum es noch CPUs gibt?
Ganz einfach, weil man in aktueller Form nur mit einer CPU überhaupt eine GPU zu Berechnungen überreden kann...
Vereinfacht ausgedrückt. Ein PC läuft auch ohne Grafikausgabe und ohne GPU. Aber nicht ohne CPU.
 
Napoleon1982 schrieb:
Das würde ich so nicht ganz unterschreiben.
Ich würde behaupten, dass man theoretisch nahezu jeglichen Code auf eine andere Architektur portieren kann, sofern man genug Zeit und Mühe reinsteckt.
Zum Vergrößern anklicken....

Selbst wenn das ginge, was ich bezweifle, dann gibt es immernoch das Problem, daß ein Rechenkern einer GPU strunzdumm ist und mit einem nicht parallelisierbaren Problem richtige Probleme hat. Nicht umsonst werden GPUs in erster Linie zum numbercrunchen benutzt, denn das können sie.
 
So kann man das nicht vergleichen.

Ein Prozessor besteht nicht nur aus einer einfachen Recheneinheit, da sind noch viele Sache nebenrum, die es erst ermöglichen bestimmte Aufgaben zu erledigen.
Das hat weniger etwas mit x86 zu tun sondern eher mit dem Befehlssatz, wo wir dann wieder bei CISC vs RISC Sache sind.
Gleiches gilt für ARM. ARM war früher mal eine DER RISC CPUs schlecht hin. Im Moment ist man auf dem Weg zu CISC, immer mehr Funktionen.

Wie schon gesagt, Architekturen ist ein nicht nur abendfüllendes Programm.

Um auf das Hirnbeispiel zurückzukommen.

Was hilft es dir, wenn du super toll rechnen kannst, alles in Perfektion bis ins kleinste, aber du nicht in der Lage bis, die einfachsten, für uns völlig normalen, Vorgänge zu erledigen. Auf deutsch, vor lauter Rechenintelligenz kannst du nicht mehr laufen.
(ein Großteil der Genies hatten alle ein mehr oder weniger großes Defizit bei anderen Sachen)

Und genauso muß man sich das bei Prozessoren vorstellen.
GPU sind so weit spezielisiert, dass sie Aufgaben, die eine CPU übernehmen soll nicht leisten kann.

Es gibt eben noch andere Sachen, die eine Prozessor können muß, nicht nur 1+1 rechnen und das kann eine GPU eben nicht. (dafür kann eine CPU nicht 1000x gleichzeitig 1+1 rechnen, muß sie aber auch nicht)

Wie gesagt, Rechnerarchitektur.
Man könnte auch CPUs auf die Rechenleistung von GPUs aufbohren, aber dann wäre die DIE wohl so groß wie das MB, hätte nen paar kW Abwärme und noch ein paar andere Probleme.

Wer das eine will, muß das andere aufgeben, so einfach ist das.
Der Cell Prozessor zB ist ein Versuch des Kreuzung aus GPU und CPU.

Zu der Thematik OS auch auf einer GPU, das kann fast verneint werden.

Man muß zunächst definieren was denn das OS machen soll. Ein OS ist nicht nur Windows, ein OS ist eigentlich eine viel einfachere Struktur.
Dennoch unterstützt eine GPU bestimmte Features, die für ein einigermaßen aktuelles OS notwendig sind, einfach nicht. Jetzt könnte man meinen, da bastelt man solange hin und her, bis das passt.
Klar kann man das. Der Vorteil einer CPU ist aber, dass sie bestimmte Sachen einfach so macht, ohne dabei eigentliche Rechenoperationen durchzuführen. Das ist der Grund, warum CPUs so komplex sind. Man hat das ausgelagert, da ein (softwaretechniche) Umsetzung so viel Zeit in anspruch nehmen würde, dass es nicht vertretbar ist.
Oder würde einer hier 10mins warten bis die CPU 1GB Daten von der HDD in den RAM kopiert hat?
GPUs müßte das machen, geht nicht in der heutigen Welt.

Auf jeden Topf passt ein Deckel, man muß nur dir richtigen finden.
 
underclocker2k4 schrieb:
So kann man das nicht vergleichen.

Ein Prozessor besteht nicht nur aus einer einfachen Recheneinheit, da sind noch viele Sache nebenrum, die es erst ermöglichen bestimmte Aufgaben zu erledigen.
Das hat weniger etwas mit x86 zu tun sondern eher mit dem Befehlssatz, wo wir dann wieder bei CISC vs RISC Sache sind.
Gleiches gilt für ARM. ARM war früher mal eine DER RISC CPUs schlecht hin. Im Moment ist man auf dem Weg zu CISC, immer mehr Funktionen.

Wie schon gesagt, Architekturen ist ein nicht nur abendfüllendes Programm.

Um auf das Hirnbeispiel zurückzukommen.

Was hilft es dir, wenn du super toll rechnen kannst, alles in Perfektion bis ins kleinste, aber du nicht in der Lage bis, die einfachsten, für uns völlig normalen, Vorgänge zu erledigen. Auf deutsch, vor lauter Rechenintelligenz kannst du nicht mehr laufen.
(ein Großteil der Genies hatten alle ein mehr oder weniger großes Defizit bei anderen Sachen)

Und genauso muß man sich das bei Prozessoren vorstellen.
GPU sind so weit spezielisiert, dass sie Aufgaben, die eine CPU übernehmen soll nicht leisten kann.

Es gibt eben noch andere Sachen, die eine Prozessor können muß, nicht nur 1+1 rechnen und das kann eine GPU eben nicht. (dafür kann eine CPU nicht 1000x gleichzeitig 1+1 rechnen, muß sie aber auch nicht)

Wie gesagt, Rechnerarchitektur.
Man könnte auch CPUs auf die Rechenleistung von GPUs aufbohren, aber dann wäre die DIE wohl so groß wie das MB, hätte nen paar kW Abwärme und noch ein paar andere Probleme.

Wer das eine will, muß das andere aufgeben, so einfach ist das.
Der Cell Prozessor zB ist ein Versuch des Kreuzung aus GPU und CPU.

Zu der Thematik OS auch auf einer GPU, das kann fast verneint werden.

Man muß zunächst definieren was denn das OS machen soll. Ein OS ist nicht nur Windows, ein OS ist eigentlich eine viel einfachere Struktur.
Dennoch unterstützt eine GPU bestimmte Features, die für ein einigermaßen aktuelles OS notwendig sind, einfach nicht. Jetzt könnte man meinen, da bastelt man solange hin und her, bis das passt.
Klar kann man das. Der Vorteil einer CPU ist aber, dass sie bestimmte Sachen einfach so macht, ohne dabei eigentliche Rechenoperationen durchzuführen. Das ist der Grund, warum CPUs so komplex sind. Man hat das ausgelagert, da ein (softwaretechniche) Umsetzung so viel Zeit in anspruch nehmen würde, dass es nicht vertretbar ist.
Oder würde einer hier 10mins warten bis die CPU 1GB Daten von der HDD in den RAM kopiert hat?
GPUs müßte das machen, geht nicht in der heutigen Welt.

Auf jeden Topf passt ein Deckel, man muß nur dir richtigen finden.
Zum Vergrößern anklicken....

Wie gesagt, in der Praxis gebe ich Dir ja Recht.
Aber es hat auch mal vor langer Zeit ein Onkel Bill gesagt, dass 640 KB (!) RAM die Grenze sind weil ein Mensch niemals mehr brauchen würde. Und jetzt sitze ich vor einer Kiste mit 24 GB aktiv gekühltem RAM und kriege die ganz gut voll wenn ich zig unkomprimierte 24 Bit 96 KHz Audiospuren in einer professionellen Audiosoftware gleichzeitig laufen lasse.

Der Trend geht im Mainstream Bereich in Richung CPU und GPU auf einem Chip. Mal sehen was die Zeit so bringt.

---------- Beitrag hinzugefügt um 19:43 ---------- Vorheriger Beitrag war um 19:27 ----------
underclocker2k4 schrieb:
Wer das eine will, muß das andere aufgeben, so einfach ist das.
Der Cell Prozessor zB ist ein Versuch des Kreuzung aus GPU und CPU.
Zum Vergrößern anklicken....

Das ist so nun auch nicht ganz richtig. Von der Art der Architektur geht es zwar ein kleines bisschen in die Richtung aber mehr auch nicht. Der beste und bekannteste Beweis dafür ist die Playstation 3. In ihr werkelt ein NVidia RSX Grafikprozessor. Die SPE's in einem Cell sind zwar quasi dumme, dafür aber Massenhaft vorhandene Kerne, jedoch waren sie nie Grafikeinheiten sondern von vorne herein als Recheneinheiten konzipiert.
 
CPU und GPU in einem ist aber keine CGPU, da ist das Ding.
Nur weil ich eine GPU DIE auf einen CPU DIE bringe, wird daraus kein Chip, von dem wir hier reden.

Und das hat auch nicht mit reiner Praxis zu tun, wer das eine will, muß das andere vernachlässigen. Bestimmte Sachen sind in HW gelöst einfach schneller als in Software.

Die eierlegende Wollmilchsau wird es nie geben. Spezialisierung ist immer besser, als wenn einer alles können muß.

Wenn wir irgendwann Quantencomputer haben werden, dann werden die CPUs mit Sicherheit unsere aktuellen GPUs in der Pfeife rauchen, dann werden aber diese GPUs in der Lage sein aktuelle(zusammen) Supercomputer in Grund und Boden zu rechnen.

Dennoch wird eine QuantenCPU solche Verwaltungssachen besser lösen als eine QuantenGPU.

Wer sich noch an diese 100core CPU von Intel erinnert, genau das ist ein Versuch eine CPU extrem zu parallelisieren. -> Vektorprozessoren

Wenn das Teil aber Marktreif ist, dann werden wir wohl GPUs haben die deutlich mehr vektorisiert ist als dieser 100kerner. Wo wir dann wieder bei dem Punkt wären, dass die CPU, trotz ihrer 100Kerne, nicht in der Lage ist auch nur im Ansatz mitzuhalten.
Es entwickeln sich beide Seiten weiter.

Es ist natürlich nicht so, dass sich CPUs nicht schon bei den GPUs bedient hätten, SSE zB ist solche ein Implementation, ohne diesen Sachen wären unsere CPUs heute zu garnichts mehr zu gebrauchen.

Wie gesagt, man könnte auch Vektorprozessoren auf Basis von CPU Cores baun, nur laufen da soviele Sachen mit, die keiner braucht, dass es sich nicht rentieren würde.
Daher läßt man diese Sachen weg, der Ergebnis ist eine GPU.

Wie gesagt, es gibt bereit heute solche Zwitterlösungen, zB Cell oder Itanium.
Bei letzterem hat man gesehn, wohin diese Entwicklung führen kann.
Die CPU war nicht in der Lage x86 in HW zu machen, was umständlich über Software (was du vorgeschlagen hattest) gelöst werden mußte.
Ergebnis war eine CPU, welche für normale OSs nicht zu gebrauchen war, dazu langsam. Dafür konnte das Teil ordentlich crunchen.

Sprich, es gibt Versuche, diese sind aber bisher nicht wirklich geglückt.

Man müßte für sowas entsprechende OSs schreiben, bzw wird das auch gemacht.
Im HPC macht man sowas nur, aber damit kann eben keiner sein Word benutzen.

Wie gesagt, spannende Sache.
 
Zuletzt bearbeitet:
KeinNameFrei schrieb:
Hat er nicht ;)
Zum Vergrößern anklicken....

2001, als in etwa 256 MB bis 1 GB RAM üblich waren, war es dann natürlich im nachhinein politisch klüger das Gegenteil zu behaupten. ;)

Aber dennoch war die Beschränkung da und keiner kann mir erzählen, dass man es nicht anders coden konnte! Selbst ein UNIX mit Technik aus den 60ern konnte schon mehr RAM ansprechen.

---------- Beitrag hinzugefügt um 19:52 ---------- Vorheriger Beitrag war um 19:47 ----------
underclocker2k4 schrieb:
CPU und GPU in einem ist aber keine CGPU, da ist das Ding.
Nur weil ich eine GPU DIE auf einen CPU DIE bringe, wird daraus kein Chip, von dem wir hier reden.

Und das hat auch nicht mit reiner Praxis zu tun, wer das eine will, muß das andere vernachlässigen. Bestimmte Sachen sind in HW gelöst einfach schneller als in Software.

Die eierlegende Wollmilchsau wird es nie geben. Spezialisierung ist immer besser, als wenn einer alles können muß.

Wenn wir irgendwann Quantencomputer haben werden, dann werden die CPUs mit Sicherheit unsere aktuellen GPUs in der Pfeife rauchen, dann werden aber diese GPUs in der Lage sein aktuelle(zusammen) Supercomputer in Grund und Boden zu rechnen.

Dennoch wird eine QuantenCPU solche Verwaltungssachen besser lösen als eine QuantenGPU.

Wer sich noch an diese 100core CPU von Intel erinnert, genau das ist ein Versuch eine CPU extrem zu parallelisieren. -> Vektorprozessoren

Wenn das Teil aber Marktreif ist, dann werden wir wohl GPUs haben die deutlich mehr vektorisiert ist als dieser 100kerner. Wo wir dann wieder bei dem Punkt wären, dass die CPU, trotz ihrer 100Kerne, nicht in der Lage ist auch nur im Ansatz mitzuhalten.
Es entwickeln sich beide Seiten weiter.

Es ist natürlich nicht so, dass sich CPUs nicht schon bei den GPUs bedient hätten, SSE zB ist solche ein Implementation, ohne diesen Sachen wären unsere CPUs heute zu garnichts mehr zu gebrauchen.

Wie gesagt, man könnte auch Vektorprozessoren auf Basis von CPU Cores baun, nur laufen da soviele Sachen mit, die keiner brauch, dass es sich nicht rentieren würde.
Daher läßt man diese Sachen weg, der Ergebnis ist eine GPU.

Wie gesagt, es gibt bereit heute solche Zwitterlösungen, Cell oder Itanium.
Bei letzterem hat man gesehn, wohin diese Entwicklung führen kann.
Die CPU war nicht in der Lage x86 in HW zu machen, was umständlich über Software (was du vorgeschlagen hattest) gelöst werden mußte.
Ergebnis war eine CPU, welche für normale OSs nicht zu gebrauchen war, dazu langsam. Dafür konnte das Teil ordentlich crunchen.

Sprich, es gibt Versuche, diese sind aber bisher nicht wirklich geglückt.

Man müßte für sowas entsprechende OSs schreiben, bzw wird das auch gemacht.
Im HPC macht man sowas nur, aber damit kann eben keiner sein Word benutzen.

Wie gesagt, spannende Sache.
Zum Vergrößern anklicken....

Und was sagt uns das letztenendes?
Was auch immer die Berechnungen letztenendes durchführt, der Flaschenhals ist schon lange nicht mehr die Hardware sondern die Software.

Die Spiele z.B. sind ja heute nicht unbedingt 100 mal so gut/hochauflösung oder was auch immer, obwohl die GPU's entsprechendes zu leisten vermögen als vor 15 Jahren oder so.

---------- Beitrag hinzugefügt um 19:52 ---------- Vorheriger Beitrag war um 19:47 ----------
Napoleon1982 schrieb:
2001, als in etwa 256 MB bis 1 GB RAM üblich waren, war es dann natürlich im nachhinein politisch klüger das Gegenteil zu behaupten. ;)

Aber dennoch war die Beschränkung da und keiner kann mir erzählen, dass man es nicht anders coden konnte! Selbst ein UNIX mit Technik aus den 60ern konnte schon mehr RAM ansprechen.

---------- Beitrag hinzugefügt um 19:52 ---------- Vorheriger Beitrag war um 19:47 ----------



Und was sagt uns das letztenendes?
Was auch immer die Berechnungen letztenendes durchführt, der Flaschenhals ist schon lange nicht mehr die Hardware sondern die Software.

Die Spiele z.B. sind ja heute nicht unbedingt 100 mal so gut/hochauflösung oder was auch immer, obwohl die GPU's entsprechendes zu leisten vermögen als vor 15 Jahren oder so.
Zum Vergrößern anklicken....

Ergo:
Assembler rulez, auch wenns ne scheiß Arbeit ist! ;)
 
underclocker2k4 schrieb:
Wenn wir irgendwann Quantencomputer haben werden, dann werden die CPUs mit Sicherheit unsere aktuellen GPUs in der Pfeife rauchen, dann werden aber diese GPUs in der Lage sein aktuelle(zusammen) Supercomputer in Grund und Boden zu rechnen.
Zum Vergrößern anklicken....
Ist nicht ein Quantencomputer auch vor allem für massiv parallelisierte Aufgaben gut?
 
Anmelden, um zu antworten.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh