Alles rund um Compiler und Softwareentwicklung

Also wer die Folien zugelassen hat..
Da stimmt ja mal überhaupt keine Spaltenbreite.
 
Also wer die Folien zugelassen hat..
Da stimmt ja mal überhaupt keine Spaltenbreite.

Das Gerücht das AMD ihren durchgeknallten Folienpraktikanten zur HSA-Group abgeschoben hat könnte den Kursprung der AMD-Aktie im letzten Monat erklären.
Die Erkenntnis das dieser dümmste anzunehmende Vollidiot noch einen Bruder hat würde dann wiederum den Kurssturz erklären.
 
Interessante Folien, aber ohne neue ERkenntnisse eigentlich.
Klar kann eine CPU alles berechnen was eine GPU auch berechnen kann, die Frage is tnur wie lange das dauert.
Und wie gesagt, die HSAIL muss noch in CPU und GPU maschinencode übersetzt werden.
Zwar ist es schlussendlich egal ob die CPU oder die GPU das dann ausführen, das gilt aber nicht dediziert für "FMA befehle" sondern eben für "HSA Befehle" - ob die in x86-FMA übersetzt werden und auf der CPU ausgeführt oder in GPU-MAschinencode ist dann eien Frage des Schedulings bzw. des Algorithmus der dann letztenendes bestimmt auf welchem Computing device der Code am ende landet.
Wenn irgendwo in einem bestehenden x86-Programm aber irgendwo eine Handvoll FMA-Befehle drinstehen, werden die sicher nicht auf die GPU ausgelagert, das ist dann nämlich kein HSA. Außerdem ist der Maschinencode für einen FMA-Befehl auf der CPU garantiert anders als irgend ein GPU-Befehl. Von Spitzfindigkeiten bei der Adressierung ganz zu schweigen.
Also HSA ist toll und ein wunderschöner Schritt in Richtung besserer Ausnutzung der vorhandenen Rohleistung, aber HSA wird nich so einfach die FPU überflüssig machen oder allen bestehenden x86-Code mal eben magisch auf die GPU bringen.
Den besten LEistungzuwachs bzw. spürbaren Vorteil wird das bestimmt auf Mobilgeräten haben, wenn die GPU die im normalfall däumchen dreht dann dank HSA dazu beitragen kann dass irgendwas zeitnah fertig wird. Leider sind die kleineren APUs ja noch nicht wirklich voll HSA-tauglich. Aber das kommt sicher auch noch.
 
Wenn irgendwo in einem bestehenden x86-Programm aber irgendwo eine Handvoll FMA-Befehle drinstehen, werden die sicher nicht auf die GPU ausgelagert, das ist dann nämlich kein HSA.

Das ist schon klar. Wenn, dann über Compilereinstellungen: Verwende bitte kein FPU, SSE oder AVX sondern nutze die GPU, wenn integriert.
Mit der Zeit könnten dann die Einheiten auf der CPU überflüssig werden.
 
Und die CPU willst du dann nur noch aus int-einheiten bauen? - was wenn ein HSA finalizer selbst floatingpoint-code braucht? - Soll das dann auch auf der GPU laufen und AMD muss einen GPU-lauffähigen HSA-Finalizer bauen oder wie oder was?
Damit will ich sagen, solange das Ding eine General Purpose CPU sein soll, muss sie auch in der lage sein jeden erdenklichen (x86) Code auszuführen. Natürlich kann der HSA finalizer entscheiden dass eine gewisse Befehlsfolge auf der GPU besser aufgehoben ist als auf der CPU aber der finalizer selbst ist ja auch nur ein Programm - im prinzip ähnlich des JIT-Compilers von java oder .net. Und es müssen zumindest alle Einheiten die genau für diesen Prozess benötigt werden vorhanden sein damit irgend ein "switch" möglich wird.
 
Und die CPU willst du dann nur noch aus int-einheiten bauen?
Du glaubst gar nicht, wieviele CPUs ohne Float noch unterwegs sind. Da freut man sich schon, wenn die wenigstens Hardwareunterstützung für Division drin haben. ;)
 
