Der GPU-CPU-Krieg - Intel wirft einen Blick in die Zukunft

[AnarchX]

B3D hat einem interessanten Artikel die Präsentation von Intel zu diesem Thema zusammengefasst:


B3D: Intel presentation reveals the future of the CPU-GPU war (http://www.beyond3d.com/content/articles/31/1)
http://img375.imageshack.us/img375/1092/image6bigov8.jpg



Da scheint Intel wohl sich bedroht zu sehen, aber mit VCG hat man ja schon erste Maßnahmen unternommen.

[Gast]

hm, eigentlich könnte man DX10 schon in den general-purpose-bereich schreiben ;)

[=Floi=]

http://www.beyond3d.com/images/articles/IntelFuture/Image10-big.jpg
wenn das ein ausblick auf den nehalem wäre... :rolleyes:

[dildo4u]

Intel hat im Labor doch schon eine 80 Core CPU am laufen die bei 5.46Ghz ca 1800 G-Flops schafft.


Quelle: PCGH 5/2007

[AnarchX]

hm, eigentlich könnte man DX10 schon in den general-purpose-bereich schreiben ;)
Generell scheint Intel die GPUs in dieser Presentation etwas herunterzuspielen.;)

http://www.beyond3d.com/images/articles/IntelFuture/Image10-big.jpg
wenn das ein ausblick auf den nehalem wäre... :rolleyes:
Das linke Design sieht mir sehr nach Nehalem aus, wobei dies im Kontext eher nicht passt.

Intel hat im Labor doch schon eine 80 Core CPU am laufen die bei 5.46Ghz ca 1800 G-Flops schafft.

Ja, das ist Terascale, welcher aber kein direktes Design für die Zukunft darstellen soll, sondern ein Testobjekt für verschiedene Technologien, die in zukünftige CPUs Einzug halten könnten.



Aber wie schon gesagt ist es ein Blick in die Zukunft, vor 2010 würde ich da eher keine Situation erwarten, die man als "Krieg" bezeichnen kann.

[Demirug]

Generell scheint Intel die GPUs in dieser Presentation etwas herunterzuspielen.;)

Das Ding ist in der Beziehung noch harmlos.

Erinnert sich noch jemand an „MMX macht die 3D Beschleuniger überflüssig“? Davon gibt es inzwischen sowas wie die zweite Auflage.

[Schrotti]

Das Ding ist in der Beziehung noch harmlos.

Erinnert sich noch jemand an „MMX macht die 3D Beschleuniger überflüssig“? Davon gibt es inzwischen sowas wie die zweite Auflage.

Dazu kann ich den Artikel empfehlen.

Großspurig -> Ein kritischer Blick auf MMX (http://www.heise.de/ct/97/01/228/)

Quelle: Heise Verlag (www.heise.de/ct)

[Gast]

General Purpose macht aus Sicht eines GPU-Designers doch gar keinen Sinn. Damit wird doch genau der Vorteil nivelliert, den eine GPU auszeichnet: durch ihre Spezialisierung ist sie in ihrer Sparte einer CPU überlegen. Oder gilt dieser Umstand nichts mehr und überrascht NVidia demnächst mit einer Wunder-CPU, die das Mooresche Gesetz (in volkstümlicher Auslegung) Lügen straft, in dem sie mit brachialer Leistung Intels dann aktuelle Prozessorgeneration im Vergleich aussehen lässt wie einen archaischen Z80?

Ich glaube nicht, Tim. Die Jungs von Intel designen ja nicht erst seit gestern CPUs, genaugenommen tun sie es schon deutlich länger als NVidia und Co. Und das sie auch "zaubern" können, haben sie mit dem C2D bewiesen.

Eher mag sich eine Annäherung zwischen Intel/NVidia ergeben, im Gegenzug zu dem Aufkauf von ATi durch AMD.

[StefanV]

Das eine widerspricht dem anderen ja nicht!

GPUs sind nunmal GPUs und in erster Linie dazu gedacht, 3D Berechnungen zu berechnen.
Das man mit ihnen aber auch hervorragend Proteine falten kann, ist nur ein Nebeneffekt.
Das das ganze dann um einiges schneller als von einer echten GP CPU von statten geht, wundert da aber auch nicht...

Denn wie mans dreht und wendet, Spezialprozessoren sind für die entsprechenden Anwendungen sinniger als ein einzelner Prozessor, das wussten sogar die alten Computerdesigner und haben ihre Systeme damals, als Rechenleistung knapp war, entsprechend aufgebaut (Videoprozessor, 'CPU', Audioprozessor).

[DarkSoldier]

wenn man dem ersten Bild Glauben schenken darf würde das bedeuten, dass irgendwann mal GPU=CPU darstellen würde

zumindest annäherungsweise

und das lustige ist, dass sie aus 2 verschiedenen Richtungen ursprünglich kommen, sich aber immer ähnlicher werden

[Spasstiger]

hm, eigentlich könnte man DX10 schon in den general-purpose-bereich schreiben ;)
Naja, schreibt D3D10.1 schon double precision vor? Ich glaube nicht. Und nur mit single precision würde ich noch nicht von general purpose sprechen.
Und die GeForce 8 unterstützt bisher eh nur single precision.
Ist schon richtig so, dass DX10 vor den Übergang von "programmable" zu "general purpose" gesetzt wurde.

