AW: AMD Radeon R9 290X im Test: Der langersehnte Titan-Killer für 479 Euro?
Solange der Xeon Phi so abschneidet, brauchen sich AMD und Nvidia kaum Sorgen zu machen.
Anhang anzeigen 691197
Kommt von Paralution. "a non-preconditioned CG is performed on a Laplace matrix resulting from a finite difference discretization of the unit square with 4.000.000 unknowns." Jeder Beschleuniger durfte seine Lieblings-API nutzen, Intel bekam OpenMP.
Naja, fragt sich jetzt, was Sie da alles mit rein zählen in die Zeitmessung. Also ob die Transfers auch rein zählen oder nicht usw. Da muss man schon aufpassen. Je nachdem kann sich da das Ergebnis noch gravierend verändern, wenn man die Setupzeiten mit rein nimmt, oder nicht. Ich weiß noch, wie wir unsere Leistungswerte "kreativ gepimpt" haben in den Übungen zu den Vorlesungen
Das war echt teilweise nicht mehr feierlich...
Soweit ich das gerade aus dem Code raus sehen kann, hat man nur die reinen Ausführungszeiten gemessen, also ohne Overhead aus den Transfers. Gerade das macht teilweise schon massiv viel aus, wobei man aber auch sagen muss, man versucht ja diese Latenzen zu verstecken hinter Berechnungen. Was aber auf jeden Fall nicht gegeben ist, ist die Sync über Workgroups hinweg, soweit ich das sehe. Also sprich du startest die Berechnung und gut ist. Da kann XeonPhi natürlich seine Vorteile nicht so ausspielen. Der kommt halt sehr gut mit irregulären Programmabläufen klar. Das hat man hier weniger. Wenn auch DynamicParallelism das Problem bei K20(x) entschärft hat.
Was ich von OpenMP halten soll auf XeonPhi weiß ich auch nicht. Klar, es ist einfacher und hat meist ähliche Performance wie PThreads, aber ob das so optimal ist? hm. Ist halt alles ziemlich abstrahiert schon. Da sieht man dann halt auch einen großen Vorteil von XeonPhi nicht. Die Programme sind VIEL! einfacher zu debuggen für XeonPhi im Vergleich zu CUDA/OpenCL. Also zumindest ich brauch nur einen Bruchteil dafür, und ich hab ja doch schon das eine oder andere gemacht.
Zudem bleibt Intel ja nicht stehen mit XeonPhi. Ich würd dazu jetzt ja auch gern noch was sagen und hab auch fünf mal angesetzt, wie ich es denn jetzt sagen soll, aber das wird nichts
Ich kann da nur soviel zu sagen. Das mit der absoluten Leistung ist richtig. An der Perf/W arbeitet man sehr intensiv. Ich seh die aber gar nicht mal als DAS Totschlagargument an. CUDA und OpenCL sind einfach aufwändig zu programmieren. Bis man nur die Software so weit hat, dass Sie überhaupt funktioniert, geschweige denn schneller ist, als die CPU Version, dauert es, und man muss echt gut wissen, was man macht. Wenn man dagegen ne OpenMP/Pthreads/MPI Version von nem Programm hat, dann lässt sich das echt verdammt schnell auf XeonPhi portieren, und es läuft erstmal. Klar die Performance ist dann bäh, aber es läuft schonmal, und die Optimierung ist dann halt echt straight foward. Man weiß wohin die Reise gehen soll. Bei CUDA/OpenCL ist das viel mehr nen Krampf und auch ein Bauchgefühl. Vor allem wenn man SAchen debuggen muss. Das ist soooo hässlich in OpenCL und CUDA. Da verplempert man schnell Stunden wegen irgend nem ganz stumpfen scheis... Für CPUs oder XeonPhi Multithread zu programmieren ist dadagegen echt nen Traum..
Man muss aber glaub ich echt einfach mal selbst was für CUDA/OpenCL, und dann einmal für XeonPhi das gleiche Problem implementiert haben, um das verstehen zu können. Ich konnte es echt auch nicht glauben/nachvollziehen, bis ich nicht selbst nen KNx im Geschäft bekommen hab. Das ist einfach was total anderes. Für den fancy shit, den ich mach, brauchts zwar auch etwas und man bekommt auch graue Haare, aber wenn man mal hinter die Besonderheiten gestiegen ist, ist es echt sowas von straight forward, das gibts garnicht.
Ob sich Leute, die wirklich ernsthaft Programme für Beschleuniger in Clustern entwickeln wollen, wirklich mit Consumer-Karten abgeben, mag ich kaum glauben.
Es hat keiner was zu verschenken da
Klar, in den Produktivsystemen haste halt meist nen kleinen Developercluster noch dabei, der halt die gleiche Architektur hat nur mit ein paar wenigen Knoten. Da haste aber halt absolut KEINE! Chance drauf zu kommen. Überhaupt die ganzen Produktivsysteme sind halt komplett zu für die Lehre. Da kannste voll knicken. Da lässt dich keiner drauf, weil die Dinger eigentlich immer ausgelastet sind, und es einfach nur suckt, wenn da noch jemand anderes rumhampelt auf den Kisten. Du willst da gerade fürs Developing eigentlich immer die Kisten exklusiv für dich haben. Sonst brauchste gar nicht anfangen mit optimieren.
Klar, Studenten, die haben ja chronischen Geldmangel - zumindest behaupten das alle - aber für Lehranstalten gibt es meistens über irgendwelche Sponsoring-Programme günstige Arbeits-Hardware zu beschaffen. Alternativ konnte man zu meiner Zeit noch Zeit im RRZ beantragen.
Schön wärs...
Wie gesagt, wenn man wirklich vernünftig arbeiten will, braucht man die Kisten exklusiv für sich. Das war in den Vorlesungen schon immer nen riesen Krampf, wenn wir mal was auf mehr Nodes machen sollten, und halt mal "vernünftige" Kisten verwenden durften. Da biste extra um 3 Uhr Nachts aufgestanden, damit kein anderer dir in die Quere kommt... Toll wars, wenn wieder mal einer meinte, Skripte über Nacht laufen lassen zu müssen... Der wurde dann teils fast gelyncht
Ok, mal zurück zum Thema. Wie gesagt, du brauchst halt exklusiven Zugriff. Also muss das Institut für die Studis eigentlich nen Rechner hinstellen, der nur für die da ist. Das wird aber faktisch nicht gemacht. Die Gelder sind da echt knapp, und keiner fühlt sich da wirklich zuständig und stellt mal kurz REchner für mehrere tausend € hin.
Selbst wenn du Consumerkarten verwendest, ist die Kiste an sich halt schon sack teuer.
Man braucht ja mindestens folgendes:
2-4 Dual-Sockel Boards mit BMC, damit man die REchner remote Powerreseten kann
4-8 CPUs mit min 4, eher 8 Kernen
16GB RAM pro CPU
2-4 Infiniband Karten
HDD
Rackgehäuse
min eine GPU/XeonPhi pro Node, besser 2
und dann noch jemand der sich um die Verwaltung kümmert
Und das machste jetzt für vielleicht 10 Studis, die das nutzen, und dann sollteste ja auch noch jeweils ne Version für XeonPhi, nVidia und AMD haben. Und da am Besten auch eher zwei denn nur eine Gen....
Wir haben z.B. damals auf ner GTX460 arbeiten müssen, weil halt kein Geld für was bessere für die Studis da war...
Ohne Eigeninitiative kommste da einfach null weiter, so lange du nicht fest angestellt bist. Irgendwoher müssen ja aber die Leute kommen, die sowas überhaupt programmieren können...
Man kann ja aber shcon froh sein überhaupt mal an Hardware ran zu kommen. Viele verschiedene sind völlig utopisch.
Auf der anderen Seite gabs mal Ideen bei uns zu nem Projekt bzgl. hoher Integration, als die GTX Titan raus kam. Hätte die RDMA gekonnt, wären zwei Kisten mit jeweils 7 GTX Titan drinnen angeschafft worden
Das Sie es aber nicht konnte, und das ein Musthave war, ist das halt gestorben. 14 K20 wären dann halt doch zu teuer geworden...