Nagut meientwegen. - Ich persönlich halte es in Anbetracht der Tatsache wie unbedeutend die Transistormengen von FPUs und Divisinsschaltungen heutzutage sind (im Gegensatz zu Caches, Dekoderlogik, Northbridge usw.) nur irgendwie für Sinnlos. Ich meine, schaut euch an wie klein die Bobcat-Kernchen sind, und was sie dennoch leisten können. Die haben immerhin eine 64Bit FPU. Und die Jaguare die deutlich potenter sind und eine "volle" FPU vorweisen können, sind immernoch alles andere als riesig. Also ist das IMHO am falschen Ende gespart, aber who knows...
Viel wichtiger als deratige Diskussionen ist, dass AMD sich ins Zeug legt um HSA entprechend zu promoten und die Runtime Verbreitung findet. Gerade auch unter Entwicklern.
Da können schon Spezifika wie Lizenzen, Einfachheit der Benutzung, Datenstrukturen etc. den Ausschlag geben ob jemand HSA verwenden will oder weiter nach dem bisherigen Schema einfach das nächstbeste nimmt das seine Plattform hergibt bzw. was sowieso Teil der Standard-Runtime ist. - Wenn Das nicht hinhaut, ist alle Diskussion hier für die Muschi und die ewigen Nörgler behalten letzten Endes doch recht. Die GPU-Teil in APUs bleiben mehrheitlich nichts als überdimensionierte Windows-Desktop-Darsteller. *noahnung*
 
Ich nutze regelmäßig Open Source Grafiksoftware wie GIMP und Inkscape. Bei diesen Programmen herrscht Entwickler-Mangel, da kann die Unterstützung moderner CPUs länger dauern, aber sie kommt: die nächste Version von Inkscape (0.91) wird multi-core-fähig, GIMP 2.10 wird Berechnungen auf mehreren Kernen UND der GPU unterstützen. Wobei die beiden Programme für meine Zwecke auch schnell genug waren, ich saß nicht davor und habe gewartet. Jedenfalls werden die Single-Thread-Inseln weniger, wenn dann gleich die GPU mit eingespannt wird ist das doch eine gute Sache!
 
(Ich hoffe, mein Kommentar rutscht nicht zu sehr ins OT ab)
Ich habe mit gimp Bilder der Größe von 5-8 Megapixel bearbeitet. Bei sämtlichen Transformationen, vom Drehen, Skalieren über Gaussche Unschärfe bis hin zu Median-Filter hat der jeweilige Bearbeitungschritt um geschätzt den Faktor 8 länger gedauert als mit PS-cs2, meist im höheren einstelligen Minutenbereich. Sollte tatsächlich eine baldige HSA-fähige Version von gimp erscheinen, müsste ich mir noch eine kleine Testroutine für den Vergleich einfallen lassen. Ich bin da offen für Anregungen.
 
Gib mal ein Beispielbild. Mag das nicht so ganz glauben mit mehreren Minuten. Da stelle ich das mal nach bei mir unter Gentoo.
 
@GIMP, sorry für das Abwandern in Richtung OT
Ich habe mich über GIMP auf Wikipedia zu der dort verlinkten Quelle in Sachen Mehrkernfähigkeit vorgearbeitet und stelle fest, dass der voraussichtliche Erscheinungstemin von Gimp 2.10 Ende 2013 sein soll. Hm. Bisher ist noch kein GIMP 2.9 releast. Wann soll das denn kommen? Bzw. gibt es neuere Infos als die von mir gefundenen?
MfG
 
Nicht wirklich. When it's done. Ich weiß nicht, ob 2.9 noch als Zwischenversion kommt. Aber 2.10 wird ein riesiges Update. Da dann standardmäßig GEGL für alles genutzt wird, werden automatisch die meisten alten Probleme beseitigt. Wichtig finde ich dabei die 16Bit Farbtiefe (oder gar höher). Zusätzlich dann auch OpenCl Unterstützung für alle Operationen (wenn ich mich nicht irre). Sollte sich dann mit einem Schlag für ernsthafte Bildbearbeitung eignen. Deswegen sollen sie da ruhig genug Zeit investieren, damit auch was gutes bei raus kommt.
 
Da war mein Gedächtnis wohl doch etwas zu kreativ: Die Bilder sind im Bereich von 185-190 Megapixel(!), und wirklich Rechenzeit verschlingen lediglich die sehr aufwändigen Operationen wie Filter. Ich werde meine vorläufigen Ergebnisse bei Erscheinen der neuen GIMP Version in einem Vergleich gegenüberstellen.

GIMP 2.8.10 Linux Kernel 3.14.8-100.fc19.x86_64
Bildeigenschaften: Breite 10971 px, Höhe 17043 px, RGB,
Auflösung 4800 pixel/in

Aufgabe 1: Bild horizontal spiegeln
GIMP 2.8.10
0 min 12 s


Aufgabe 2: Bild drehen um 4.30° um das geometrische Zentrum

GIMP 2.8.10
1 min 39 s
Kernauslastung in htop: hauptsächlich 1 / 4 Threads, wechselt sprunghaft zwischen Kernen