Verwenden GPUs eigentlich schon solche Dinge wie branch prediction units oder reservation stations für out-of-order execution?

P.S.: Sorry, für das Denglisch, aber die Begriffe kommen nunmal aus dem Englischsprachigen und werden so auch in der Fachsprache verwendet. ;)

wenn man dem ersten Bild Glauben schenken darf würde das bedeuten, dass irgendwann mal GPU=CPU darstellen würde
Jopp, so kann man das durchaus deuten. GPUs weisen traditionell mehr Parallelität auf als CPUs. Dafür sind die CPUs traditionell universeller einsetzbar. In letzter Zeit bekommen die CPUs deutlich mehr Parallelität, die GPUs deutlich mehr Funktionalität.
Die Parallelität nimmt bei den GPUs der ersten DX10-Generation dagegen nur relativ wenig zu gegenüber der letzten DX9-Generation, eine Verdoppelung erleben wir nicht. Der G80 hat z.B. acht "Quadpipes", der G70/G71 auch schon sechs "Quadpipes". Die Zahl der Shader-ALUs in skalare Anteile umgerechnet hat sogar abgenommen (192 ps + 40 vs beim G70/G71, 128 us beim G80).

[Gast]

Das eine widerspricht dem anderen ja nicht!

GPUs sind nunmal GPUs und in erster Linie dazu gedacht, 3D Berechnungen zu berechnen.
Das man mit ihnen aber auch hervorragend Proteine falten kann, ist nur ein Nebeneffekt.
Das das ganze dann um einiges schneller als von einer echten GP CPU von statten geht, wundert da aber auch nicht...

Denn wie mans dreht und wendet, Spezialprozessoren sind für die entsprechenden Anwendungen sinniger als ein einzelner Prozessor, das wussten sogar die alten Computerdesigner und haben ihre Systeme damals, als Rechenleistung knapp war, entsprechend aufgebaut (Videoprozessor, 'CPU', Audioprozessor).

Soweit ich Einblick in die Materie habe (nicht viel, nur das, was ich von E-Technik-Bekannten höre) stimmt dies so nicht mehr. Mittlerweile nimmt man für alle möglichen Aufgaben 08/15-Standardprozessoren und programmiert diese für den entsprechenden Einsatz. Das ist billiger als die Entwicklung eines auf die Anwendung abgestimmten Spezialprozessors. Das Spezialprossesoren sinniger sind bezweifelt wohl keiner, aber in der Kosten/Nutzen-Betrachtung schneiden sie immer öfter schlechter ab.

[HellHorse]

Intel hat im Labor doch schon eine 80 Core CPU am laufen die bei 5.46Ghz ca 1800 G-Flops schafft.
Von denen auf dem Desktop (und dort verkauft Intel nun mal seine CPU) bloss zwei Achtigstel genutzt werden. Da macht es schon Sinn, krankhaft nach einer Verwendung für die restlichen 97.5% Rechenkapazität zu suchen.

Ach ja, Intel und Zukunftsplandung:
http://www.theinquirer.net/default.aspx?article=11785
http://www.theinquirer.net/default.aspx?article=7481

P.S.:
Ja ich weiss, dass nächsten Monat super viele DualCore Games erscheinen werden. Ist schon seit einem Jahr so.

[Spasstiger]

Von denen auf dem Desktop (und dort verkauft Intel nun mal seine CPU) bloss zwei Achtigstel genutzt werden.
Mit Hilfe von Polaris - so heißt dieser 80-Kern-Prototyp von Intel - sollen aber Verfahren entwickelt werden, die Befehle unabhängig vom Betriebssystem in Hardware auf die Kerne verteilen. Das steckt natürlich einiges an Know-How dahinter.
Klar wird man mit so vielen Kernen zukünftig wohl noch mehr anstellen, rudimentäre 3D-Grafik wie den Vista-Desktop oder Google Earth könnte dann die CPU alleine übernehmen, man braucht keine Extra-Grafikkarte.

[Gast]

Mit Hilfe von Polaris - so heißt dieser 80-Kern-Prototyp von Intel - sollen aber Verfahren entwickelt werden, die Befehle unabhängig vom Betriebssystem in Hardware auf die Kerne verteilen. Das steckt natürlich einiges an Know-How dahinter.
Klar wird man mit so vielen Kernen zukünftig wohl noch mehr anstellen, rudimentäre 3D-Grafik wie den Vista-Desktop oder Google Earth könnte dann die CPU alleine übernehmen, man braucht keine Extra-Grafikkarte.

Das ist imho der einzig gangbare Weg und es wird bestimmt noch eine ganze Weile dauern, bis es zufriedenstellend funktioniert. Aber bleibt auch da nicht das Problem bei "Berechnungen", die sich nicht "parallelisieren" lassen?

[Gast]

Ja das Problem bleibt natürlich. Deswegen wirds auch eher heterogene Cores geben und Software wird ein bisschen komplexer um mehr Rechenleistung zu "verschwenden".

[Spasstiger]

Aber bleibt auch da nicht das Problem bei "Berechnungen", die sich nicht "parallelisieren" lassen?
Doch, bleibt es. Hier mal eine Grafik aus der Intel-Präsentation zum "Teraflop Research Chip" Polaris:

http://img245.imageshack.us/img245/9791/terascalepq9.png
Quelle: http://www.turbogadgets.com/wp-content/uploads/2007/02/teraflops_research_chip.pdf

Wie man sieht, würde bei einer reinen Erhöhung der Core-Anzahl die Performance ab einer gewissen Grenze (hier ca. 16 Cores) sogar wieder sinken. Auch mit Unterstützung durch Tera-Scale Research erwartet Intel bei mehr als 8 Kernen keine 1:1-Skalierung mehr.

[Gast]

Doch, bleibt es. Hier mal eine Grafik aus der Intel-Präsentation zum "Teraflop Research Chip" Polaris:

http://img245.imageshack.us/img245/9791/terascalepq9.png
Quelle: http://www.turbogadgets.com/wp-content/uploads/2007/02/teraflops_research_chip.pdf

Wie man sieht, würde bei einer reinen Erhöhung der Core-Anzahl die Performance ab einer gewissen Grenze (hier ca. 16 Cores) sogar wieder sinken. Auch mit Unterstützung durch Tera-Scale Research erwartet Intel bei mehr als 8 Kernen keine 1:1-Skalierung mehr.
Kleine Korrektur: Der Performance-Zuwachs wird rückläufig. Die Gesamtperformance steigt natürlich weiter an. Der Grund: Nicht jedes Problem ist parallelisierbar.


Q

[Spasstiger]

Kleine Korrektur: Der Performance-Zuwachs wird rückläufig. Die Gesamtperformance steigt natürlich weiter an.
Für mich bedeutet eine Veränderung des Performancezuwachses (gegenüber einem Core) von einem Faktor ~4 auf einen Faktor ~3, dass die Performance sinkt.
In der PC Games Hardware steht:
Bis zu einer Menge von circa 16 Kernen steigt die Geschwindigkeit nach Angaben von Intel, danach fällt sie aber rapide ab.

Ich nehme mal an, dass das vom Verwaltungsoverhead kommt.

[ScottManDeath]

Amddahl's Law (http://en.wikipedia.org/wiki/Amdahl's_law)

Oder so gesagt: Angenommen, ich habe ein Programm, welches zu 1% seriellen Code hat und zu 99% parallelisierbaren Code, dann kann ich maximal 100 mal so schnell werden, wenn ich die 99% parallelisierbaren Code auf unendlich viele Prozessoren verteile, und damit die Zeit dafuer auf 0 druecke.

In der Praxis haben wir meist weniger als 99% parallelisierbaren Code und auch weniger als unendlich viele Prozessoren, d.h. wir werden keine utopischen Performancesteigerungen durch n-Cores erwarten koennen.



So, ich geh erstmal weiter CUDA kernel hack0rn =)

[BAGZZlash]

Für mich bedeutet eine Veränderung des Performancezuwachses (gegenüber einem Core) von einem Faktor ~4 auf einen Faktor ~3, dass die Performance sinkt.


Was ein Blödsinn. Dann denk' nochmal genau darüber nach. :rolleyes:

[stav0815]

Für mich bedeutet eine Veränderung des Performancezuwachses (gegenüber einem Core) von einem Faktor ~4 auf einen Faktor ~3, dass die Performance sinkt.

Dann sinkt der Zuwachs, nicht aber die Performance!

[Spasstiger]

Was ein Blödsinn. Dann denk' nochmal genau darüber nach. :rolleyes:
Naja, kennst du nicht das Sprichwort: Viele Köche verderben den Brei?
Und wenn das, was ich schreibe, Blödsinn ist, dann ist auch das in der PC Games Hardware Blödsinn und die Intel-Grafik wäre ebenfalls Blödsinn.
Sollten die Balken einen prozentualen Zuwachs anzeigen, dann dürfte bei einem Kern gar kein Balken stehen. Demzufolge handelt es sich um einen Geschwindigkeitsfaktor, der bei einem Kern genau 1 ist. Bei 16 Kernen hätte man demnach rund einen Faktor 4, bei 32 Kernen nur noch rund Faktor 3.
Was ist nun schneller, Faktor 4 oder Faktor 3 gegenüber Faktor 1 bei einem Kern?

[BAGZZlash]

Naja, kennst du nicht das Sprichwort: Viele Köche verderben den Brei?
Und wenn das, was ich schreibe, Blödsinn ist, dann ist auch das in der PC Games Hardware Blödsinn und die Intel-Grafik wäre ebenfalls Blödsinn.
Sollten die Balken einen prozentualen Zuwachs anzeigen, dann dürfte bei einem Kern gar kein Balken stehen. Demzufolge handelt es sich um einen Geschwindigkeitsfaktor, der bei einem Kern genau 1 ist. Bei 16 Kernen hätte man demnach rund einen Faktor 4, bei 32 Kernen nur noch rund Faktor 3.
Was ist nun schneller, Faktor 4 oder Faktor 3 gegenüber Faktor 1 bei einem Kern?

