anonymous_user schrieb:
Das habe ich doch schon in meinem letzten Post erklärt...
hUMA ist in der hinsicht keine Optimierung. Immernoch: hUMA erspart dem Programmierer jeden Vorgang des hin und her Kopierens von Speicherbereichen. Da wird nichts zusätzlich im Code benötigt, sondern weggelassen!
Und was soll denn bitte der Hinweis dazu dass PCIe 3.0 keinen Performance Vorteil bringt? Wir reden hier immer noch von HSA, nochmal als erklärung von was wir hier reden:
huma ist eine Optimierung. Eine die nicht "automatisch" verwendet wird. Da muss zuerst jemand hergehen und die entsprechende API wie D3D, OGL, OCL anpassen(sodass entsprechender Code zum Kopieren weggelassen wird). Soweit ich weiß nimmt MS keine Dinge in seinen Standart auf, die nur ein Hersteller beherrscht und in OGL, OCL habe ich sowas auch noch nicht gesehen. Da könnte AMD höchstens eine Extension schreiben, welche aber nicht automatisch genutzt wird.
Daher macht auch Mantle Sinn.
anonymous_user schrieb:
http://de.wikipedia.org/wiki/Heterogeneous_System_Architecture
Dein Vergleich mit PCIe2 vs. PCIe3 hat also rein garkeinen Wert um daraus irgendwelche Schlüsse zu ziehen die man auf APU's Anwenden kann.
Wir reden hier von HSA, ja. Und ich bin mir im Klaren darüber dass in einer APU kein PCIe verläuft. Aber das Problem, dass Speicher von CPU zur GPU kopiert werden muss besteht sowohl in einer APU als auch in einem getrennten System. In einer APU wird von RAM nach RAM kopiert, in einem getrennten System von RAM nach VRAM. Wenn jetzt die Verdopplung dieser Geschwindigkeit in einem getrennten System(Wechsel von PCIe2.0 auf PCIe3.0) keine Performance bringt ist der Kopiervorgang kein Flaschenhals, was natürlich auch für das System mit APU gilt. Logischerweise hat es keine großen positiven Performanceauswirkungen, wenn man etwas optimiert, das kein Flaschenhals ist.
anonymous_user schrieb:
Und auch das ist mal wieder Apfel & Birnen... Ein teil von HSA ist u.a. hUMA, womit schon der ganze Absatz wiederlegt ist.
Aber rate doch mal, vielleicht ist ja die HSA Entwicklerplattform genau dafür gedacht u.a. den Entwicklern die Nutzung der GPU durch eben solche Dinge wie hUMA einfacher zu machen! Das ist das Typische Henne Ei Problem. Wäre deine Aussage zutreffend, würden wir heute noch Rechenschieber benutzen, die waren zu der Zeit schließlich für jeden Verständlich und Zugänglich.
Mag sein dass huma Teil von HSA ist, aber da huma auch ohne HSA möglich wäre, kann man schlecht den huma Performanceschub zum HSA Performanceschub dazuzählen.
Und ja durch huma wird GPGPU einfacher. Aber leider nicht viel einfacher, sondern nur minimal, da man nach wie vor Funktionen schreiben muss die hochparallelisierbar sind. Etwas, das normale Softwareentwickler einfach nicht machen.
Und wenn man die theorethische Performance perfekter Software mit typischer Performance reeler Software im Laufe der Zeit vergleicht, wird man bemerken, dass noch nie so ineffizient programmiert wird wie heute. Sieht man auch schön an häufig verwendeten Programmiersprachen: Assembly -> Fortran -> C -> C++ -> Java -> HTML5?
Das liegt auch nicht am Henne-Ei Problem, sondern ganz einfach daran, dass Performance ziemlich billig ist. Deswegen haben solche Technologien wie GPGPU & Co im Consumer Bereich sehr wenig Erfolg. Nur im HPC Bereich sieht es besser aus, aber die verwenden keine APUs.
anonymous_user schrieb:
Und schon wieder die Leier von GPGPU. Das die GPU eventuell durch weniger nötige Speicheroperationen und LowLevel Optimierungen wieder Luft nach oben hat ist nicht möglich? Und es geht bei HSA immernoch nicht nur um GPGPU, andere Szenarien seitens AMD sehen nämlich vor eine Aufgabe auf CPU und GPU gleichzeitig zu beschleunigen.
Davon ab, der Wunsch von Dice und EA(die auch schon 15 Titel angekündigt haben) nach Mantle zeigt wohl ganz eindeutig dass da noch einiges geht.
Der Hauptzweck von HSA ist GPGPU. Der Hauptzweck von huma ist sich Kopieroperation zu sparen. Aber wie oben schon erwähnt wird das nicht viel bringen da es kein Flaschenhals ist. Dementsprechend hat die GPU auch nicht viel mehr Zeit als vorher.
Typischerweise ist die GPU eher der Flaschenhals als die CPU, weswegen man immer noch keine GPGPU Aufgaben der Grafikkarte überlassen sollte, trotz HSA.
anonymous_user schrieb:
Ja momentan gibt es nur Produkte von AMD, aber dass die von mir oben genannten "Founder" Firmen jeweils der HSA Foundation 125.000$ im Jahr bezahlen liegt sicherlich nicht daran dass die unglaublich gerne Inhaltslose AMD Vorträge anhören und in alldem keinen Sinn sehen. Früher oder später werden die HSA Paradigmen selber Implementieren, oder AMD HSA Produkte nutzen.
Für solche Unternehmen sind das Peanuts. Soviel verdient wahrescheinlich der durchschnittlich US-Mitarbeiter. Ich denke eher die springen auf den Zug auf um zu schauen wo er hin fährt.
anonymous_user schrieb:
Den Vorteil hat man nicht verloren, nur Fertigt Intel seine Chips schneller in kleineren Strukturen. Intels neuster ATOM kann dem Apple A7 nichtmal im Ansatz das fürchten lehren. Einerseits weil Apple gute Chipdesigner übernommen hat in den letzten Jahren, und anderseits weil der A7 seine 64Bit ausspielen kann im Vergleich zu Intel mit Windows Tablets oder Android Smartphones. Das 5S ist in fast allen Disziplinen schneller als Baytrail. Stromverbrauch liegt gleich auf, und das bei 28nm A7 vs. 22nm Bay Trail.
Ich nehme an du beziehst dich auf den Anandtech Test. Der bestätigt dein Aussage auf den ersten Blick. Auf den zweiten widerlegt er sie aber. In diesem Test werden hauptsächlich Benchmarkes verwendet die nur einen bis zwei Kerne unterstützen(Geekbench ist eine Ausnahme). Je nach Benchmark ist der A7 vorne oder der Baytrail. Da der A7 ein Dualcore ist, ist er zu 50% bzw. zu 100% ausgelastet. Der Baytrail dagegen nur zu 25% bzw. 50%. Unter Vollast verbraucht der A7 etwas weniger als der Baytrail. Da der Baytrail aber nur halb so stark ausgelastet ist wie der A7 impliziert das, dass der Baytrail wesentlich weniger Energie verbraucht und so effizienter ist. Und bei optimierten Apps ist der Baytrail dann doppelt so schnell.
Bei der GPU ist der A7 natürlich besser. Auf der anderen Seite gibt es keine Android-Spiele, die man mit Baytrail nicht auf max spielen könnte, weswegen das auch nicht wirklich so relevant ist wie es gerne dargestellt wird.
anonymous_user schrieb:
Und die letzte Spitzenidee wurde garnicht in die Tonne gekloppt, nur ist erstmal die Entwicklung von ARMv8 SoC's für alle beteiligten erstmal Interessanter. Ohne zusätzlichen Verbrauch bei Wechsel von 32nm auf 28nm verdoppelt sich die Rechenleistung bei Entsprechendem 64Bit OS.
Qualcomm hat gesagt, dass sie big.little nicht verwenden werden. Und damit hatten sie im Vgl zum Tegra4 und Exynos Octa jede Menge Design Wins.
anonymous_user schrieb:
Du betrachtest dass alles einfach zu Schwarz & Weiß. Wenn die Möglichkeit besteht, kann man auf der APU auch einfach auf beiden Einheiten beschleunigen anstatt nur CPU oder GPU. Davon ab soll wohl der Standard Compiler LLVM werden/sein.
Du kannst mir glauben, dass es heute unter normalen Umständen nicht möglich ist ein Programm automatisch zu parallelisieren. Und angesichts der Komplexität in dem Bereich und der Tatsache, dass man vor algorithmisch unlösbaren Problemen steht wird das auch noch Jahrzehnte dauern.
anonymous_user schrieb:
Mann muss Java nicht mögen, aber die meistgenutzte Programmiersprache HSA Tauglich zu machen kann in jedem Fall nur Sinnvoll sein.
Da es nicht automatisch gehen wird, darf dann ein Java Programmierer GPGPU verwenden. Ein sehr schöner Zielgruppenfail.
anonymous_user schrieb:
Das brauchste mir nicht sagen, du vergleichst eine einzelne Befehlssatzerweiterung mit ganzen Hardware Standards und Programmier Paradigmen. Und nebenbei Diskutierst du über HSA, hast das Konzept aber allem Anschein nach garnicht verstanden.
Ich hab auch garnicht bezweifelt das AVX512 in irgendeiner weise Nutzlos ist oder wenig bringen würde. Aber HSA, das ein Konzept ist wie die Hardware zu sein hat, die wiederum aus CPU&GPU besteht, die wiederum aus einzelnen Registern Besteht, die wiederum für Unterschiedliche Befehlssatzerweiterungen genutzt werden wie eben AVX512, sollte doch einleuchten? Und da haben wir nicht mal die Software Seite Berücksichtigt, die u.a. Compiler & Programmiersprachen Anpassungen, Integration/Entwicklung unterschiedlicher API's und Schlussendlich der Entwicklerplattform als Gesamtes, benötigt.
Nein, du hast das Konzept nicht verstanden. HSA referenziert zwar die CPU und die GPU, beinhaltet sie aber nicht. HSA ist nur der Teil in CPU&GPU der dafür sorgt dass keine Fehler entstehen wenn CPU & GPU auf die gleichen Daten zugreifen. Also bspw. um False Sharing zu vermeiden.
Und bezüglich Umfang: HSA muss sich auf kleinen dies für mobile SoCs unterbringen lassen, AVX512 wird für Jahre nur auf den großen dies für HPC, Server und Desktops zu finden sein. Der Grund liegt einfach im viel höheren Flächenbedarf.
anonymous_user schrieb:
Und zu den Reference Programming Manuals: Wie schon gesagt, die AMD Entwicklerplattform ist noch nicht beendet, Einsicht in alle Dokumente zu HSA haben wir wahrscheinlich (im moment noch) garnicht. In dem von dir genannten Dokument geht es nämlich nur um die dort genannten HSA Teile, nur ist das leider nicht alles. Und in dem Intel Dokument geht es "nur" bis Seite 100 um AVX512, die Restlichen Seiten drehen sich um alle Art AVX und SSE Befehle soweit ich das gesehen habe. Und das Inhaltsverzeichnis dessen scheint mir da auch recht zu geben.
AMD sollte seine Hardware schon fast fertig haben. Da noch die Spezikationen zu ändern ist sogut wie unmöglich.
Bezüglich des Intel Dokuments: Das hast du falsch gesehen. Das ganze Dokument beinhaltet nur zukünftige Befehlssätze. Und Kapitel 5 das von Seite 100 bis 800 reicht beinhaltet ausschließlich AVX512 Befehle.
Um das in Relation zu stellen: Momentanige x86 Referenz beinhaltet 1700 Seiten für GeneralPurpose, x87, MMX, SSEx, AVX(2), TSX. Da sieht man stark der Befehlsatz wächst.
anonymous_user schrieb:
Zum Rest: Abwarten und Tee trinken. Mutmaßungen was wieviel bringt ist zum jetzigen Zeitpunkt viel zu gewagt. Und selbst wenn Int und Float Throughput verdoppelt werden, die muss man erstmal auf die Straße bringen.
Gerade bei SIMD lässt sich der Durchsatz einfach und verlässlich vorraussagen, da die dazu benötigten Informationen offen sind.
Und bisher ist jede Befehlssatzerweiterung auf der Straße gelandet.
na ja passt auch hier ...