Aufgabe 3: Filter: Gausscher Weichzeichner, 15 pixel, Einstellung: RLE
GIMP 2.8.10
1 min 13 s


Aufgabe 4: Filter: Medianfilter (heißt bei GIMP "Flecken entfernen")
Schwellenwerte für Schwarz und Weiß werden dabei auf -1, respektvie 256 belassen (Filterung ohne Schwellenwert)

Radius: 24
Option 1: normal

GIMP 2.8.10
9 min 08 s
Kernauslastung in htop: hauptsächlich 1 / 4 Threads, die Auslastung der Kerne ändert sich sprunghaft


Aufgabe 5
Bild skalieren: Von 4800 dpi auf 600 dpi
Einstellung 1: linear

GIMP 2.8.10
0 min 03 s

Einstellung 2: Kubisch

GIMP 2.8.10
0 min 07 s
 
Zuletzt bearbeitet:
Hab mich schon gewundert - mehrere Minuten hab ich nie gewartet. Das einzig "zählbare" Verzögerung sind Filter. 2.9.x sind übrigens die Entwicklerversionen, die zu 2.10 führen.

Was machst du mit solchen Pixelmonstern? ist
 
Ja, das AMD-Marketing und die Präsentationsschöpfer können, wenn sie wollen. (Oder dürfen?!)
 
Interessante Kurzpräsentation zum PGI Compiler:
http://de.slideshare.net/insideHPC/pgi-2014

pgi-2014-overview-3-1024.jpg


Der scheint auch für AMD Produkte Vorteile haben mit der Unterstützung für OpenACC. Hier mehr Details dazu:
http://de.slideshare.net/DevCentralAMD/pl-4044-michaelwolfe?next_slideshow=1

--- Update ---

Mir scheint Nvidia hier damit heterogenes Computing bei Supercomputern forcieren zu wollen:
http://de.slideshare.net/Ruyk/directivebased-approach-to-heterogeneous-computing
 
Könnte es sein, dass Rory Read endlich in die Compilerentwicklung investiert oder zumindest moralische Unterstützung liefert?
 
Naja das geht ja gar nicht anders wenn HSA funktionieren soll.
 
In den letzten Jahrzehnten kam AMD ja ganz "gut" ohne das aus.
 
Da sprechen Marktanteile aber eine andere Sprache. Und die Compiler Situation hat mit Sicherheit ihren Beitrag dazu geleistet warum AMD Produkte als nicht Konkurrenzfähig gelten.
 
Die letzten Monate haben schon gezeigt, dass AMD endlich erkannt hat, dass gute Hardware auch entsprechende Software braucht.
Die Compiler sind ein Bereich, der allerdings zur Zeit vor allem bei OpenCL noch sehr ausbaufähig ist, HSA ist eine weitere große Baustelle an der gearbeitet wird. Aber vor allem mit Mantle hat man ja nun die hauseigenen GPUs so angespitzt, dass sich alle Großen der Industrie zum Handeln gezwungen sehen. Das ist doch ein großer Erfolg. Bei OpenCL stellte sich bislang vor allem Nvidia quer, die verständlicherweise lieber CUDA etabliert sehen. Aber auch dank Intel gewinnt OpenCL ja derzeit kräftig an Fahrt.
Daneben ist bei AMD aber auch ein wachsendes Interesse an OpenSource und Linux ersichtlich.

Alles in allem ist AMD momentan in vielen Bereichen, in denen bisher Schwächen waren, sehr aktiv und das scheint sich doch, wenn auch langsam, auszuzahlen.
 
@Complicated
Das meinte ich mit den Anführungszeichen. Die Bestimmer bei AMD hielten es für nicht notwendig, das war* das Problem.

* - hoffentlich
 
Ja verdammte Ironie geht immer so vorbei beim lesen - ironisch ;)
 
GCC erhält weitere HSA Optimierungen. Beigesteuert durch SUSE: http://www.phoronix.com/scan.php?page=news_item&px=MTc5NzA
Martin Jambor of SUSE has published a good amount of work for bettering HSA within the GNU Compiler Collection stack. There's work for passing HSA information to libgomp, identifying simple OMP loops, and other big work. The biggest work though was by Ganesh Gopalasubramanian and upgrades the GCC branch of GCC to HSAIL v1.0p while up to now they were using a pre-1.0 version of HSAIL, the intermediate translation language of HSA.

Overall though the GCC HSA support still seems like a big work-in-progress, but at least they have a few months to hopefully beat the support into shape so that it can be found in next year's GCC 5 release. On the LLVM/Clang front I have yet to see any HSA-related work.
 
Zurück
Oben Unten