Du hast am Montag einen Apfel. Am Dienstag gebe ich Dir einen Apfel. Am Mittwoch gebe ich Dir zwei, am Donnerstag drei. Steigender Zuwachs. Zwischensumme: Wie viele Äpfel hast Du am Donnerstag Abend? Sieben. Am Freitag gebe ich Dir nur zwei Äpfel. Der Zuwachs sinkt. Trotzdem hast Du am Freitag Abend nicht weniger Äpfel als am Donnerstag, sondern sogar mehr, nämlich neun. Wenn der Zuwachs sinkt, steigt trotzdem der absolute Bestand. So ist die Intel-Grafik gemeint: Die Ordinate ist mit "performance increase" beschriftet, also Leistungszuwachs. Durch simples Hinzufügen von Kernen soll also der Zuwachs irgendwann sinken. Trotzdem steigt natürlich die absolute Leistung weiter an. Stav0815 hat's verstanden.
Hey, nicht böse sein, okay? Sonst lese ich sehr gerne, was Du hier beiträgst, das meine ich ernst.

[Ganon]

Oder um es mal ganz simpel auszudrücken:

Mit einem Core hast du 10 fps. Mit 2 Cores 20 fps. Mit 4 Cores hast du 35fps. Mit 8 Cores hast du 40fps. Mit 16 Cores hast du 42fps und mit 32Cores hast du 43 fps.

Die Leistung steigt, aber nicht so stark, wie beim Umstieg von 1 auf 2 Cores. ;) Also ist der Balken "Performancezuwachs" kleiner als von 1 auf 2 Cores. Mehr Leistung hast du aber trotzdem.

Passt jetzt nicht zur Grafik, aber vom Prinzip her sollte es hinkommen. ;)

[Spasstiger]

Die PCGH schreibt aber in einer Zwischenüberschrift: "Mehr Kerne, weniger Leistung?" und beantwortet die Frage mit "ja".
Außerdem müsste der Zuwachs nach eurer Argumentation ja stetig fallen und nicht erst steigen und dann plötzlich fallen. Es ist auch seltsam, dass durch Tera-Scale-Research der Zuwachs stetig wachsen soll. Das wäre ja dann ein quadratischer Anstieg der Performance mit der Anzahl der Kerne.
Und für was sollen eurer Meinung nach die Zahlen bei "Performance-Increase" stehen? Etwa %? Meiner Meinung nach sind das einfach nur Faktoren. Denn wie sollte man dann den Wert 1 für den Performance Increase bei einem Kern begründen? Das geht ja nur über Faktoren.
Und wenn man von Faktoren ausgeht, dann kommt man käme man bei der Steigerung von 32 auf 64 Kerne nach eurer Argumentation mit Tera-Scale-Research auf eine Performancesteigerung um den Faktor 26. Und das bei nur einer Verdoppelung der Kernzahl?

Also eure Argumentation halte ich für sehr weit hergeholt und passt auf diese Grafik nichtmal ansatzweise.

/EDIT: Das einzige, was noch denkbar wäre und was auch auf eure Argumentation passt: Die Werte bei Performance Increase stellen weder Faktoren noch Prozentzahlen dar, sondern Kernzahl-Auqivalente. D.h. bei einer Steigerung der Kernzahl von 32 auf 64 Kerne steigt die Performance als würde man 26 voll arbeitende Kerne hinzufügen.
Der Wert bei einem Core macht dann auch Sinn.
Sollte die Grafik so interpretiert werden, hat die PCGH sich wohl einen groben Schnitzer geleistet bzw. der zuständige Redakteur Christian Gögelein. Oder er hat das richtige gemeint, es aber textuell nicht klar genug rübergebracht.

[Ganon]

Deine erste Argumentation würde passen, wenn an der linken Seite nur "Performace" (also absolute Performance) stehen würde. Aber es ist doch klar von "Performancesteigerung" die Rede.

Wenn es langsamer werden würde, müsste der Balken ins negative gehen.

[pancho]

Wieso negativ? Wenn die Steigerung der Geschwindigkeit immer im Vergleich zu einem Kern betrachtet wird, passt die Sichtweise von Spasstiger genau. IMO lohnt es nicht, darüber zu streiten, weil ich dieses Diagramm für Marketing-Geblubber halte. Dass ein Prozessor mit vielen (vielen vielen) Kernen mit heutiger Technologie nicht glücklich macht, wird durch das bereits genannte Amddahl's Law doch hinreichend klar. Folglich besteht Entwicklungsbedarf. Und das ist IMO die Kernaussage dieses Diagramms.

[Gast]

Wieso negativ? Wenn die Steigerung der Geschwindigkeit immer im Vergleich zu einem Kern betrachtet wird, passt die Sichtweise von Spasstiger genau.

Was soll da passen? Das passt überhaupt nicht. Im schlimmsten Fall bringt ein zusätzlicher Kern keine weitere Geschwindigkeit, was etas vollkommen anderes als negativ ist. Der Gesamtwachstum steigt bis er ab einer gewissen Kernanzahl stagniert oder zum Stillstand kommt.

[micki]

Amddahl's Law (http://en.wikipedia.org/wiki/Amdahl's_law)

Oder so gesagt: Angenommen, ich habe ein Programm, welches zu 1% seriellen Code hat und zu 99% parallelisierbaren Code, dann kann ich maximal 100 mal so schnell werden, wenn ich die 99% parallelisierbaren Code auf unendlich viele Prozessoren verteile, und damit die Zeit dafuer auf 0 druecke.

