Archiv verlassen und diese Seite im Standarddesign anzeigen : CPU mit Streamprozessoren?
=Floi=
2008-06-28, 18:07:21
Hallo
wieso gibt es keine hauptprozessoren mit streamprozessoren bzw. warum greift man nicht das cell-konzept auf?
Wenn ich da zu den grafikkarten schaue frage ich mich schon warum da intel oder amd hier nicht auch ein paar kleine recheneinheiten verbaut hat um bestimmte berechnungen extrem zu beschleunigen. Durch den taktvorteil der cpus bräuchte man auch nur ca. 24 stremprozessoren@ 3-4 ghz um eine starke grundleistung zu bieten.
Gibt es irgendwelche guten grunde warum das die cpu hersteller nicht gemacht haben und so nun von der grafikkarten seite massive konkurrenz haben?
Sollten die cpu hersteller nicht generell mehr logik verbauen und nicht so viel cache?
wären 6,8 oder gar 12 core nicht besser als der olle cache?
was meinst du mit Streamprozessoren? SIMD-Instruktionen sind Bestandteil jeder modernen Proz.-architektur
LOCHFRASS
2008-06-28, 18:21:05
MMX, SSE, AltiVec und 3DNow! sind dir bekannt?
Spasstiger
2008-06-28, 18:22:06
Mit gängigem Code für CPUs kann man die SIMD-Einheiten wie sie auf Grafikkarten verbaut werden, nicht vernünftig auslasten. Deshalb setzen die CPU-Hersteller lieber auf sehr mächtige Recheneinheiten, die sehr gut ausgelastet werden können und pro Takt mehrere Instruktionen bearbeiten können.
Und AMD z.B. bietet neben den CPUs ja auch GPUs als dedizierte Rechenwerke an (FireStream (http://ati.amd.com/technology/streamcomputing/index.html)). D.h. wer diese Zusatzleistung für Spezialanwendungen braucht, bekommt sie auch. Alle anderen Kunden genießen den Preisvorteil bei den normalen CPUs ohne diese sehr breiten SIMD-Einheiten.
Und wie bereits oben erwähnt, haben CPUs auch SSE-Einheiten (SSE = Streaming SIMD Extension). AMD will beim Bulldozer z.B. SSE5-Einheiten verbauen.
BlackBirdSR
2008-06-28, 18:36:23
Gibt es irgendwelche guten grunde warum das die cpu hersteller nicht gemacht haben und so nun von der grafikkarten seite massive konkurrenz haben?
Weil man x86 Code nicht ohne Weiteres in Vektoren packen kann, und dann 24 oder 96 SIMD-Einheiten damit befüllen. Woher soll die Datenmenge dazu kommen?
Ausnahmen gibt es, und dort sind eben auch GPUs stark.
Wenn ein Grafikchip mal eben schnell einen Bildschirm mit 1680x1050 Pixeln füllt, diese nebenbei noch berechnet und die Geometrie der Szene verändert, gibt es viel zu tun wie du dir vorstellen kannst.
Da laufen hunderte wenn nich tausende Operationen ab.
Wenn ich dir jetzt erzähle, dass eine x86-CPU pro Takt im Durschnitt 1.5 Operationen durchführt, dann wird dir vielleicht klar, warum 2-4 SIMD Einheiten ausreichen, und man keine 96 Mini-ALUs verbaut.
Warum das so ist? x86-Code, oder der meiste Programcode von Programmen ist voll von Abhängigkeiten, Stolperfallen und unbekannten Sprüngen. Während die CPU sich kaputt schwitzt aus diesem Chaos 1.5 Operationen pro Takt zu quetschen, muss die GPU vereinfacht gesagt Datenberge oft nur annehmen, abarbeiten und ausspucken.
Mit gängigem Code für CPUs kann man die SIMD-Einheiten wie sie auf Grafikkarten verbaut werden, nicht vernünftig auslasten. Deshalb setzen die CPU-Hersteller lieber auf sehr mächtige Recheneinheiten, die sehr gut ausgelastet werden können und pro Takt mehrere Instruktionen bearbeiten können.
im gegensatz zu GPUs werden CPUs praktisch nie gut ausgelastet.
Spasstiger
2008-06-28, 18:48:05
im gegensatz zu GPUs werden CPUs praktisch nie gut ausgelastet.
Aber es wird viel Aufwand betrieben, damit überhaupt eine Auslastung möglich ist.
Gib mal einer GPU typischen x86-Code. Die erstickt dran.
Durch den taktvorteil der cpus bräuchte man auch nur ca. 24 stremprozessoren@ 3-4 ghz um eine starke grundleistung zu bieten.
hätte man den wirklich? wohl eher nicht, die entsprechende pipeline würde man wohl kaum mit dem normalen kerntakt betreiben können.
=Floi=
2008-06-29, 00:05:18
ich meinte keinen hundertprozentigen x86er code und eher weniger die normalen aufgaben, sondern eher die sachen die damit gut funktionieren. Wie z.B. video en- und decoding, physikbeschleunigung und zig andere sachen die dafür gut passen. Man hätte ja eine api wie dx oder einen treiber machen können über den dann auf diese recheneinheiten zugegriffen werden kann. Es ging mir ja weniger um ein ersetzen, sondern um ein beschleunigen der cpu.
CPU mit Streamprozessoren on Chip gibt es demnächst (AMD Shrike), die Streamprozessoren nennt man dabei "GPU". ;)
BlackBirdSR
2008-06-29, 00:23:06
ich meinte keinen hundertprozentigen x86er code und eher weniger die normalen aufgaben, sondern eher die sachen die damit gut funktionieren. Wie z.B. video en- und decoding, physikbeschleunigung und zig andere sachen die dafür gut passen. Man hätte ja eine api wie dx oder einen treiber machen können über den dann auf diese recheneinheiten zugegriffen werden kann. Es ging mir ja weniger um ein ersetzen, sondern um ein beschleunigen der cpu.
Der Aufwand, diese Einheiten quasi extern anzusprechen, und auch noch eine eigene API?
Damit wäre jegliche Kompatibilität zwischen AMD und Intel hinfällig. Von Via gar nicht zu reden.Zumal das jeweilige Programm dann auch noch extra dafür angepasst werden müsste...
Du siehst, es wäre ein Aufwand an dem die Idee scheitern würde.Schon schlimm genug, dass man ab und an Aufwand für SIMD betreiben muss.
ich meinte keinen hundertprozentigen x86er code und eher weniger die normalen aufgaben, sondern eher die sachen die damit gut funktionieren. Wie z.B. video en- und decoding, physikbeschleunigung und zig andere sachen die dafür gut passen. Man hätte ja eine api wie dx oder einen treiber machen können über den dann auf diese recheneinheiten zugegriffen werden kann. Es ging mir ja weniger um ein ersetzen, sondern um ein beschleunigen der cpu.
Öhm ... das was Du suchst nennt sich AMD Fusion, Ende 2009 (wenn nichts schief löuft ^^) beim Händler Deines Vertrauens ;-)
Das sind 2 K10 Kerne + ATi GPU, in einem Gehäuse. Grob gesagt könnte man den Aufbau als als x86 Cell Prozessor beschreiben, 2 dicke x86 Kerne plus viele, viele Streamprozessoren von ATi. Preisfrage ist z.Zt. nur, wie die beiden Teile verbunden werden, und ob Dual Channel DDR3 reicht.
Wie auch immer, den GPU Teil nennt AMD gerne APU, A für "Accelerated", und das bedeutet nicht nur Grafikbeschleunigung, sondern Beschleunigung im Allgemeinen.
Direkt per x86 Befehle wird man die APU natürlich nicht ansprechen können, das muss so laufen wie jetzige GPGPU Applikationen (siehe Folding@Home), oder aber mit neuer "Middleware", Open CL scheint da im Moment recht hipp zu sein. Bisschen mehr Info dazu gibts noch im ATi/PhysiX Thread:
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=6620434#post6620434
Intel hat ähnliches im Programm, aber ob deren CPU/GPU Combo auch rechnen kann, oder ob Intel da nur die Grafikausgabe ermöglicht .. keine Ahnung.
Edit:
Trap war schneller. Damit zu keinen Namensverwirrung kommt, Fusion ist die Chip-Familienbezeichnung für alle kommenden CPU/GPU Combos bei AMD, Shrike ist der Codename des ersten Chips der Fusion Familie, der laut Plan Ende 2009 kommen soll.
ciao
Alex
Spasstiger
2008-06-29, 00:35:50
Preisfrage ist z.Zt. nur, wie die beiden Teile verbunden werden
Da kommt doch bei AMD nur Hypertransport in Frage, oder? Das hat sich schließlich auch schon bei den Opterons für die Prozessorinterkommunikation bewährt.
Da kommt doch bei AMD nur Hypertransport in Frage, oder? Das hat sich schließlich auch schon bei den Opterons für die Prozessorinterkommunikation bewährt.
Jo, aber kennst Du nen ATi Chip mit Hypertransportinterface ?
Entweder nimmt AMD nen K10 Kern und flanscht PCIe an die XBar, oder ein ATi Chip bekommt HT verpaßt.
Nachdem man PCIe an nem K10 auch noch anderweitig nuten kann und man mit dem X2 Karten Erfahrung mit dem Zusammenschalten per PCIe hat, favorisiere ich persönlich die PCIe Variante, aber nichts ist raus.
Vielleicht geht AMD auch gleich den Luxusweg und entwirft ein monolithisches DIE, indem sie z.B. den Hub der R7xx und die Xbar des K10s zusammenbasteln, aber das wäre für die erste Generation schon ein gewagter Schritt. Auf der andern Seite haben sie noch 1,5 Jahre Zeit ... Mehr als Abwarten und im Nebel Stochern kann man im Moment leider nicht.
Erst gestern gabs wieder Infos über Shrike im Netz, aber Neues gabs da auch nicht:
http://www.planet3dnow.de/photoplog/file.php?n=2567&w=o
Möglich auch, dass das schlicht und ergreifend ein dual Core X2 plus integriertem Chipsatz wird. Ein 780G ist ja prinzipiell ne ATi Grafikkarte mit Hypertransportanschluss, und PCIe für die SB ist bekanntermaßen auch an board. Für den Fall wunder ich mich aber, wieso das so lange dauert ...
ciao
Alex
Headman
2008-06-29, 01:00:09
Jo, aber kennst Du nen ATi Chip mit Hypertransportinterface ?
Gibt sogar ne ganze Menge: rs690, rs740, rs780 etc.
Die aktuellen AMD Northbridges sind nichts anderes als per HT angebundene Grafikchips mit zusätzlichem PciE Controller.
Deshalb wäre es wohl die einfachste Lösung demnächst einfach so einen Chip mit aufs Package zu pflanzen.
Bokill
2008-06-29, 13:11:43
Gibt sogar ne ganze Menge: rs690, rs740, rs780 etc.
Die aktuellen AMD Northbridges sind nichts anderes als per HT angebundene Grafikchips mit zusätzlichem PciE Controller.
Deshalb wäre es wohl die einfachste Lösung demnächst einfach so einen Chip mit aufs Package zu pflanzen. Wobei aber Chipintern in der integrierten Northbridge die Anbindung des GPU-Teils per PCI-Express macht.
In der Hinsicht wäre ULi besser gewesen, die haben unterschiedliche Northbridges* sowohl mit HyperTransport* und PCI-Express im Köcher gehabt.
Zum Thema:
"So etwas wie der Cell".
Wenn man tatsächlich das Konzept vom 1:1 Cell übernähme, dann musste die Programmierung noch komplexer werden. Aber nicht nur wegen des Vektorprozessorchrakters (das kennt x86 seit MMX, 3DNow!, SSE, wie du selber ja weisst =Floi= ;)).
Die SPEs vom Cell haben lokalen RAM integriert. Dieser muss gezielt bei der Programmierung ebenso berücksichtigt werden. "Vergisst" dies ein Programmierer, dann verliert der Cell deutlich an Geschwindigkeit.
Allerdings geht bei x86 der Trend zu noch mehr Vektorisierung hin. Spätestens mit dem Larrabee ist dann etwas auf dem Markt, was vom Konzept vergleichbar erscheint gegenüber dem Cell.
AMD wählt da eher einen hybriden Ansatz mit x86-Prozessorkernen + non-x86-GPU-Einheiten.
Der Cell verfügt zur Zeit aber einen internen Ringbus, was beim Larrabee vermutlich in Richtung Mash (http://www.orthy.de/index.php?option=com_content&task=view&id=4895&Itemid=86) geht. Mit Dem Projekt Polaris (http://www.orthy.de/index.php?option=com_content&task=view&id=4532&Itemid=86) hat ja Intel ein Mash-Konzept gezeigt.
MFG Bobo(2008 )
* = Tatsächlich gab es zu den unterschiedlichen Interfaces dann auch jeweils Southbridges mit PCI-Express und HyperTransport.
ULi hatte aber keine integrierten Chipsätze wie ATI, SiS und Nvidia.
Die SPEs vom Cell haben lokalen RAM integriert. Dieser muss gezielt bei der Programmierung ebenso berücksichtigt werden. "Vergisst" dies ein Programmierer, dann verliert der Cell deutlich an Geschwindigkeit.Jo, und interessant dabei ist, dass nVidia das auch schon hat, und AMD das gerade eben per RV700 nachgerüstet hat:
Another such accommodation is the addition of 16KB of local shared memory in each SIMD core, useful for sharing data between threads in GPU-compute applications. This is obviously rather similar to the 16KB of shared memory Nvidia has built into each of the SM structures in its recent GPUs, although the RV770 has relatively less memory per stream processor, about a tenth of what the GT200 has. This local data share isn't accessible to programmers via graphics APIs like DirectX, but AMD may use it to enable larger kernels for custom AA filters or for other forms of post-processing. Uniquely, the RV770 also has a small, 16K global data share for the passing of data between SIMDs. http://www.techreport.com/articles.x/14990/4
Mal schauen wie das weitergeht, Polaris ist natürlich schon ein Koloss an Speicherbandbreite, aber wer weiß was nV/ATi bis dahin ausgekocht habe :)
ciao
Alex
denke schon dass CPUs GPU-ähnlicher werden, als nur ein GPU Kern im CPU integriert, jetzt ist Quadcore standard, 09 vermutlich 8 core, dann 16, 24... und wenn man mal den 16. core auf einer CPU verbaut, interessiert es dann noch ob dieser sachen wie out of order execution unterstützt oder über große Caches und viele Register verfügt wenn er für normale x86 Programmabläufe (auch wenn es einen Paradigmawechsel im Programmieren hin zur parallelität gibt) meist sowieso brach liegen würde und ausschließlich von sehr parallelisierbaren Programmen, wie Grafik, Video, Physik verwendet werden würde. Wieso sollte man diesen dann nicht GPU-like sehr einfach halten und für diese Aufgaben optimieren. Solange Moores Law bestehen bleibt, wird es denke ich zwangsweise auf sowas rauslaufen, vermutlich sogar mit Ausgang im Mobilen Markt wo Grafikkarten keinen so starken Gegenpart zur CPU einnehmen wie bei Desktops. (außerdem ist eine derartige Bauweise ja viel energieeffizienter)
TheRealTentacle
2008-06-30, 18:05:34
Das geht ja alles in einer sehr interessante und richtige Richtung. Es ist einfach unnötig, das der PC heutzutage für alles einen extra Chips haben muss. Hoffentlich kommt da auch mal ein vernünftiges SoC heraus, das würde sehr kleine, leistungfähige PCs ermöglichen.
ihr vergesst auch eines, streamprozessoren brauchen erstmals unmengen an bandbreite, ich wüsste nicht wie man diese bei einer cpu bereitstellen sollte.
ihr vergesst auch eines, streamprozessoren brauchen erstmals unmengen an bandbreite, ich wüsste nicht wie man diese bei einer cpu bereitstellen sollte.Naja, 3 x 64 Speicherkanäle beim Nehalem mit DDR3-1600. Das ist ja schon einmal was für den Anfang.
=Floi=
2008-06-30, 22:27:28
ich sehe nicht das problem in der programmierbarkeit. Wenn es eine beschleunigung um den faktor 10 gibt, dann kann man hierfür auch entsprechend optimieren und sobald hier produktive software eingesetzt wird, dann spielt der softwarepreis so gut wie keine rolle mehr.
Spasstiger
2008-06-30, 22:42:54
ich sehe nicht das problem in der programmierbarkeit. Wenn es eine beschleunigung um den faktor 10 gibt, dann kann man hierfür auch entsprechend optimieren und sobald hier produktive software eingesetzt wird, dann spielt der softwarepreis so gut wie keine rolle mehr.
Und wie willst du etwas auf SIMD-Verarbeitung optimieren, wenn gar nicht soviele Daten reinkommen bzw. ständig Abhängigkeiten und Sprünge auftreten?
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.