App installieren
How to install the app on iOS
Follow along with the video below to see how to install our site as a web app on your home screen.
Anmerkung: This feature may not be available in some browsers.
Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden.
Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Kerndiskussion - breit oder schmal, wenige oder viele?
- Ersteller Ge0rgy
- Erstellt am
Ge0rgy
Grand Admiral Special
- Mitglied seit
- 14.07.2006
- Beiträge
- 4.322
- Renomée
- 82
- Mein Laptop
- Lenovo Thinkpad X60s
- Prozessor
- Phenom II 955 BE
- Mainboard
- DFI LanParty DK 790FXB-M3H5
- Kühlung
- Noctua NH-U12P
- Speicher
- 4GB OCZ Platinum DDR1600 7-7-7 @ 1333 6-6-6
- Grafikprozessor
- Radeon 4850 1GB
- HDD
- Western Digital Caviar Black 1TB
- Netzteil
- Enermax Modu 525W
- Betriebssystem
- Linux, Vista x64
- Webbrowser
- Firefox 3.5
Hier ein Podium für die Diskuttanten die sich gerne über Skalierungseffekte, Multicore und den immerwährenden Disput zwischen wenigen "fetten" - Kernen kontra vielen, schlankeren auslassen.
Viel spaß
Viel spaß
mocad_tom
Admiral Special
- Mitglied seit
- 17.06.2004
- Beiträge
- 1.234
- Renomée
- 52
Wir unterhalten uns schon über eine "General Purpose CPU"?ddb schrieb:Kommt auf den Applikationsmix an. Wenn er sehr spezifisch ist, gibt es Anwendungsfelder.
Ich gehe davon aus, dass Bulldozer eine "General Purpose CPU" ist.
Vielleicht sind sie ja wirklich mit dem Schlachtplan in die Schlacht gezogen:
Zuerst Bulldozer:
Ein etwas schmalerer Kern (der auch leichter zu Validieren ist) da man überall genug Baustellen hat
Danach Piledriver:
An Punkten, die man fetter gestalten kann wird ausstaffiert, um die "Durchschitts-IPC" anzuheben.
Trinity hat ja auch nur zwei Piledriver-Module.
Während man von Istanbul zu Orochi geht, geht man von 6 Kerne auf 8 Int-Kerne.
Von Llano auf Trinity geht man aber von 4 Kerne auf 4 Int-Kerne.
Wann wird jetzt da endlich etwas gelauncht?
Vielleicht stimmt ja auch was Crashtest geschrieben hat:
Crashtest schrieb:Immerhin benötigt AMD reichlich gute Chips für Server - Desktop ist da nur Randgebiet immerhin soll da Bulldozer erst richtig als Fusion nächstes Jahr durchstarten ...
Kannst du mal dieses Paper suchen- oder vllt ist es ja noch wo auf deiner Platte?
Ich glaube mich erinnern zu können - wurde es nicht auch mal hier gepostet (vor Jahren) - ich weiß aber partout nicht mehr wo.ddb schrieb:Hier fehlt jetzt das Paper mit den Power/Performance-Kurven bei 2way-InO, 2way-OoO, 4way-OoO etc. Mit denen konnte ich kürzlich ein paar Kollegen recht leicht nachvollziehbar die wesentlichen Unterschiede zwischen einigen CPUs inkl. ARM verdeutlichen.
Zuletzt bearbeitet:
Ge0rgy
Grand Admiral Special
- Mitglied seit
- 14.07.2006
- Beiträge
- 4.322
- Renomée
- 82
- Mein Laptop
- Lenovo Thinkpad X60s
- Prozessor
- Phenom II 955 BE
- Mainboard
- DFI LanParty DK 790FXB-M3H5
- Kühlung
- Noctua NH-U12P
- Speicher
- 4GB OCZ Platinum DDR1600 7-7-7 @ 1333 6-6-6
- Grafikprozessor
- Radeon 4850 1GB
- HDD
- Western Digital Caviar Black 1TB
- Netzteil
- Enermax Modu 525W
- Betriebssystem
- Linux, Vista x64
- Webbrowser
- Firefox 3.5
Heben wir doch mal die Unterschiede hervor:
Dicker Kern:
Pro:
- potenziell hohe durchschnittliche IPC
- SMT-Fähig
- nur wenig Takt nötig für hohe Leistung
Contra:
- Komplex, daher Bug-Anfällig, schwieriger zu validieren, groß.
- Stromsparen ist schwieriger
- schwerer auszulasten, daher nicht immer max. Effizienz bei der Arbeit
- nur moderat taktbar
Schlanker Kern:
Pro:
- hohe Takte möglich
- einfacher zu validieren / testen
- einfacheres Design spart Transistoren
- Stromsparen ist leichter, selbst wenn man es nur auf Ebene ganzer Kerne implementiert.
- mittlere auslastung besser als bei großen Kernen.
Contra:
- schlechte IPC, daher hohe Takte nötig
- höhere Spannungen erforderlich, zu Lasten des Stromverbrauchs
- in vielen Fällen langsamer weil Software nicht sauber skaliert.
Hab ich was vergessen?
Dicker Kern:
Pro:
- potenziell hohe durchschnittliche IPC
- SMT-Fähig
- nur wenig Takt nötig für hohe Leistung
Contra:
- Komplex, daher Bug-Anfällig, schwieriger zu validieren, groß.
- Stromsparen ist schwieriger
- schwerer auszulasten, daher nicht immer max. Effizienz bei der Arbeit
- nur moderat taktbar
Schlanker Kern:
Pro:
- hohe Takte möglich
- einfacher zu validieren / testen
- einfacheres Design spart Transistoren
- Stromsparen ist leichter, selbst wenn man es nur auf Ebene ganzer Kerne implementiert.
- mittlere auslastung besser als bei großen Kernen.
Contra:
- schlechte IPC, daher hohe Takte nötig
- höhere Spannungen erforderlich, zu Lasten des Stromverbrauchs
- in vielen Fällen langsamer weil Software nicht sauber skaliert.
Hab ich was vergessen?
PuckPoltergeist
Grand Admiral Special
Schlanker Kern heisst nicht automatisch geringere IPC und umgekehrt. Das finde ich jetzt etwas sehr verallgemeinert.
Bobo_Oberon
Grand Admiral Special
- Mitglied seit
- 18.01.2007
- Beiträge
- 5.045
- Renomée
- 190
Du meinst, da spielt mindestens ebenso stark die ISA und Betriebssystem (-> dahinter stehendes Ökosystem) eine Rolle?!Schlanker Kern heisst nicht automatisch geringere IPC und umgekehrt. Das finde ich jetzt etwas sehr verallgemeinert.
MFG Bobo(2011).
mocad_tom
Admiral Special
- Mitglied seit
- 17.06.2004
- Beiträge
- 1.234
- Renomée
- 52
Dem kann ich nur zustimmen.Schlanker Kern heisst nicht automatisch geringere IPC und umgekehrt. Das finde ich jetzt etwas sehr verallgemeinert.
Itanium kann eine hohe IPC haben ist aber vom Kern-Transistorbudget her kleiner als die aktuellen x86-Budgets.
Ich finde auch diese Simulationen etwas verallgemeinernd.
Man schafft es ja in einen bestehenden Kern hinein immer wieder etwas neues reinzubauen. Issue-Wide-Mässig, anzahl Pipeline-Stufen, FO4 ändert sich nicht, trotzdem steigt die IPC - wie durch Zauberhand
Ge0rgy
Grand Admiral Special
- Mitglied seit
- 14.07.2006
- Beiträge
- 4.322
- Renomée
- 82
- Mein Laptop
- Lenovo Thinkpad X60s
- Prozessor
- Phenom II 955 BE
- Mainboard
- DFI LanParty DK 790FXB-M3H5
- Kühlung
- Noctua NH-U12P
- Speicher
- 4GB OCZ Platinum DDR1600 7-7-7 @ 1333 6-6-6
- Grafikprozessor
- Radeon 4850 1GB
- HDD
- Western Digital Caviar Black 1TB
- Netzteil
- Enermax Modu 525W
- Betriebssystem
- Linux, Vista x64
- Webbrowser
- Firefox 3.5
Öhm... natürlich ist das verallgemeinert, das soll ja auch eine art stichwortliste sein zur weiteren Erörterung.
Abgesehen davon, dass 2-issue nun mal in der theorie einen befehl weniger pro takt bearbeiten kann als 3-issue. Also ist die maximale IPC eben schon geringer.
Ebenso haben die fetten kerne die Transistoren ja nicht aus Jux und Dollerei. - Die haben einen Sinn, meistens eben die Verbesserung der Auslastung zur erhöhung der mittleren IPC.
So alla Branch Prediction, Prefetching, OP-Fusion usw. usf.
Also mit fettem Kern ist nicht nur gemeint dass man 10-fach OoO arbeitet sondern auch das Ganze drum und dran.
Die paradebeispiele beider Lager sind doch eigentlich CPUs und GPUs. Erstere haben relativ wenig Rechnekerne, die aber wesentlich mehr logik enthalten. letztere Vertreter der Brute-Force-Methode alla Ameisenschwarm...
Die genaueren Spezifika des einen oder anderen Ansatzes (egal ob CPU oder GPU) sind genau der Gegenstand dieses Threads. CELL Beispielsweise ist eher ein Hybride der Elemente von beiden Ansätzen enthält.
Abgesehen davon, dass 2-issue nun mal in der theorie einen befehl weniger pro takt bearbeiten kann als 3-issue. Also ist die maximale IPC eben schon geringer.
Ebenso haben die fetten kerne die Transistoren ja nicht aus Jux und Dollerei. - Die haben einen Sinn, meistens eben die Verbesserung der Auslastung zur erhöhung der mittleren IPC.
So alla Branch Prediction, Prefetching, OP-Fusion usw. usf.
Also mit fettem Kern ist nicht nur gemeint dass man 10-fach OoO arbeitet sondern auch das Ganze drum und dran.
Die paradebeispiele beider Lager sind doch eigentlich CPUs und GPUs. Erstere haben relativ wenig Rechnekerne, die aber wesentlich mehr logik enthalten. letztere Vertreter der Brute-Force-Methode alla Ameisenschwarm...
Die genaueren Spezifika des einen oder anderen Ansatzes (egal ob CPU oder GPU) sind genau der Gegenstand dieses Threads. CELL Beispielsweise ist eher ein Hybride der Elemente von beiden Ansätzen enthält.
PuckPoltergeist
Grand Admiral Special
Auch wenn das stimmt, meinte ich das nicht mal hier. Vergleicht doch nur mal den Pentium4 mit dem Core. Letzterer ist schlanker im Design und hat trotzdem die höhere IPC.Du meinst, da spielt mindestens ebenso stark die ISA und Betriebssystem (-> dahinter stehendes Ökosystem) eine Rolle?!
MFG Bobo(2011).
Dein Contra dazu timmt nicht ganz, Stromsparen & CPU Takt ist bei Intel kein Problem.Dicker Kern:
Pro:
- potenziell hohe durchschnittliche IPC
- SMT-Fähig
- nur wenig Takt nötig für hohe Leistung
Contra:
- Komplex, daher Bug-Anfällig, schwieriger zu validieren, groß.
- Stromsparen ist schwieriger
- schwerer auszulasten, daher nicht immer max. Effizienz bei der Arbeit
- nur moderat taktbar
Hab ich was vergessen?
Und die aktuellen Xeon für Sockel 1155 haben ohne IGP 3,6Ghz Basistakt bei 95W TDP mit durchscnittlich 40% höhere IPC als K10.
Seit dem Core2 hat Intel eine Super Architektur die auf hohe IPC & moderate Taktraten ausgelegt ist, mit Architektur Updates Stichwort: "Tock" steigert Intel weiterhin die IPC und der Takt wird nicht geringer!
Dresdenboy
Redaktion
☆☆☆☆☆☆
Ich kenne derzeit niemanden, der nicht davon ausgeht, außer vielleicht Bauarbeiter und alle anderen, die nicht so in der Materie stecken.Wir unterhalten uns schon über eine "General Purpose CPU"?
Ich gehe davon aus, dass Bulldozer eine "General Purpose CPU" ist.
Da aber "General Purpose" nicht "konstante Leistung" bedeutet sondern sich eher auf die ISA bezieht, ist die Variabilität bei heutigen Architekturen auch kein Widerspruch. Siehe dazu auch das Bild mit den Clustern, welches wir schon verwendet hatten.
So ähnlich stelle ich mir das auch vor. Aber eher danach gestaffelt, welche Merkmale von der Komplexität am ehesten umsetzbar sind, so dass komplexere Elemente in nachfolgende Ausprägungen integriert werden. Das passt ganz gut zu Chuck Moores Ansatz, solche Features nicht nur nach Performanzgewinn zu gewichten, sondern auch nach Aufwand, Zeit, Energiebedarf usw.Vielleicht sind sie ja wirklich mit dem Schlachtplan in die Schlacht gezogen:
Zuerst Bulldozer:
Ein etwas schmalerer Kern (der auch leichter zu Validieren ist) da man überall genug Baustellen hat
Danach Piledriver:
An Punkten, die man fetter gestalten kann wird ausstaffiert, um die "Durchschitts-IPC" anzuheben.
Da gibt es nicht mehr viel Spekulationsspielraum nach unten bezgl. der LeistungTrinity hat ja auch nur zwei Piledriver-Module.
Während man von Istanbul zu Orochi geht, geht man von 6 Kerne auf 8 Int-Kerne.
Von Llano auf Trinity geht man aber von 4 Kerne auf 4 Int-Kerne.
"Energy-Performance Tradeoffs in Processor Architecture and Circuit Design: A Marginal Cost Analysis" von Omid Azizi, Aqeel Mahesri, Benjamin C. Lee, Sanjay J. Patel, Mark HorowitzKannst du mal dieses Paper suchen- oder vllt ist es ja noch wo auf deiner Platte?
Link: http://www.duke.edu/~BCL15/documents/azizi2010-isca-opt.pdf
Ge0rgy
Grand Admiral Special
- Mitglied seit
- 14.07.2006
- Beiträge
- 4.322
- Renomée
- 82
- Mein Laptop
- Lenovo Thinkpad X60s
- Prozessor
- Phenom II 955 BE
- Mainboard
- DFI LanParty DK 790FXB-M3H5
- Kühlung
- Noctua NH-U12P
- Speicher
- 4GB OCZ Platinum DDR1600 7-7-7 @ 1333 6-6-6
- Grafikprozessor
- Radeon 4850 1GB
- HDD
- Western Digital Caviar Black 1TB
- Netzteil
- Enermax Modu 525W
- Betriebssystem
- Linux, Vista x64
- Webbrowser
- Firefox 3.5
Dein Contra dazu timmt nicht ganz, Stromsparen & CPU Takt ist bei Intel kein Problem.
Und die aktuellen Xeon für Sockel 1155 haben ohne IGP 3,6Ghz Basistakt bei 95W TDP mit durchscnittlich 40% höhere IPC als K10.
Seit dem Core2 hat Intel eine Super Architektur die auf hohe IPC & moderate Taktraten ausgelegt ist, mit Architektur Updates Stichwort: "Tock" steigert Intel weiterhin die IPC und der Takt wird nicht geringer!
Wir müssen aufpassen dass wir hier nich die Fertigung mit hineinmischen.
Die Core-Mikroarchitektur ist ohne Zweifel gut... aber nur weil wir nichts besseres als Vergleichsbassi haben, ist sie noch lange nicht der Weisheit letzter Schluss.
Warum erscheinen dir 3,6Ghz viel?
Weil die Konkurrenz auch nicht mehr gebracht hat? - Das sagt nichts über die theoretische Möglichkeit aus, dass ein schlankerer Prozessor alla Bobcat nicht die 5Ghz hätte knacken können in Intels 32nm-Prozess.
Meine Pros und Contras sind nicht auf die derzeitige Marktsituation ausgerichtet sondern auf das was möglich wäre.
Das Stromsparen ist ein anderer Punkt... wenn du einen Bobcat-10-kerner hättest, der alle Kerne bis auf 1 im IDLE abschalten kann... meinst du nicht der wäre noch sparsamer als Sandy Bridge?
Also nur weil man mit viel Tricks & technischem Aufwand (der wiederum transistoren kostet) die "fetten" Kerne auf Diät gesetzt hat wenn es nichts zu arbeiten gibt, bedeutet das nicht kategorisch einen Vorteil des Architekturansatzes.
Mente
Grand Admiral Special
- Mitglied seit
- 23.05.2009
- Beiträge
- 3.671
- Renomée
- 135
- Aktuelle Projekte
- constalation astroids yoyo
- Lieblingsprojekt
- yoyo doking
- Meine Systeme
- Ryzen 3950x
- BOINC-Statistiken
- Prozessor
- AMD 5800X3D
- Mainboard
- Asus ROG Crosshair VIII Dark Hero
- Kühlung
- Headkiller IV
- Speicher
- 3800CL14 G.Skill Trident Z silber/rot DIMM Kit 32GB, DDR4-3600, CL15-15-15-35 (F4-3600C15D-16GTZ)
- Grafikprozessor
- AMD Radeon RX 6900 XT Ref. @Alphacool
- Display
- MSI Optix MAG27CQ
- SSD
- SN8502TB,MX5001TB,Vector150 480gb,Vector 180 256gb,Sandisk extreme 240gb,RD400 512gb
- HDD
- n/a
- Optisches Laufwerk
- n/a
- Soundkarte
- Soundblaster X4
- Gehäuse
- Phanteks Enthoo Pro 2 Tempered Glass
- Netzteil
- Seasonic Prime GX-850 850W
- Tastatur
- Logitech G19
- Maus
- Logitech G703
- Betriebssystem
- Win 10 pro
- Webbrowser
- IE 11 Mozilla Opera
- Verschiedenes
- Logitech PRO RENNLENKRAD DD
Hi Ge0rgy
aber wenn wir nach dem Was wissenschaftlich möglich ist, müssten wir auf Silitzium langsam verzichten.
Die Frage ist er was könnte man Kostendeckend Produzieren. Viele gehen ja davon aus das es nicht mal lange mit Silizium weiter gehen kann.
lg
aber wenn wir nach dem Was wissenschaftlich möglich ist, müssten wir auf Silitzium langsam verzichten.
Die Frage ist er was könnte man Kostendeckend Produzieren. Viele gehen ja davon aus das es nicht mal lange mit Silizium weiter gehen kann.
lg
mocad_tom
Admiral Special
- Mitglied seit
- 17.06.2004
- Beiträge
- 1.234
- Renomée
- 52
@ddb
http://www.duke.edu/~BCL15/documents/azizi2010-isca-opt.pdf
Wenn man sich Abbildung 8 auf Seite 9 anschaut.
Dort ist die Voltage variabel (also genau das was wir derzeit als gegeben voraussetzen).
Der 4-Issue-OoO und der 2-Issue-OoO scheinen hier wirklich die zwei härtesten Kontrahenten zu sein.
Der Schnittpunkt liegt bei 2000MIPS.
Was ist, wenn man dem Intel-Design-Team sagt, baut eine 4-Issue-Wide-OoO, die aber nur so viel Verbrauchen darf wie eine 2-Issue-Wide-OoO.
Die Sachen sind halt leider nach wie vor sehr theoretisch abgearbeitet. Man sieht nicht, welchen Effekt ein Handverdrahtetes Design hätte gegenüber einem syntetisierten (aus Foundry-Bibliotheken). Was ist, wenn Intel besonders kleine, schnelle und stromsparende Cachezellen bauen kann.
Was ist, wenn Intel sich deshalb auf ein Design stützt, das besonders gut mit großem L3-Cache und vollem Kern-Takt zurechtkommt.
Ich sehe die Cache-Pipeline als genau so wichtig, wie die Prozessor-Pipeline. Beim Core 2 Duo wurde hier vieles sehr sehr gut gemacht. Sie hatten eine extrem kurze Cache Latency beim Zugriff auf den 6MB großen L2-Cache.
Ich freue mich auf den start des BD, ich glaube aber, dass er den Namen wahrscheinlich nicht verdient hat.
http://www.duke.edu/~BCL15/documents/azizi2010-isca-opt.pdf
Wenn man sich Abbildung 8 auf Seite 9 anschaut.
Dort ist die Voltage variabel (also genau das was wir derzeit als gegeben voraussetzen).
Der 4-Issue-OoO und der 2-Issue-OoO scheinen hier wirklich die zwei härtesten Kontrahenten zu sein.
Der Schnittpunkt liegt bei 2000MIPS.
Was ist, wenn man dem Intel-Design-Team sagt, baut eine 4-Issue-Wide-OoO, die aber nur so viel Verbrauchen darf wie eine 2-Issue-Wide-OoO.
Die Sachen sind halt leider nach wie vor sehr theoretisch abgearbeitet. Man sieht nicht, welchen Effekt ein Handverdrahtetes Design hätte gegenüber einem syntetisierten (aus Foundry-Bibliotheken). Was ist, wenn Intel besonders kleine, schnelle und stromsparende Cachezellen bauen kann.
Was ist, wenn Intel sich deshalb auf ein Design stützt, das besonders gut mit großem L3-Cache und vollem Kern-Takt zurechtkommt.
Ich sehe die Cache-Pipeline als genau so wichtig, wie die Prozessor-Pipeline. Beim Core 2 Duo wurde hier vieles sehr sehr gut gemacht. Sie hatten eine extrem kurze Cache Latency beim Zugriff auf den 6MB großen L2-Cache.
Ich freue mich auf den start des BD, ich glaube aber, dass er den Namen wahrscheinlich nicht verdient hat.
mocad_tom
Admiral Special
- Mitglied seit
- 17.06.2004
- Beiträge
- 1.234
- Renomée
- 52
Wollte hier noch was anderes einwerfen.
Im "Energy-Performance-Tradeoff"-paper auf Seite 9 liegen die CPUs nicht so weit auseinander.
Jetzt mal kurz etwas, das vllt. den ein oder anderen aus den Socken heben könnte:
http://www.hotchips.org/archives/hc...1.23.270.Pulli-OpenCL-in-Handheld-Devices.pdf
In diesem Paper wird gezeigt, wie viel ein Bild-Bearbeitungs-Algorithmus auf einer ARM-CPU verbraucht und wie viel auf einer GPU mit OpenCL.
Auf Seite 18 wird mit der Angabe Joule per Frame rumhantiert.
Dabei zeigt sich, dass die Bildbearbeitung nicht nur schneller auf der GPU läuft, sondern auch nur ca. 15% der Energie braucht.
3,93 Joule pro Frame für die Berechnung auf der CPU
0,56 Joule pro Frame für die Berechnung auf der GPU
Es lässt sich daraus folgern:
für spezielle Anwendungen eignet sich die GPU um den Energieverbrauch minimieren zu können.
Im "Energy-Performance-Tradeoff"-paper auf Seite 9 liegen die CPUs nicht so weit auseinander.
Jetzt mal kurz etwas, das vllt. den ein oder anderen aus den Socken heben könnte:
http://www.hotchips.org/archives/hc...1.23.270.Pulli-OpenCL-in-Handheld-Devices.pdf
In diesem Paper wird gezeigt, wie viel ein Bild-Bearbeitungs-Algorithmus auf einer ARM-CPU verbraucht und wie viel auf einer GPU mit OpenCL.
Auf Seite 18 wird mit der Angabe Joule per Frame rumhantiert.
Dabei zeigt sich, dass die Bildbearbeitung nicht nur schneller auf der GPU läuft, sondern auch nur ca. 15% der Energie braucht.
3,93 Joule pro Frame für die Berechnung auf der CPU
0,56 Joule pro Frame für die Berechnung auf der GPU
Es lässt sich daraus folgern:
für spezielle Anwendungen eignet sich die GPU um den Energieverbrauch minimieren zu können.
Zuletzt bearbeitet:
Ge0rgy
Grand Admiral Special
- Mitglied seit
- 14.07.2006
- Beiträge
- 4.322
- Renomée
- 82
- Mein Laptop
- Lenovo Thinkpad X60s
- Prozessor
- Phenom II 955 BE
- Mainboard
- DFI LanParty DK 790FXB-M3H5
- Kühlung
- Noctua NH-U12P
- Speicher
- 4GB OCZ Platinum DDR1600 7-7-7 @ 1333 6-6-6
- Grafikprozessor
- Radeon 4850 1GB
- HDD
- Western Digital Caviar Black 1TB
- Netzteil
- Enermax Modu 525W
- Betriebssystem
- Linux, Vista x64
- Webbrowser
- Firefox 3.5
Lang lebe Fusion
memory_stick
Lieutnant
Im Paper wird ausserdem noch erwähnt, dass das kombinierte berrchnen eines Frames mehr verbraucht als nur auf der GPU, jedoch immer noch deutlich weniger als auf der CPU allein.
Folgerung: Da mit OpenCL dynamisch CPU und/oder GPU verwendet werden können, wird es in Heterogenen Anwendungen sehr wichtig sien, die richitgen Aufgaben auf die richtige Hardware zu verteilen,um ein optimales Performance/Watt Verhältnis zu erreichen.
btw: Georgy
es heisst "The Future is Fusion"
mfg memory_stick
Folgerung: Da mit OpenCL dynamisch CPU und/oder GPU verwendet werden können, wird es in Heterogenen Anwendungen sehr wichtig sien, die richitgen Aufgaben auf die richtige Hardware zu verteilen,um ein optimales Performance/Watt Verhältnis zu erreichen.
btw: Georgy
es heisst "The Future is Fusion"
mfg memory_stick
Dresdenboy
Redaktion
☆☆☆☆☆☆
Was auch spannend bzgl. der Tradeoffs ist (und nicht so oft dahingehend untersucht wurde): Welche Tradeoffs/Kurven passen nun gut zu den geplanten Einsatzfeldern (teilweise auch dadurch verschieden, weil das gleiche Die oder der Kern für Server/DT oder gar Mobile genutzt wird)?Wollte hier noch was anderes einwerfen.
Im "Energy-Performance-Tradeoff"-paper auf Seite 9 liegen die CPUs nicht so weit auseinander.
Z. B. wäre für single threaded performance die Architektur am besten, deren Energie/Befehl-gegen-Performanz-Kurve sich am weitesten in den unteren rechten Sektor bewegt. Für angepeilte Multithreaded-Anwendungen können die Arch. geeigneter sein, welche eher im Mittelfeld bis leicht unten rechts liegen, da mehr Kerne dank TDP mit weniger Verbrauch auskommen müssen u. damit in den etwas niedriger performenden Bereich rutschen müssen. Für "unten rechts" reicht das Energiebudget einfach nicht mehr (ansteigender Part).
Wie jetzt... ? Fusion würde etwas bringen?Jetzt mal kurz etwas, das vllt. den ein oder anderen aus den Socken heben könnte:
http://www.hotchips.org/archives/hc...1.23.270.Pulli-OpenCL-in-Handheld-Devices.pdf
In diesem Paper wird gezeigt, wie viel ein Bild-Bearbeitungs-Algorithmus auf einer ARM-CPU verbraucht und wie viel auf einer GPU mit OpenCL.
Auf Seite 18 wird mit der Angabe Joule per Frame rumhantiert.
Dabei zeigt sich, dass die Bildbearbeitung nicht nur schneller auf der GPU läuft, sondern auch nur ca. 15% der Energie braucht.
3,93 Joule pro Frame für die Berechnung auf der CPU
0,56 Joule pro Frame für die Berechnung auf der GPU
Es lässt sich daraus folgern:
für spezielle Anwendungen eignet sich die GPU um den Energieverbrauch minimieren zu können.
Tja, bei sehr hoher Datenlokalität und oft regelmäßigen Operationen passt das gut zu den vielen kleinen GPU-Shaderkernen mit vielen lokalen Registern u. Caches.
Es gab auf RWT u. woanders ja auch schon die Diskussion, dass ALU's ja eigentlich billig sind und nur das Hin- und Herschieben der Daten und Befehle in großen General-Purpose-CPU-Kernen dagegen sehr viel Energie braucht.
Ge0rgy
Grand Admiral Special
- Mitglied seit
- 14.07.2006
- Beiträge
- 4.322
- Renomée
- 82
- Mein Laptop
- Lenovo Thinkpad X60s
- Prozessor
- Phenom II 955 BE
- Mainboard
- DFI LanParty DK 790FXB-M3H5
- Kühlung
- Noctua NH-U12P
- Speicher
- 4GB OCZ Platinum DDR1600 7-7-7 @ 1333 6-6-6
- Grafikprozessor
- Radeon 4850 1GB
- HDD
- Western Digital Caviar Black 1TB
- Netzteil
- Enermax Modu 525W
- Betriebssystem
- Linux, Vista x64
- Webbrowser
- Firefox 3.5
Erstmal muss es Leben
Im Moment ist es aus meiner Sicht nicht mehr als GPU und CPU auf einem DIE.
Software ist auch nicht gerade eine Stärke von AMD,trotzdem noch die beste Strategie ihr Know-how zu nutzen.
Du sagst das als wäre es was negatives?
Ja, es ist CPU und GPU auf einem DIE... und auch wenn die CPU teilweise nicht mehr ganz auf der Höhe der technischen Möglichkeitne rangiert, ist sie dennoch noch lange nicht untauglich und die GPU ist Top. Allen Unkenrufen zum Trotz freue ich mich auf mein Llano-Notebook, so es denn bald geliefert wird.
Die GPU ist sehr tauglich als GPU für Videobeschleunigung und "kleinere" 3D-Spielchen, ebenso sehr brauchbar als GPGPU-Beschleuniger.
Zugegeben, AMD hat sich bisher softwareseitig nicht mit Ruhm bekleckert, aber sie arbeiten daran. Neue SDKs, Debugger usw.
Aber, das Potential das dort schlummert ist enorm. Überlegt man was alleine die 80 Shaderkernchen eines Zacate in GFlops zu Leisten im Stande sind und zu welchem Preis/welchem Energiebedarf.
Genau hier wirds mittelfristig sehr lustig, wenn Bildbearbeitungssoftware und div. Algorithmen dank OpenCL stromsparender & schneller auf APUs rechenen können als auf CPUs alleine. Dann müssen nur noch einige Hürden bei der Zusammenarbeit/Speicherverwaltung zwischen CPU-Teil und GPU-teil der APU genommen werden und es geht rund! Photoshop auf einem Netbook
mocad_tom
Admiral Special
- Mitglied seit
- 17.06.2004
- Beiträge
- 1.234
- Renomée
- 52
Wie jetzt... ? Fusion würde etwas bringen?
Tja, bei sehr hoher Datenlokalität und oft regelmäßigen Operationen passt das gut zu den vielen kleinen GPU-Shaderkernen mit vielen lokalen Registern u. Caches.
Dieses Paper:
http://www.duke.edu/~BCL15/documents/azizi2010-isca-opt.pdf
Plus die Annahme, dass Algos mit hoher Datenlokalität gut zur GPU passen -> daraus folgt doch dann:
Wir brauchen einen breiten General-Purpose-Prozessor für stark chaotische Instruktionen+Daten
und
eine GPU für sehr strukturierte Instruktionen+Daten (weil Energieeffizienter)
Wenn man das schon weiß - warum macht man dann BD nicht 4-Issue-OoO?
Lynxeye
Admiral Special
- Mitglied seit
- 26.10.2007
- Beiträge
- 1.107
- Renomée
- 60
- Standort
- Sachsen
- Mein Laptop
- Lifebook T1010
- Prozessor
- AMD FX 8150
- Mainboard
- Gigabyte GA-970A-UD3
- Kühlung
- Zalman Reserator 1 Plus
- Speicher
- 4x8GB DDR3-1600 G.Skill Ripjaws
- Grafikprozessor
- ASUS ENGTX 260
- Display
- 19" AOC LM928 (1280x1024), V7 21" (1680x1050)
- HDD
- Crucial M4 128GB, 500GB WD Caviar 24/7 Edition
- Optisches Laufwerk
- DVD Multibrenner LG GSA-4167B
- Soundkarte
- Creative Audigy 2 ZS
- Gehäuse
- Amacrox Spidertower
- Netzteil
- Enermax Liberty 500W
- Betriebssystem
- Fedora 17
- Webbrowser
- Firefox
- Verschiedenes
- komplett Silent durch passive Wasserkühlug
Dann müssen nur noch einige Hürden bei der Zusammenarbeit/Speicherverwaltung zwischen CPU-Teil und GPU-teil der APU genommen werden und es geht rund!
Welche Hürden? Der Zero-Copy Pfad kann inzwischen genutzt werden. Die Entwickler müssen nur noch die Dokumentation lesen und diese umsetzen, aber das ist mit OpenCL insgesamt das selbe Spiel.
Edit:
Dieses Paper:
http://www.duke.edu/~BCL15/documents/azizi2010-isca-opt.pdf
Plus die Annahme, dass Algos mit hoher Datenlokalität gut zur GPU passen -> daraus folgt doch dann:
Wir brauchen einen breiten General-Purpose-Prozessor für stark chaotische Instruktionen+Daten
und
eine GPU für sehr strukturierte Instruktionen+Daten (weil Energieeffizienter)
Wenn man das schon weiß - warum macht man dann BD nicht 4-Issue-OoO?
Weil der Vorteil der CPUs gegenüber den Shaderkernen nicht in der Breite der ALUs liegt, sondern an der Fähigkeit durch große Caches, sehr gute Dekoder, sinnvolle Branchprediction, usw. annehmbare Geschwindigkeiten bei stark verzweigendem (chaotischem) und wenig parallelen Code zu erreichen. Allein schon diese Tatsache zeigt doch, dass es nicht sinnvoll ist mehr parallele superskalare Einheiten zu verbauen, sondern das Transistorbudget in das Umland der ALUs/AGUs zu stecken, um diese sinnvoll auszulasten. -> Genau das, was bei BD gemacht wurde.
Zuletzt bearbeitet:
Die Entwickler müssen nur noch..... Klar passiert nebenbei, genau das ist das Problem CUDA funktioniert doch auch nur weil NV es massiv unterstützt.
Das ist ein ernstes Problem sonst würde es doch passieren wo sind denn die Applikationen dafür? Klar im Browser ganz fein aber geht auch prima ohne oder?
Und dann ist es nicht mehr als auch Intel hat nur bessere GPU schlechter CPU und ne Menge schlummerndes Potential aber ich kauf nichts mehr was in X Jahren Y% Leistung bringen soll.
Kamm ganz oft genau nicht so.
Das ist ein ernstes Problem sonst würde es doch passieren wo sind denn die Applikationen dafür? Klar im Browser ganz fein aber geht auch prima ohne oder?
Und dann ist es nicht mehr als auch Intel hat nur bessere GPU schlechter CPU und ne Menge schlummerndes Potential aber ich kauf nichts mehr was in X Jahren Y% Leistung bringen soll.
Kamm ganz oft genau nicht so.
Ähnliche Themen
- Antworten
- 0
- Aufrufe
- 465
- Antworten
- 0
- Aufrufe
- 950
- Antworten
- 0
- Aufrufe
- 889
- Antworten
- 3
- Aufrufe
- 1K