In der Praxis haben wir meist weniger als 99% parallelisierbaren Code und auch weniger als unendlich viele Prozessoren, d.h. wir werden keine utopischen Performancesteigerungen durch n-Cores erwarten koennen.die law is fuer'n arsch. es kommt so ziemlich garnicht drauf an wieviel von welcher codeart vorhanden ist, sondern lediglich wieviel last sierieller/paraller code macht und da fangen wir erst an zu parallelisieren, sonst war serielle abarbeitung immer weit schneller und wir haben uns ja darauf eingestellt.

fuer mich schaut das intel diagram da (um die 4MB cache mit 8in-order cpus)nach cell aus. ich glaube das loesung liegt irgendwo dazwischen, zwischen komplett in-order und dem was wir gerade haben, da zZ schon viel mehr aufwand getrieben wird als nutzen dabei rauskommt. 8cores mit inetwa der pipeline vom Pentium (natuerlich mit SSE und genug rechenwerken) waeren ne gute loesung, alternativ viel mehr register :)

[Gast]

die law is fuer'n arsch. es kommt so ziemlich garnicht drauf an wieviel von welcher codeart vorhanden ist, sondern lediglich wieviel last sierieller/paraller code macht und da fangen wir erst an zu parallelisieren, sonst war serielle abarbeitung immer weit schneller und wir haben uns ja darauf eingestellt.


Verstehe ich nicht, darauf solltest du mal näher eingehen.


fuer mich schaut das intel diagram da (um die 4MB cache mit 8in-order cpus)nach cell aus.


Für mich sieht das überhaupt nicht nach CELL aus. Der CELL kann nur zwei HT Threads und die SPUs müssen asynchron von diesen heraus angesprochen werden und können auch nur bestimmten Code gut verarbeiten. Dass in dem Intel Diagramm nur In-Order Kerne sind, ist doch reine Kosteneinsparung, da die Wahrscheinlichkeit des Stallen bei so einer großen Parallelisierung sinkt. Würde ich jetzt zumindest vermuten.

[Gast]

Also eure Argumentation halte ich für sehr weit hergeholt und passt auf diese Grafik nichtmal ansatzweise.


die grafik zeigt die relative performancesteigerung durch mehrere cores.

bei einem core ist die relative performance auch 1. bei 2 dürfte sie auch rund 2 sein, bei 4, 4 und bei 8 auch noch ~7-8 (laut dieser grafik)

bei 16 cores haben wir nur mehr eine performancesteigerung um den faktor 13, bei 32 cores nicht ganz 20 und bei 64 cores ~26. die performance steigt also stetig an, lediglich der aufwand für den gleichen performancezuwachs wird immer größer

[mickii]

Verstehe ich nicht, darauf solltest du mal näher eingehen.
vielleicht wird das anhand eines beispieles besser deutlich. nehmen wir mal winamp, die software hat massig gui-code, massig internet-protocol-code, dateihandling, datenbankzeug fuer playlists und natuerlich den mp3 decoder. sagen wir mal 90% des codes ist zwingend zeriel und nur 10% ist parallelisierbar, naemlich der teil der mp3 decodet.
nun spielst du dein mp3 ab und siehst dass du deine cpu voll auslastet (ist ja nru ein beispiel ;) ). da 90% seriell ist, kannst du nun die last laut dem gesetzt auf 90% runterschrauben bzw performance um 1.11..fache verbessern. wenn du aber einen profiler drueberlaufen laesst siehst du das 99% der last im decoder ist, den du laut der law eigentlich auf 0 optimieren kannst, somit hast du dann reel 1% last durch den seriellen code am ende.

deswegen sagt die verteilung im code auf seriel/parallel so ziemlich nichts darueber aus wie weit durch parallelisierung die performance gesteigert werden kann.



Für mich sieht das überhaupt nicht nach CELL aus. Der CELL kann nur zwei HT Threads und die SPUs müssen asynchron von diesen heraus angesprochen werdendas ist eine fehlinformation der du erlegen bist. die SPUs koennen unabhaengig von den PPU threads laufen und beliebigen code ausfuehren. es ist eventuell sinnig die weniger starken ppu-threads als lastverteiler arbeiten zu lassen, aber rein theoretisch koennte jede spu ein 100MB musikstueck in jeweils ein ganz anderes format konvertieren.
das einzige fast der spu fehlt ist ein automatischer zugriff auf den speicher, sie muss quasi das cachen explizit im code haben, nicht implizit ueber nen controller.

Dass in dem Intel Diagramm nur In-Order Kerne sind, ist doch reine Kosteneinsparung, da die Wahrscheinlichkeit des Stallen bei so einer großen Parallelisierung sinkt. Würde ich jetzt zumindest vermuten.
das haengt sehr von der implementierung von "in order" und von dem anwendungsgebiet ab.
GPUs arbeiten ja auch "InOrder", aber nur weil sie mittels ihren "threads" die latenz (die ja trotzdem vorhanden ist) verstecken koennen. so aenlich wie bei HyperThreading.
hast du software die aber nicht vom rechnen her, sondern von daten her limitiert ist, ist dieses threading absolut nutzlos, denn egal ob du eine cpu/spu hast die gerade 8GB kopiert oder ob du 128cpu/spu hast die das machen, sie werden alle auf den speicher warten.

das ist der grund weshalb sowohl intel massig cache verbaut, als auch amd nun L3 verbauen wird (und weshalb GPUs das kaum brauchen). CPUs arbeiten nunmal auf den daten, je mehr cores vorhanden sind, desto mehr verschiedene quellpunkte und ziele gibt es fuer daten, das heisst, dass vom speicher immer mehr random gelesen wird (es gibt natuerlich ausnahmen wo das nicht der fall ist!). aber DDR, DDR2, (GDDR3 GDDR4...) haben immer groessere latenzen und werden auf bandbreite optimiert. du kannst also wirklich massig daten streamen (was bei GPUs mit texturen, vertices etc. ja auch super ist). bei cpus aber kontraproduktiv ist. wenn du z.b. nen server hast, der hat nun 128Cores und soll in 128 datenbanken abfragen erledigen, dann liest die cpu (aus controller sicht) wie zufaellig im ganzen ram rum.

das ist dann auch ein zweiter grund weshalb die menge des seriellen/parallelen codes nicht das mass fuer performance ist. die auslegung der daten ist ebenfalls wichtig. sparst du speicher, indem du komprimiertere daten verwendest die zwar mehr rechenleistung brauchen (mehr code ;) ), aber am ende virtuell eine cachegroessen verdoppelung bringen, hast du eventuel trotz mehr rechenaufwand auf der cpu (den einzelnen cores) einen performancegewinn (also auch wenn der source nicht weiter parallelisiert werden koennte und sozusagen seinen peak erreicht hat, kann man dann doch fuer parallelisierung optimieren, indem man den code "langsammer" macht, was auf singlecores auch langsam waere, auf multicore das gesamtsystem aber verbessert).


korrigiert ruhig wenn ich mich irgendwo irren sollte ;)

[Gast]

die law is fuer'n arsch. es kommt so ziemlich garnicht drauf an wieviel von welcher codeart vorhanden ist, sondern lediglich wieviel last sierieller/paraller code macht und da fangen wir erst an zu parallelisieren, sonst war serielle abarbeitung immer weit schneller und wir haben uns ja darauf eingestellt.
Endlich mal jemand vernünftiges.
Der performancefressende Code ist eigentlich fast immer komplett parallelisierbar. Die meisten Leute scheinen den Unterschied zwischen Overhead und seriellem Code nicht zu kennen.

[Gast]

wenn du aber einen profiler drueberlaufen laesst siehst du das 99% der last im decoder ist, den du laut der law eigentlich auf 0 optimieren kannst, somit hast du dann reel 1% last durch den seriellen code am ende.

deswegen sagt die verteilung im code auf seriel/parallel so ziemlich nichts darueber aus wie weit durch parallelisierung die performance gesteigert werden kann.


Das hat doch damit überhaupt nichts zu tun. Wieviel Last erzeugt wird sagt dir aus wieviel zusätzliche Prozessoren du brauchst, um eben die 10% parallelen Code auf 0 zu drücken. Wenn der Profiler bei dir 99% CPU Auslastung sagt (was ich für MP3 Dekodierung auf heutigen CPUs recht seltsam finde), dann brauchst du offensichtlich mehr CPUs.


das ist eine fehlinformation der du erlegen bist. die SPUs koennen unabhaengig von den PPU threads laufen und beliebigen code ausfuehren. es ist eventuell sinnig die weniger starken ppu-threads als lastverteiler arbeiten zu lassen, aber rein theoretisch koennte jede spu ein 100MB musikstueck in jeweils ein ganz anderes format konvertieren.
das einzige fast der spu fehlt ist ein automatischer zugriff auf den speicher, sie muss quasi das cachen explizit im code haben, nicht implizit ueber nen controller.


Die SPUs können keine Threads selbst ausführen, nur die PPU. Die Threads auf der PPU müssen dann Aufgaben an die SPU delegieren, sich aber auch um die Synchronisation kümmern. Das ist fundamental anders als eine reine Multicore-Lösung.

[Gast]

Die SPUs können keine Threads selbst ausführen, nur die PPU. Die Threads auf der PPU müssen dann Aufgaben an die SPU delegieren, sich aber auch um die Synchronisation kümmern. Das ist fundamental anders als eine reine Multicore-Lösung.
Ich möchte langsam mal wissen wo dieses Gerücht herkommt.
Die SPUs können auf den kompletten Hauptspeicher zugreifen und miteinander kommunzieren. Das es sinnvoll sein kann die PPU die Synchronisation machen zu lassen ist ja manchmal richtig, aber die SPEs können alles selber machen.

[HellHorse]

Der performancefressende Code ist eigentlich fast immer komplett parallelisierbar. Die meisten Leute scheinen den Unterschied zwischen Overhead und seriellem Code nicht zu kennen.
Ja nee, is klar. Dann parallelisiere doch bitte mal die Firefox rendering engine, layout engine und JS engine und Excel und Word. Das sind Desktopapplikationen, die eine CPU schon mal zu hundert Prozent auslasten können. Also genau der Fall, für den Intel eigentlich Prozessoren machen müsste.

[Gast]

Ich möchte langsam mal wissen wo dieses Gerücht herkommt.
Die SPUs können auf den kompletten Hauptspeicher zugreifen und miteinander kommunzieren. Das es sinnvoll sein kann die PPU die Synchronisation machen zu lassen ist ja manchmal richtig, aber die SPEs können alles selber machen.

Das ist kein Gerücht, sondern Tatsache. Die PPU kümmert sich darum, die SPUs mit Jobs zu füttern. Die SPUs sind nicht komplett autonom, da sie von der PPU erst gestartet werden müssen.

[Gast]

Ja nee, is klar. Dann parallelisiere doch bitte mal die Firefox rendering engine, layout engine ... Excel und Word.
Wer diese Applikationen nicht im Durchschnittsfall fast komplett parallelisiert bekommt, will es einfach nicht.
Rendering Engine? Selbst in 2D Paradebeispiel, das man verteilen kann.
Excel? Operationen auf größeren Datensätzen sind prädestiniert dafür.
Word? Nun ja. Das einzige was daran langsam ist, ist momentan das Rendering. Das lässt sich auch gut parallelisieren. Was will daran noch beschleunigen? Selbst das Parsen der XML Dateien kann man da fast beliebig auf Cores verteilen.

[Gast]

Wer diese Applikationen nicht im Durchschnittsfall fast komplett parallelisiert bekommt, will es einfach nicht.
Rendering Engine? Selbst in 2D Paradebeispiel, das man verteilen kann.
Excel? Operationen auf größeren Datensätzen sind prädestiniert dafür.
Word? Nun ja. Das einzige was daran langsam ist, ist momentan das Rendering. Das lässt sich auch gut parallelisieren. Was will daran noch beschleunigen? Selbst das Parsen der XML Dateien kann man da fast beliebig auf Cores verteilen.

Das kann man so pauschal überhaupt nicht sagen. Wenn du komplizierte Excel Operationen hast, die man zwar in mehrere Teilrechnungen zerlegen kann, aber diese voneinander abhängig sind (z.B. Teilrechnung B benötigt Eregbnis von A usw.), lässt sich da gar nichts parallelisieren. Rechtschreibe/Grammatik Prüfung lässt sich ebenfalls nicht parallelisieren. Das reine Parsen "eines" Xml Dokumentes lässt sich ebenfalls nicht parallelisieren. Das man mehrere Xml Dokumente parallel abarbeiten kann, ist ja klar. Wie du das Rendering vom Browser multithreaden willst, musst du mal erklären, weil du ein HTML Dokument sowieso sequentiell parsen musst.

[ScottManDeath]

die law is fuer'n arsch. es kommt so ziemlich garnicht drauf an wieviel von welcher codeart vorhanden ist, sondern lediglich wieviel last sierieller/paraller code macht und da fangen wir erst an zu parallelisieren, sonst war serielle abarbeitung immer weit schneller und wir haben uns ja darauf eingestellt.


Code im Sinne von ausgefuehrten Instruktionen, nicht im Sinne von geschriebenen Zeilen ;)

[micki]

nun spielst du dein mp3 ab und siehst dass du deine cpu voll auslastet (ist ja nur ein beispiel )
Wenn der Profiler bei dir 99% CPU Auslastung sagt (was ich für MP3 Dekodierung auf heutigen CPUs recht seltsam finde),


Das hat doch damit überhaupt nichts zu tun. Wieviel Last erzeugt wird sagt dir aus wieviel zusätzliche Prozessoren du brauchst, um eben die 10% parallelen Code auf 0 zu drücken. dann brauchst du offensichtlich mehr CPUs.hat nichts mit dem gequoeteten zu tun dass die law sagt dass parallelisierbarer code idealisiert gesehen auf 0 rechenzeit mit ausreichend cores optimierbar ist.



Die SPUs können keine Threads selbst ausführen, nur die PPU. Die Threads auf der PPU müssen dann Aufgaben an die SPU delegieren, sich aber auch um die Synchronisation kümmern. Das ist fundamental anders als eine reine Multicore-Lösung.natuerlich kann auf der spu ein voellig unabhaengiger thread laufen und es gibt ebenfalls synchronisations mechanismen, sowohl fuer die SPUs untereinander als auch fuer die zusammenarbeit mit der ppu.

[micki]

Das ist kein Gerücht, sondern Tatsache. Die PPU kümmert sich darum, die SPUs mit Jobs zu füttern. Die SPUs sind nicht komplett autonom, da sie von der PPU erst gestartet werden müssen.
und die ppu ist nicht autonom weil sie erst beim booten vom bios gefuertert werden (was das bios ebenfalls gleich fuer die spus uebernehmen koennte wenn man es drauf anlegen wuerde). nur ist das keine definition von unabhaengigen rechenwerken, denn dann waere jeder weitere core bis auf den ersten einer cpu ebenfalls nur vom hauptcore abhaengig.

[micki]

Code im Sinne von ausgefuehrten Instruktionen, nicht im Sinne von geschriebenen Zeilen ;)
axo, alle instructionen die von einer vorherigen abhaengen koennen nicht mit ihr gleichzeitig ausgefuehrt werden. hmm... gegen diese weisheit kann wohl niemand was sagen.

[Gast]

natuerlich kann auf der spu ein voellig unabhaengiger thread laufen und es gibt ebenfalls synchronisations mechanismen, sowohl fuer die SPUs untereinander als auch fuer die zusammenarbeit mit der ppu.

Nein! Ein Thread kann da nicht drauf laufen. Die SPUs führen quasi ein Programm aus, mit einem Thread hat das aber nichts zu tun. Genau das ist der Grund warum man nicht einfach eine Multithreaded PC/XBOX 360-Anwendung problemlos für die PS3 übernehmen kann.

[Demirug]

Das kann man so pauschal überhaupt nicht sagen. Wenn du komplizierte Excel Operationen hast, die man zwar in mehrere Teilrechnungen zerlegen kann, aber diese voneinander abhängig sind (z.B. Teilrechnung B benötigt Eregbnis von A usw.), lässt sich da gar nichts parallelisieren. Rechtschreibe/Grammatik Prüfung lässt sich ebenfalls nicht parallelisieren. Das reine Parsen "eines" Xml Dokumentes lässt sich ebenfalls nicht parallelisieren. Das man mehrere Xml Dokumente parallel abarbeiten kann, ist ja klar. Wie du das Rendering vom Browser multithreaden willst, musst du mal erklären, weil du ein HTML Dokument sowieso sequentiell parsen musst.

Da gibt es schon Mittel und Wege. Der Nachteil dieser Verfahren ist aber das sie in Summe mehr Rechenleistung brauchen als wenn man es auf die klassische sequenzielle Art macht. Abhängig von der spezifischen Aufgabe kann ein solches Verfahren zum Beispiel auf einem Dualcore länger brauchen als die sequenzielle Lösung auf einem Singelcore. Auf einem Quadcore aber dann gewinnen. Solange aber entsprechende Prozessoren nicht weit genug verbreitet sind verbrennt sich niemand der klar bei Verstand ist damit die Finger.

Dieses Problem tritt in abgeschwächter Form auch bei Dualcore optimierten Spiele auf. Haben die Entwickler auf einen Singelcore fallback verzichtet zahlt man auch dort für den Mehraufwand.

[Gast]

denn dann waere jeder weitere core bis auf den ersten einer cpu ebenfalls nur vom hauptcore abhaengig.


ist er im weitesten sinne auch, das bios bootest erstmal mit 1 core, erst das OS aktiviert den 2. core.

[micki]

Nein! Ein Thread kann da nicht drauf laufen. Die SPUs führen quasi ein Programm aus, mit einem Thread hat das aber nichts zu tun. nein, die spu fuehrt nur einen thread innerhalb des selben programmes aus.


Genau das ist der Grund warum man nicht einfach eine Multithreaded PC/XBOX 360-Anwendung problemlos für die PS3 übernehmen kann.nein, der grund dafuer ist das die compiler nicht automatisch daten in den lokalen speicher schieben, sondern dass der programmierer das bisher selbst erledigen muss. ist wie dass compiler keinen code generieren dass automatisch speicher auf die und von der festplatte geladen wird, das muss auch jemand programmieren. das ist aber kein kriterium fuer threads.

[micki]

Also genau der Fall, für den Intel eigentlich Prozessoren machen müsste.das ist der grund fuer out of order cpus, sie parellelisieren code im kleinen.wenn du dann benchmarks siehst dass ein p3 700 mit der ppu des cell bei 3.2ghz mithalten kann, kann man das wohl auch als erfolgreich betiteln :)

[HellHorse]

Wer diese Applikationen nicht im Durchschnittsfall fast komplett parallelisiert bekommt, will es einfach nicht.
Sicher.

Rendering Engine? Selbst in 2D Paradebeispiel, das man verteilen kann.
Ja genau, es ist ja nicht so, dass die rendering engine, die layout engine und die JS enginge auf den gleichen Daten (DOM-tree) arbeiten. :rolleyes: Auch dass JavaScript, was bei AJAX Applikationen durchaus ernstzunehmende Last erzeugen kann, keine Threads unterstützt und auch nie unterstützen wird, hilft enorm.

Excel? Operationen auf größeren Datensätzen sind prädestiniert dafür.
Word? Nun ja. Das einzige was daran langsam ist, ist momentan das Rendering. Das lässt sich auch gut parallelisieren. Was will daran noch beschleunigen?
Ja genau, mal ein grosses Word oder Excel Dokument bearbeitet? Nur das rendering ist langsam. Aber sicher doch.
Selbst das Parsen der XML Dateien kann man da fast beliebig auf Cores verteilen.
Ja genau. So ist der Namespace eines Kindelementes ja nicht abhängig vom Namespace des Elternelements. Man muss auch nicht ein vorhergehendes Element fertig geparst haben um das nächste parsen zu können (z.B. um zu wissen, wo es denn anfangen soll). Und es ist ja auch nicht so, dass schlussendlich alles zu einem einizgen DOM tree wird. Eignet sich hervorragend für Parallelisierung. :rolleyes:

Warum nur habe ich bloss immer wieder das Gefühl, dass alle Leute, die sagen wie einfach doch Parallelisierung sei, noch nie parallelen Code geschrieben haben?
das ist der grund fuer out of order cpus, sie parellelisieren code im kleinen.wenn du dann benchmarks siehst dass ein p3 700 mit der ppu des cell bei 3.2ghz mithalten kann, kann man das wohl auch als erfolgreich betiteln :)
Noch, wenn ich so Gesichten wie 80 Core höre, kommen mir aber Zweifel, wie lange das noch der Fall sein wird.