HWL News Bot
News
Thread Starter
- Mitglied seit
- 06.03.2017
- Beiträge
- 113.949
... weiterlesen
GTC17: Alle Details zur Volta-Architektur von NVIDIA
- Ersteller HWL News Bot
- Erstellt am
... weiterlesen
Für Leute die mit Matlab (und ähnlichen Derivaten) arbeiten ist das schon cool (und für Nvidia sehr profitabel) - für Spieler wird wohl nur der verbesserte Scheduler relevant sein. Hier muss aber gesagt werden, dass die großen spielestudios ihre Engine schon so anpassen, dass der Load-Bereich schon halbwegs balanciert auf die GPU geworfen wird.
Effektiv rechne ich hier mit einer Leistungssteigerung durch Architektur-Verbesserung im einstelligen Prozentbereich bzw niedrigen 2-stelligen. (*daumen in die Luft hält*)
Für Spiele gibts ja auch kaum noch was zu optimieren. Es wurde schon alles angefasst, was man anfassen kann. (Interessant ist, dass Vulkan nicht erwähnt wird - Nvidia geht wohl voll in die Datenzentren mit Volta. Da fühlt es sich schon so an, als ob man die Volta-Architektur auch fürs Spielen missbrauchen kann und jeder Gamer sich wie ein dreckiger Bauer fühlen darf, wenn er das macht ^_^ )
Effektiv rechne ich hier mit einer Leistungssteigerung durch Architektur-Verbesserung im einstelligen Prozentbereich bzw niedrigen 2-stelligen. (*daumen in die Luft hält*)
Für Spiele gibts ja auch kaum noch was zu optimieren. Es wurde schon alles angefasst, was man anfassen kann. (Interessant ist, dass Vulkan nicht erwähnt wird - Nvidia geht wohl voll in die Datenzentren mit Volta. Da fühlt es sich schon so an, als ob man die Volta-Architektur auch fürs Spielen missbrauchen kann und jeder Gamer sich wie ein dreckiger Bauer fühlen darf, wenn er das macht ^_^ )
besterino
Legende
Joah. Jedenfalls die Keynote stand absolut im Zeichen von Deep Learning. Da hätte Gaming auch gar nicht reingepasst. Die ganze GTC richtete sich an Profis, egal ob zum Thema VR, AR, Rendering oder eben Deep Learning. Kann ich auch gut verstehen: im B2B steckt einfach eine viel profitablere Zukunft drin als wenn ich mich mit Consumern um +-50 Euro Preisdifferenz oder 5% Performance-Zuwachs zoffen muss.
Dementsprechend liefen auf der GTC nach meiner Wahrnehmung neben Studenten, Mathematikern, Forschern und sonstigen Technik-Profis auch primär IT-Vertreter aus Industrien wie Automotive, Insurance/Finance, Maschinenbau & Co herum - und über vielem schwebte eben das Thema Deep Learning.
Was man auch nicht vergessen darf: NVidia merkt m.E. schon den Druck auf der potenziellen Überholspur bei sowas wie Googles TPUs. Schon krass, dass sie den eigenen Bereich dazu auch Mitte des Jahres Open source stellen werden.
Schon beeindruckend, wie Nvidia sich da engagiert (natürlich nicht ganz uneigennützig).
Dazu passt dann auch die Aussage von Huang, dass sie das Thema Deep Learning nachhaltig supporten werden: "until the end of our lives". Da war es verdammt still im Raum.
Dementsprechend liefen auf der GTC nach meiner Wahrnehmung neben Studenten, Mathematikern, Forschern und sonstigen Technik-Profis auch primär IT-Vertreter aus Industrien wie Automotive, Insurance/Finance, Maschinenbau & Co herum - und über vielem schwebte eben das Thema Deep Learning.
Was man auch nicht vergessen darf: NVidia merkt m.E. schon den Druck auf der potenziellen Überholspur bei sowas wie Googles TPUs. Schon krass, dass sie den eigenen Bereich dazu auch Mitte des Jahres Open source stellen werden.
Schon beeindruckend, wie Nvidia sich da engagiert (natürlich nicht ganz uneigennützig).
Dazu passt dann auch die Aussage von Huang, dass sie das Thema Deep Learning nachhaltig supporten werden: "until the end of our lives". Da war es verdammt still im Raum.
Zuletzt bearbeitet:
RAZ0RLIGHT
Enthusiast
Maxwell war einfach ein Glücksgriff für Nvidia, deshalb ist Pascal nur ein Maxwell Shrink mit höheren Taktraten (Maxwell/Pascal mit selben Takt = selbe Performance) und Volta zeigt fast nur Verbesserungen im Profi Bereich, aber mal abwarten, vllt. ist da doch mehr dahinter.
Zuletzt bearbeitet:
ja und den Glücksgriff hatte AMD bisher nicht
auch wenn immer viel gesülzt wird von wegen GCN 1.1, GCN 1.2, GCN 2.0, Polaris, Fiji, alles immer Super Duper neu > Nope
seit GCN kennt AMD nur eins: CORES CORES CORES CORES, und ab und an gibts Fertigungsbedingt paar MHz mehr und dann wieder CORES CORES CORES
so richtig super duper neu ist bei denen schon lange nix mehr, zumindest nicht mehr als Maxwell > Pascal > Volta
Vega - Supernova - große klein, 11/12, keine Ahnung was der fette da ist, mit 4096? Cores? takte eine FuryX auf den gleichen Takt und du hast die gleiche Performance
auch wenn immer viel gesülzt wird von wegen GCN 1.1, GCN 1.2, GCN 2.0, Polaris, Fiji, alles immer Super Duper neu > Nope
seit GCN kennt AMD nur eins: CORES CORES CORES CORES, und ab und an gibts Fertigungsbedingt paar MHz mehr und dann wieder CORES CORES CORES
so richtig super duper neu ist bei denen schon lange nix mehr, zumindest nicht mehr als Maxwell > Pascal > Volta
Vega - Supernova - große klein, 11/12, keine Ahnung was der fette da ist, mit 4096? Cores? takte eine FuryX auf den gleichen Takt und du hast die gleiche Performance
RAZ0RLIGHT
Enthusiast
wir wissen ja wie du zu AMD stehst, von daher.
keine andere Antwort habe ich erwartet, die Frage ist hinter welcher Brille du sitzt, das ist ja schon ein Gewächshaus 
RAZ0RLIGHT
Enthusiast
Sonnenbrille, ansonsten keine 
ps. was hätte ich auf so einen Post auch anderes antworten können...
ps. was hätte ich auf so einen Post auch anderes antworten können...
es ist nunmal Tatsache das beide mit GCN/Maxwell die Basis gelegt haben wie intel seinerzeit mit Core
und alles basiert darauf und wird optimiert und beide machen nicht mehr als technisch und technologisch möglich ist
mit einem Unterschied: Maxwell = Pascal = Volta laut einiger Aussagen und das kann man exakt auf GCN beziehen
nicht mehr und nicht weniger - AMD setzt wenigstens auf aktuellste Technologien, das kann man schon honorieren aber es zählt was am Ende rauskommt, egal ob GCN, Maxwell, HBM, GDDR(x) oder Vulcan/DX(x)
Edit: und ja die Preise die Jensen abzieht sind krank, völlig überzogen - muss man nicht drüber diskutieren
es gibt aber genug die sich das leisten können/wollen/müssen und dann ist das einfach mal so
die 2080 oder wie auch immer sie heißen wird kommt sicher noch teurer an den Tisch - das hält man aber nicht auf indem man auf AMD wartet oder AMD kauft oder in Foren agitiert, das Thema ist durch, Nv hat ne Preissparte etabliert und im Zuge von Inflation, Dollarkurs und Einkommensanstieg bleibt das auch so
gemessen am Hauptmarkt Asien wo der Scherbel nix kostet und USA, wo nahezu jeder SLI/Criple SLI hat muss man sich darüber nicht wundern
und alles basiert darauf und wird optimiert und beide machen nicht mehr als technisch und technologisch möglich ist
mit einem Unterschied: Maxwell = Pascal = Volta laut einiger Aussagen und das kann man exakt auf GCN beziehen
nicht mehr und nicht weniger - AMD setzt wenigstens auf aktuellste Technologien, das kann man schon honorieren
aber es zählt was am Ende rauskommt, egal ob GCN, Maxwell, HBM, GDDR(x) oder Vulcan/DX(x)Edit: und ja die Preise die Jensen abzieht sind krank, völlig überzogen - muss man nicht drüber diskutieren
es gibt aber genug die sich das leisten können/wollen/müssen und dann ist das einfach mal so
die 2080 oder wie auch immer sie heißen wird kommt sicher noch teurer an den Tisch - das hält man aber nicht auf indem man auf AMD wartet oder AMD kauft oder in Foren agitiert, das Thema ist durch, Nv hat ne Preissparte etabliert und im Zuge von Inflation, Dollarkurs und Einkommensanstieg bleibt das auch so
gemessen am Hauptmarkt Asien wo der Scherbel nix kostet und USA, wo nahezu jeder SLI/Criple SLI hat muss man sich darüber nicht wundern
Zuletzt bearbeitet:
RAZ0RLIGHT
Enthusiast
Da geb ich dir teilweise recht, GCN hat jedenfalls mehr Potenzial (async compute bzw. compute allgemein), das aber dank der Marktsituation (der Grund warum ich AMD derzeit unterstützen will) nicht genutzt wird.
edit: Du hast ja doch ganz vernünftige Ansichten
bzgl. dass NV die Preise etabliert hat: teilweise ja, 599$ max sind jetzt 699$ (im Fall der Titan noch deutlich höher).
Es ist nur die Frage, was für Preise AMD verlangt, denn den CPU Markt haben sie sehr gut aufgemischt, außerdem kann Konkurrenzdruck die Preise doch recht ordentlich drücken, was aber seit Maxwell eben nicht mehr der Fall ist.
edit: Du hast ja doch ganz vernünftige Ansichten
bzgl. dass NV die Preise etabliert hat: teilweise ja, 599$ max sind jetzt 699$ (im Fall der Titan noch deutlich höher).
Es ist nur die Frage, was für Preise AMD verlangt, denn den CPU Markt haben sie sehr gut aufgemischt, außerdem kann Konkurrenzdruck die Preise doch recht ordentlich drücken, was aber seit Maxwell eben nicht mehr der Fall ist.
Zuletzt bearbeitet:
Na ja, das eine ist die aktuelle Marktsituation, das andere das Potential.
Fangen wir bei der alten C/C++ Sprache an, die laut Computersprachexperten elendig ineffizient sein sollen.
Dann die ollen alten Instruction Sets, die auch längst überholt sind und durch elegantere Sachen wie ARM ersetzt werden könnten. (Auch die Russen haben mal vor ein paar Jahren ne CPU mit unglaublicher IPC gebastelt)
Dann können wir da drauf noch die ganzen Sachen aus den Betriebsystemen schmeißen, die auf Grund von Historie noch rumgammeln.
Dann ein neues Systemdesign um die ganzen Flaschenhälse rauszuwerfen und zum Schluss optimierte Software da drauf.
Macht nur keine Sau, weils niemand kaufen würde. Ohne Windows - mööp. Ohne X86 - mööp. Ihr versteht schon...
So - was hat das ganze mit dem Thema zu tun? Ganz einfach: AMD haut regelmäßig tolle neue Technologien raus, die kaum eine Sau nutzt. WENN sie aber mal genutzt wird, geht sie ab wie Nachbars Katze.
Mir tut AMD da ein wenig leid. Die treiben mit ihrem Einkommen an der roten Linie so viel Innovation, dass Nvidia und Intel eigentlich rot vor Scham werden müssten. Werden sie aber nicht, weil die "Kunden" halt immer den gleichen Mist kaufen.
/rant
edit: Hab die "Moral von der Geschichte" vergessen. Kurz: Wenn die Softwareentwickler OpenCL benutzen würden, könnte AMD in den Rechenzentren ne Menge erreichen. Aber seit über 10 Jahren gibts nur CUDA, CUDA und wieder CUDA.
Fangen wir bei der alten C/C++ Sprache an, die laut Computersprachexperten elendig ineffizient sein sollen.
Dann die ollen alten Instruction Sets, die auch längst überholt sind und durch elegantere Sachen wie ARM ersetzt werden könnten. (Auch die Russen haben mal vor ein paar Jahren ne CPU mit unglaublicher IPC gebastelt)
Dann können wir da drauf noch die ganzen Sachen aus den Betriebsystemen schmeißen, die auf Grund von Historie noch rumgammeln.
Dann ein neues Systemdesign um die ganzen Flaschenhälse rauszuwerfen und zum Schluss optimierte Software da drauf.
Macht nur keine Sau, weils niemand kaufen würde. Ohne Windows - mööp. Ohne X86 - mööp. Ihr versteht schon...
So - was hat das ganze mit dem Thema zu tun? Ganz einfach: AMD haut regelmäßig tolle neue Technologien raus, die kaum eine Sau nutzt. WENN sie aber mal genutzt wird, geht sie ab wie Nachbars Katze.
Mir tut AMD da ein wenig leid. Die treiben mit ihrem Einkommen an der roten Linie so viel Innovation, dass Nvidia und Intel eigentlich rot vor Scham werden müssten. Werden sie aber nicht, weil die "Kunden" halt immer den gleichen Mist kaufen.
/rant
edit: Hab die "Moral von der Geschichte" vergessen. Kurz: Wenn die Softwareentwickler OpenCL benutzen würden, könnte AMD in den Rechenzentren ne Menge erreichen. Aber seit über 10 Jahren gibts nur CUDA, CUDA und wieder CUDA.
Zuletzt bearbeitet:
besterino
Legende
Sorry Freunde, Volta ist auch eine ganz andere Architektur. NVidia hat da massiv geschraubt. Schaut mal in den/die Artikel bei anandtech oder Heise dazu rein - lohnt sich.
Nur hat das eben an der Stelle primär nichts mehr mit einer Pixelschleuder zu tun. Und teuer ist das überhaupt nicht, wenn man sich den Vergleich einmal anschaut: wenn ich mit einer Kiste für die speziellen Workloads 500 Xeon-Server ersetzen kann, ist der Preis ein Witz - und das nur bei der Anschaffung. Da haben wir von Strom, Kühlung und sonstiger Infrastruktur noch gar nicht gesprochen. Und nein, ich bin kein Fanboi - aber man muss das Ganze eben ins Verhältnis und aus Sicht der Zielgruppe (Datacenter/spezifische Anwendungen)sehen um zu verstehen, was für ein gigantischer Sprung Volta ist/sein kann.
Aber: für Spieler könnte Volta mal schlappe 50% schneller als eine 1080TI sein (laut Heise Berichterstattung - bei der Session vor Ort dazu konnte ich leider selbst nicht mehr dabei sein). Soviel zum Thema nur "Pascal in groß"...
Nur hat das eben an der Stelle primär nichts mehr mit einer Pixelschleuder zu tun. Und teuer ist das überhaupt nicht, wenn man sich den Vergleich einmal anschaut: wenn ich mit einer Kiste für die speziellen Workloads 500 Xeon-Server ersetzen kann, ist der Preis ein Witz - und das nur bei der Anschaffung. Da haben wir von Strom, Kühlung und sonstiger Infrastruktur noch gar nicht gesprochen. Und nein, ich bin kein Fanboi - aber man muss das Ganze eben ins Verhältnis und aus Sicht der Zielgruppe (Datacenter/spezifische Anwendungen)sehen um zu verstehen, was für ein gigantischer Sprung Volta ist/sein kann.
Aber: für Spieler könnte Volta mal schlappe 50% schneller als eine 1080TI sein (laut Heise Berichterstattung - bei der Session vor Ort dazu konnte ich leider selbst nicht mehr dabei sein). Soviel zum Thema nur "Pascal in groß"...
Zuletzt bearbeitet:
Jupp - gelesen und für gut befunden. ^^ Zu mindest für die vorgestellten Anwendungen. :=
Genau da sind wir bei meinem oben genannten Beispiel. Da kauf sich ein Unternehmen lieber 500 Xeons anstatt einfach mal nen Coder hinzusetzen, der die Schnittstelle OpenCL-fähig macht. Die geben lieber mehrere Millionen für nen ineffizienten Cluster aus (relativ gesehen), anstatt mal einmal Butter bei die Fische zu machen und das ordentlich zu implementieren.
Die Rohleistung der GPUs ist auf beiden Seiten - sowohl Nvidia als auch AMD enorm. Nur gammelt die Industrie halt noch auf Kartoffelniveau mit ihren ranzigen Anwendungen, die "historisch" gesehen nur CUDA oder noch nicht einmal das können. Ich hab da mit den Leuten, die sich 500 Xeons anschaffen ehrlich gesagt kein Mitleid. Mein Kollege macht Deep learning auf ner Titan und er ist der einzige in dem Uni-Laden, der das halbwegs ordentlich programmieren kann. Der Rest sitzt wie ne Kartoffel vor dem Ding und lässt es lokal auf CPU rechnen, weil die sich NULL damit auskennen. (Woher auch... werden ja nur noch Fachidioten ausgebildet)
Da wurden 4 Titans für ein Projekt gekauft und so eingebaut, dass die erste die zweite aufheizt und die zweite die dritte etc... die laufen schon 2 Minuten nach Start kurz vorm Wärmetod und keine Sau interessierts - aber hauptsache man hat 4 Titans. Nee - Volta ist zwar ne schöne Sache, aber wenn man da mal richtig arbeiten würde, hätte man da auch schon mit den AMD Karten vor 10 Jahren ordentlich rechnen können. Wollte nur niemand sein Personal darauf bilden bzw. jemanden dafür einstellen, das auch nur einmal richtig zu machen - aber Personal ist ja angeblich teuer. Statt dessen wurden Millionen Euros (die dann auf einmal wieder locker waren) für ineffiziente Cluster rausgeschmissen.
Ja, für die paar Unternehmen die nicht den Cluster wie ne Brapfanne benutzen mag Volta tatsächlich ne sehr feine Sache sein. Beim Rest machts keinen Unterschied und läuft so derpig wie bisher weiter.
Hab grad schon im anderen Thema dazu mal gepostet. Die Shaderanzahl an sich macht schon 42% aus... marginal mehr Takt und du bist bei 50%. ^^
Für ne Pixelschleuder brauche ich aber keine 810 mm[SUP]2[/SUP] - da glaub ich, wird Vega die bessere P/L-Wahl.
Wie genau meinst du das?
Ineffizient, weil komplizierter(kein Garbagecollector, Mehrfachvererbung, usw.) und zeitintensiver (z.B. class und Header Datei erstellen) oder ineffizient bei der Leistung?
Falls ersteres, ja schon irgendwie, aber falls letzteres ehr nein ^^
Zuletzt bearbeitet:
Beides. ^^ Hab mal einen langen Artikel darüber gelesen, wie C entstanden ist und wie dumm/ineffizient es eigentlich ist. Es ist bis heute eines der schnellsten Werkzeuge, was eigentlich ein Armutszeugnis darstellt. Leider find ich den Artikel auf die Schnelle nicht (schon ein paar Jahre her) - aber es begann mit einem Review, wie C entstanden ist und warum und welche Sachen da schon schief gelaufen sind - auch aus Performance-Sicht.
Deswegen sag ich ja, das wir generell mal so langsam was "neues" brauchen. Neue Programmiersprache (schnell und gut), neue Instruction sets, neues alles was nur aus Kompatibilitätsgründen noch mitgeschliffen wird.
Nur das wird halt nicht passieren. Kein Unternehmen setzt sich ein selbst zusammenkompiliertes Stück Hard+Software zusammen. Der Kunde will halt word/flash/excel.
besterino
Legende
Stimmt schon, die breite Masse kennt sich damit nicht aus. Aber das ist ja das Gute für diejenigen, die sich damit wirklich mal in der Tiefe beschäftigen: Wettbewerbsvorteil.
Wenn man dann noch etwas genauer zugehört hat, dann sieht man auch die Anstrengungen, die NVIDIA (nicht uneigennützig) unternimmt, um die Technik massentauglich zu machen. Die wollen dieses Jahr 100.000 Leute schulen (im Vergleich zu 10.000 Plätzen in 2016) und bringen eine ganze Plattform, mit denen du die ganzen Frameworks über Container per Click ans laufen bringst, und das bereits optimiert für GPUs Lokal auf Titan, DGX-1(V) oder eben scale-out in der Cloud. Brauchst dann "nur" noch die entsprechend aufbereiteten Daten... (wohl noch das fast größere Problem).
Ich bin jedenfalls mit leuchtenden Augen nach Hause gefahren und werde selbst als "DAU" der ich bin, damit anfangen zu spielen - die Einstiegshürden sinken kontinuierlich, denn die Spezis haben erkannt, dass die immer noch zu hoch sind, um das Potenzial wirklich abzuschöpfen.
Im Übrigen bauen aber die ganzen großen Cloudprovider ganze "Rackstraßen" mit den Dingern, eben weil viele Interessierte (noch) keine Lust haben, sich sowas selbst hinzustellen. Die Nachfrsge ist ein offenbar da, sonst wären Amazon mit AWS und Microsoft mit Azure kaum mit auf der Bühne bei der Keynote gewesen und hätten Volta-Hardware in ihren Cloudangeboten angekündigt.
Schöne neue Welt.
Wenn man dann noch etwas genauer zugehört hat, dann sieht man auch die Anstrengungen, die NVIDIA (nicht uneigennützig) unternimmt, um die Technik massentauglich zu machen. Die wollen dieses Jahr 100.000 Leute schulen (im Vergleich zu 10.000 Plätzen in 2016) und bringen eine ganze Plattform, mit denen du die ganzen Frameworks über Container per Click ans laufen bringst, und das bereits optimiert für GPUs Lokal auf Titan, DGX-1(V) oder eben scale-out in der Cloud. Brauchst dann "nur" noch die entsprechend aufbereiteten Daten...
(wohl noch das fast größere Problem).Ich bin jedenfalls mit leuchtenden Augen nach Hause gefahren und werde selbst als "DAU" der ich bin, damit anfangen zu spielen - die Einstiegshürden sinken kontinuierlich, denn die Spezis haben erkannt, dass die immer noch zu hoch sind, um das Potenzial wirklich abzuschöpfen.
Im Übrigen bauen aber die ganzen großen Cloudprovider ganze "Rackstraßen" mit den Dingern, eben weil viele Interessierte (noch) keine Lust haben, sich sowas selbst hinzustellen. Die Nachfrsge ist ein offenbar da, sonst wären Amazon mit AWS und Microsoft mit Azure kaum mit auf der Bühne bei der Keynote gewesen und hätten Volta-Hardware in ihren Cloudangeboten angekündigt.
Schöne neue Welt.
(schon ein paar Jahre her)
Die Compiler wurden mit der Zeit aber auch immer weiter verbessert und werden immer weiter verbessert, sodass diese den Code immer besser optimieren.
Und C/C++ sind nicht die schnellsten Werkzeuge, denn dies ist Assembler (Ok um ganz genau zu sein Maschienencode). Also wenn du wirklich die bestmögliche Performance haben willst, dann werde ein Assembler Guru, nicht einfach nur jemand der Assembler programmieren kann, sondern wirklich ein Guru, sodass du in der Lage bist, besseren Assembler Code als der Compiler zu erstellen
Mit Assembler hast du auch die Möglichkeit alle Features und alles Instructions der CPU direkt anzusprechen, aber dafür musst die Hardware wirklich genauestens kennen, um diese perfekt nutzen zu können. Und du verlierst die ganzen Vorteile der High-Level Programmiersprachen, sodass du deinen Code für jede CPU neu anpassen und optimieren musst, also richtig schön Low-Level Shit 
Die Compiler wurden mit der Zeit aber auch immer weiter verbessert und werden immer weiter verbessert, sodass diese den Code immer besser optimieren.
Und C/C++ sind nicht die schnellsten Werkzeuge, denn dies ist Assembler (Ok um ganz genau zu sein Maschienencode). Also wenn du wirklich die bestmögliche Performance haben willst, dann werde ein Assembler Guru, nicht einfach nur jemand der Assembler programmieren kann, sondern wirklich ein Guru, sodass du in der Lage bist, besseren Assembler Code als der Compiler zu erstellen
Mit Assembler hast du auch die Möglichkeit alle Features und alles Instructions der CPU direkt anzusprechen, aber dafür musst die Hardware wirklich genauestens kennen, um diese perfekt nutzen zu können. Und du verlierst die ganzen Vorteile der High-Level Programmiersprachen, sodass du deinen Code für jede CPU neu anpassen und optimieren musst, also richtig schön Low-Level Shit
Zuletzt bearbeitet:
besterino
Legende
@Paddy92: wobei sich da schon die Frage aufdrängt, ob das wirklich kosteneffizient auf "Anwender-/Entwicklerseite" ist und man nicht einfach in 10% "mehr" Hardware investiert als darauf zu wetten, dass da einer mal eben x% Performance durch Optimierungen auf Assembler-Level rausholt. Die Hardware kennen heutzutage doch wahrscheinlich nur die Chiphersteller selbst gut genug (die zufälligerweise ja auch die Compiler basteln/optimieren). Nicht falsch verstehen: die Antwort darauf weiss ich gar nicht.
Ich würde mal sagen, dass lohnt i.d.R. nicht, da du es ja dann für jede Hardware machen musst, aber nicht einfach nur Hersteller übergreifend, also für die CPUs von Intel und AMD, sondern auch für die einzelnen Generationen, mal mehr, mal weniger
Zuletzt bearbeitet:
besterino
Legende
Eben. Und genau da setzt doch auch CUDA an. Die Kunst ist eben, eine in sich stimmige Plattform hinzustellen, die sich möglichst ohne vertiefte Kenntnisse "bestmöglich" und von Haus aus optimiert einsetzen lässt. Und da trennen - in diesem Bereich - AMD und NVIDIA momentan Welten (jedenfalls in meiner Wahrnehmung). NVIDIA baut inzwischen hier eben nicht nur Hardware, sondern schafft auch faktisch die Voraussetzungen für ganz neue Märkte. Über CUDA hinaus geht's jetzt an die DL-Frameworks wie Tensorflow, Caffe(2), CNTK & Co., die Dir NVIDIA zusätzlich zu den CUDA-Libraries frei Haus - natürlich nur für Ihre Hardware - hinstellt. Wenn's aufgeht: Hammer Alleinstellungsmerkmal. Wenn nicht: Hammer Fehlinvestition.
Zuletzt bearbeitet:
(schon ein paar Jahre her)
Die Compiler wurden mit der Zeit aber auch immer weiter verbessert und werden immer weiter verbessert, sodass diese den Code immer besser optimieren.
Und C/C++ sind nicht die schnellsten Werkzeuge, denn dies ist Assembler (Ok um ganz genau zu sein Maschienencode). Also wenn du wirklich die bestmögliche Performance haben willst, dann werde ein Assembler Guru, nicht einfach nur jemand der Assembler programmieren kann, sondern wirklich ein Guru, sodass du in der Lage bist, besseren Assembler Code als der Compiler zu erstellen
Warum funzt denn Code-Magie wie LLVM? Compiliert in einer Virtuellen Maschine auf ein Zielsystem, das gar nicht existiert um damit Performance rauszuholen, die der Programmierer gar nicht kannte, dass sie auf der Straße liegt. ^^
Natürlich wäre Assembler die beste Wahl - die Demo-Szene macht das ja und die schaffen es auf Hardware aus den 80'ern // frühen 90'ern in 64 kbyte oder 4 kbyte Sachen darzustellen, wo mir die Augen ausfallen, wie sowas überhaupt auf nem "Krüppelchip" möglich ist. Die Sache ist nur: Mit ner ordentlichen Infrastruktur hätte man diese Technik heute auf jedem System. Ich kann auch dynamisch programmieren, wo der Code sich auf die einzelnen Hardwareeigenschaften anpasst. Ist mein Cache 32 oder 64 kB groß? Je nachdem knall ich einen entsprechendend optimierten Datensatz rein (oder hier das System). Kann ich mit der ganzen Architektur machen bis ich einen totoptimierten Code habe.
Und jetzt stell dir mal vor, das lässt du auf sowas wie ner Titan laufen. Ich bin der festen Überzeugung, dass wir heute noch auf deutlich >50% overhead laufen.
Eben. Und genau da setzt doch auch CUDA an. Die Kunst ist eben, eine in sich stimmige Plattform hinzustellen, die sich möglichst ohne vertiefte Kenntnisse "bestmöglich" und von Haus aus optimiert einsetzen lässt. Und da trennen - in diesem Bereich - AMD und NVIDIA momentan Welten (jedenfalls in meiner Wahrnehmung). NVIDIA baut inzwischen hier eben nicht nur Hardware, sondern schafft auch faktisch die Voraussetzungen für ganz neue Märkte. Über CUDA hinaus geht's jetzt an die DL-Frameworks wie Tensorflow, Caffe(2), CNTK & Co., die Dir NVIDIA zusätzlich zu den CUDA-Libraries frei Haus - natürlich nur für Ihre Hardware - hinstellt. Wenn's aufgeht: Hammer Alleinstellungsmerkmal. Wenn nicht: Hammer Fehlinvestition.
Ich mag CUDA nicht, hauptsächlich weil es proprietär ist. Ich frag mal so: Warum nicht gleich OpenCL? Ist bei gleichem Entwicklungsaufwand der Softwarehersteller genauso schnell wie CUDA (evtl. sogar noch schneller), offen, wird aktiv weiterentwickelt, sehr flexibel und ist kompatibel mit Nvidia, Intel und AMD.
Warum wird das nicht gefördert? Warum kleben die Entwickler immer auf dem gleichen, alten Ramsch fest? Jetzt isses natürlich zu spät. CUDA ist schon längst überall drin, was GPU-Beschleunigung will und kein Hahn kräht mehr nach OpenCL. Ganz toll! *slow clap*
Zuletzt bearbeitet:
Was ist denn ein Glücksgriff für dich?
Mir stellt sich nämlich gerade die Frage, was "Glück" da an der Stelle ausrichten/beinflussen/ändern soll(te)? In der Industrie, und das sind/ist IT ebenso, gibts kein Glück.
Und irgendwie sieht es doch ganz klar danach aus, dass Maxwell genau dort liefern konnte, wo es NV gebraucht hat -> man erinnere sich an Kepler und die immer weiter abflachendere Performance, gerade in Games. Stichwort Tile based Renderer, Stichwort Bandbreitenbedarf usw.
Aber hier gehts eher um Profibereich aka HPC -> und auch dort war Kepler eher mau (nimmt man es genau), denn die Performance kam nicht so recht an. Schau dir dazu einfach mal auf den einschlägigen Portalen die Kommentare zum Thema GK110 vs. Hawaii an. Maxwell macht da eine ganze Menge besser. -> leider ohne FP64. Aber auch die Durststrecke bei NV bis zum GP100 hat AMD nicht nutzen können (oder nutzen wollen!?). Denn bis heute heist es bei AMD -> Hawaii oder Tahiti, wenn es um FP64 geht. Techniklevel von 2012-2013 und das in 2017!
Eigentlich hätte man hier schon aufhören müssen zu lesen -> 2x Passagen -> 2x daneben. Sorry, aber einfach mal solche Behauptungen unterlassen, wenn man sich wenigstens ansatzweise damit beschäftigt hat.
Vor allem, "laut Computersprachexperten" -> und dann kommt die Aussage, hab ich im INet gelesen, finde den Artikeln aber nicht mehr -> was soll das? Entweder du kannst Fakten bringen oder du machst dich lächerlich. Wäre die Aussage von "Sprachexperten" getroffen und vor allem auch, wären sich diese "Experten" ansatzweise einig, dürfte es ein leichtes sein, darüber Berichte/Aussagen/Blogposts oder was weis ich denn, zu finden...
PS: C++17 ist übrigens erst ein paar Monate alt...
Dann wäre ich doch dafür, du bewirbst dich bei den Unternehmen, lässt sich als Softwareentwickler einstellen und baust ein OpenCL Backend!? Dann haben auch alle was davon
Was ist da Magie dran!?
Hardware ist im Endeffekt von Menschen gebaut. Wieso sollte es also Magie sein, anstatt was "in die Hand" zu nehmen, es einfach virtuell zu erschaffen/erzeugen!?
Stell dir einfach vor du stehst voll auf Lego. Früher bist du in den Laden gerannt und hast die Teile gekauft. Heute kannst du dir einfach den Lego Digital Designer runterladen und Lego Sets virtuell auf dem PC zusammen bauen. Im Endeffekt ist es quasi exakt das gleiche. Stecke Stein auf Stein... Nichts anderes passiert hier in dem Fall ebenso. Der "Emulator" verhält sich exakt so wie der physische Prozessor. Und damit ist die Magie auch schon erklärt.
Ja warum wohl... Mal überlegen -> vielleicht weil es, als es released wurde, kein OpenCL gab!?
Vielleicht, weil sich der Hersteller hinter Cuda, jahrelang dafür eingesetzt hat, sein Produkt am Markt zu etablieren?
Vielleicht, weil es die Gegenpartei ebenso am Anfang mit einem Properitären Ansatz versucht hat -> AMD Stream -> und eine der beiden Ansätze scheitern musste...
Du fragst wirklich, warum ein Markt, der sehr sehr speziell ist, auf einen properitären Ansatz setzt, der mittlerweile eigentlich als Standard anzusehen ist? Und das nur, weil du Cuda nicht magst!?
PS: noch ein Hinweis, man muss Sachen nicht zwangsweise mögen um zu bewerten ob das was sinniges oder unsinniges ist. Und ganz zweifelsfrei darf man von Cuda halten was man will, dennoch WAR bzw. IST sogar noch DAS Zugpferd, was HPC mit GPU Beschleunigung angeht. Im Moment ist Intel im Kommen. Aber auch NV bringt immer mal wieder gute Ansätze/Neuigkeiten. Ebenso wird sich wohl der Markt früher oder später weiter untergliedern. Wie man jetzt schon sieht. Im Moment ist Deap Learning im Fokus. Mit teils anderen Anforderungen als bspw. in der Wettersimulation oder Atomphysik oder Astronomie oder auch in der Forensik...
Wieder so ne Behauptung... Die neuesten Cuda Versionen sind alles Andere als "alter Ramsch"...
Und es ist NIE zu spät für eine Technik in der IT, wenn es dafür einen Markt gibt. Mit rumheulen in der Community wird sich am Markt aber genau NULL ändern
Also los, geh mit gutem Beispiel vorran und portiere den Stuff auf OpenCL
Für Umme natürlich, denn das ist ja das, was du aus Endkundensicht willst...NVIDIA baut inzwischen hier eben nicht nur Hardware, sondern schafft auch faktisch die Voraussetzungen für ganz neue Märkte. Über CUDA hinaus geht's jetzt an die DL-Frameworks wie Tensorflow, Caffe(2), CNTK & Co., die Dir NVIDIA zusätzlich zu den CUDA-Libraries frei Haus - natürlich nur für Ihre Hardware - hinstellt. Wenn's aufgeht: Hammer Alleinstellungsmerkmal. Wenn nicht: Hammer Fehlinvestition.
Das Problem ist, die Leute, die mit Softwareentwicklung mit GPU Support nichts am Hut haben, wollen sowas gar nicht verstehen. Geschweige denn, dass man sowas nachvollziehen kann... Siehst du bspw. auch schön am Thema Gameworks. Da ist es im Endeffekt die gleiche Suppe in bunt nur nicht HPC, sondern eben Gaming. Es ging in der Industrie aus meiner Sicht noch nie um irgendwelche Sympatien. Das ist knallhartes Geschäft. Und wer nicht mitzieht, wo das Produkt nicht punktet, wo es irgendwo krankt oder was weis ich -> der wird eben hinterher laufen oder irgendwann untergehen. Es hat schon viele der damaligen Größen im IT Geschäft getroffen. Offenbar ist Cuda ein Erfolgsrezept für NV. Wenn auch der Anteil am Umsetz nach wie vor recht gering ist... Aber offenbar hat es gereicht um eine etablierte Größe zu werden.
Zuletzt bearbeitet:
RAZ0RLIGHT
Enthusiast
@fdsonne, beachte doch einfach mal das Kapital und welche Märkte die Firmen bedienen.
oh ich vergaß das interessiert den ICH-bezogenen Kunden ja nicht.
oh ich vergaß das interessiert den ICH-bezogenen Kunden ja nicht.
besterino
Legende
@fdsonne: ich glaub, wir sind uns da völlig einig.
@RAZ0RLIGHT: naja, als "Kunde" ist man doch per se ichbezogen. Sonst hieße es ja Spender ... (selbst ein Sponsor - obwohl nah dran - gibt aus Eigennutz Geld aus). Das finde ich nicht verwerflich.
@RAZ0RLIGHT: naja, als "Kunde" ist man doch per se ichbezogen. Sonst hieße es ja Spender ... (selbst ein Sponsor - obwohl nah dran - gibt aus Eigennutz Geld aus). Das finde ich nicht verwerflich.
RAZ0RLIGHT
Enthusiast
Da gibt es aber mehr als Schwarz Weis
Och, ich hab mich schon damit beschäftigt. Nur kann ich dir deine Vorurteile nicht abnehmen.
Es war ein recht bekannter Eintrag, der vor mehreren Jahren auch auf anderen Blogs re-gebloggt wurde und auch in einigen Foren diskutiert wurde. Google hat mir zwar einen Link ausgespuckt, der führte aber zu einer 404 - leider. Deswegen hab ich den Artikel kurz beschrieben in der Hoffnung, jemand anderes möge sich auch daran erinnern und hat vielleicht eine Idee, wo ich es wieder finden würde.
Nun ja, die Person hat ziemlich eindrucksvoll gezeigt, dass C doch nicht die schnellste Programmiersprache ist und hat zu mindest mich davon überzeugt, dass C zur Zeit zwar mit die schnellste Sprache ist - relativ gesehen, absolut aber doch leider nur mittelmäßig ist. Na ja, ohne Link kannst du mir das entweder einfach nur glauben (ja, ist doof) oder auch nicht.
Wie gesagt, der Originalartikel existiert nicht mehr und Google spuckt zwar einiges zu "program, rant, C, language" aber da wird mir ansonsten nur was von Linus ausgespuckt. Und hunderte weiterer Blogs. Nun ja, Pech.
Joar, schön. Ich bezog mich aber eher auf das Gesamtpaket wie X86, C/C++, historisch mitgeschliffene Befehlssätze und allgemein mitgeschleppten Ballast, der alles langsam, ineffizient und träge macht. Gibt halt einen Grund warum es Vulkan gibt.
Hätte ich ne entsprechenden Karrierepfad gewählt, würde ich das sogar machen.Dann wäre ich doch dafür, du bewirbst dich bei den Unternehmen, lässt sich als Softwareentwickler einstellen und baust ein OpenCL Backend!? Dann haben auch alle was davon
Aber das ist ja kein echtes Gegenargument. Warum die Leute von Mathworks CUDA implementiert haben anstatt OpenCL kann mir bis heute niemand ordentlich erklären. Da kommen dann nur so schlaue Sprüche wie "Machs doch selbst!"
Für ne Software, die locker über 10k Euro kostet ist das halt ziemlich bescheiden - aber ist ja nicht mein Geld. Genauso wenig wie so ein Datenzentrum mit 500 Xeon CPUs anstatt 5 GPUs.
Wenn ich meinen Code für Nintendo DS compiliere, wird der wohl kaum auf PowerPC laufen. Genau hier ist ja die Magie von LLVM. Du compilierst gegen ein virtuelles System, das "irgendwas" ist aber nicht die Maschine, auf der es später laufen soll und es läuft trotzdem und wahnsinnig schnell. Du tust hier ja so, als wäre das selbstverständlich. Ich find LLVM ist ein ziemlich alienhaftes Stück Technik ähnlich wie jpeg. Das existiert auch schon 15+ Jahre lang und ist immer noch ungeschlagen. Aber das ist nur meine Meinung.
Ähm...
Matlab gibts seit 1984, CUDA seit 2007. Open CL seit 2008. Wir haben jetzt 2017 - also genügend Zeit ist da gewesen und die zeitliche Differenz ist aus heutiger Sicht vernachlässigbar. Aber eh egal - OpenCL ist für die meisten Anwendungsgebiete komplett verdrängt worden. Total toll!
Ja, genau das. Nvidia hat überall versucht CUDA reinzukloppen wo es nur ging um damit die Software nur auf Nvidia Karten laufen zu lassen. Damit verdient Nvidia natürlich ordentlich Geld durch eine künstliche Restriktion der Softwarefähigkeit. Erzähl mir doch bitte mal, was daran so toll ist?
Was hat das mit OpenCL zu tun? Na ja, egal - ist eh zu spät dafür. Gibt ja nix mehr außer CUDA.
Ja tue ich, weil CUDA eine künstliche Restriktion ist, die niemand braucht. Hätten die "Implementierer", die CUDA seit 10 Jahren benutzen OpenCL verwendet, würde jetzt kein Hahn mehr nach CUDA krähen. Hätte Matlabn OpenCL anstatt CUDA eingebaut - so als Beispiel. Haben sie aber nicht, weil.... Gründe. Zu offen oder einen Bienenstock im Popo oder was auch immer die für Probleme damit haben.
Wie gesagt, das könntest du auch alles mit OpenCL machen - teilweise sogar besser, weil es flexibler ist. Aber der Mensch mag historisch gewachsenen Bullshit, also haben wir jetzt alle CUDA.
Ich hab nix gegen GPU-Berechnungen, ich hab was gegen Steine die grundlos im Weg liegen. Du kannst den Stein bunt anmalen, parfümieren und ihm einen netten Namen geben - ändert aber nix daran, dass er immer noch sinnlos im Weg rumliegt.
Wieder so ne Behauptung... Die neuesten Cuda Versionen sind alles Andere als "alter Ramsch"...
Und es ist NIE zu spät für eine Technik in der IT, wenn es dafür einen Markt gibt. Mit rumheulen in der Community wird sich am Markt aber genau NULL ändern
Also los, geh mit gutem Beispiel vorran und portiere den Stuff auf OpenCL
Zum Glück hat AMD da schon drauf reagiert und ich muss das nicht mehr machen - für Umme.
CUDA-Code rein, kurz warten, auf AMD-Karten ausführen. Ist natürlich total Banane so einen weg zu gehen, aber wir wollen es ja alle so.Jupp - ist halt genauso in der Uni gewesen. Die Leute knallen sich einen Cluster für mehrere Millionen zusammen und genau 3 Leute können ihn bedienen. Der Biologie-Student der noch nie programmiert hat darf dann die Protein-Faltung programmieren "lassen", hat selbst aber null Plan von dem Code, der da grad entsteht. Warum auch? Er ist Biologe.
Hier jetzt zu sagen, dass "er das mal schön selbst zusammencoden" soll ist ein wenig... arrogant, oder? Aber so ein dummer Student kann halt im Rinnstein verrecken, so lange es für irgendwelche Bullshitprojekte noch Fördergelder gibt.
Jupp, hast du absolut recht mit. Sollte dir aber auch die Problematik aufzeigen: Leute, die kaum Geld haben und deswegen abhängig sind können sich nicht aussuchen die "bessere" Alternative zu wählen. Die müssen fressen oder sterben. Und was da so auf dem Tisch kommt, ist nicht sehr angenehm.
Zuletzt bearbeitet:
Weil LLVM Hexerei benutzt!!!!!
Nein Spaß beiseite
Diese "Magie" ist eine VM mit JIT-Compiler (Just-in-Time), ähnlich wie bei Java mit der JVM. Durch den JIT-Compiler werden Programme zur Laufzeit kompiliert und dies ermöglicht ein "lazy-loading", d.h. es wird nicht alles kompiliert, sondern nur das, was auch benötigt wird. Auch hat der Compiler Informationen wie es aktuell in der Hardware aussieht, sodass z.B. der Code so optimiert wird, dass eventuelle Cache misses reduziert werden, welche viel Performance kosten.
Ps: Bin gerade etwas unter Zeitdruck :P
besterino
Legende
Freunde, ich bitte um Entspannung. Hier geht's doch nicht um hätte hätte Fahradkette oder OpenCL vs CUDA oder was auch immer. Fakt ist, NVIDIA bringt hier für Volta neue, optimierte Libraries, Container und eine Cloud-/KonfigurationsUI mit, die die Verwendung der Hardware für einen bestimmten Zweck nunmal recht einfach macht. Das kann man finden/bedauern wie man will, aber der arme Biologiestudent (oder in dem Fall wohl eher Mathematik- oder Informatikstudent) muss eben gerade nicht mehr rein und irgendwie groß rumcoden oder Treiber und Libs Konfigurieren, sondern kann direkt mit dem loslegen, was er eigentlich machen wollte/sollte. Die Zeit, die da bisher verplempert werden musste, um das überhaupt ans laufen zu bekommen, haste dann locker wieder drin selbst wenn dass "theoretisch" auf einer anderen Plattform mit schlechterem Drumherum-Support was besser fluppt. Mal ganz zu schweigen, wenn du mit mehreren Frameworks parallel experimentieren willst.
Zuletzt bearbeitet:
Nein, im Gegenteil... Du wertest doch über Cuda, sagst es gefällt dir nicht, obwohl du die technische Basis das einschätzen zu können gar nicht mitbringst!? Also musst du dir auch die Kritik gefallen lassen, die man dir dann entgegenbringt.
Den Vergleich mit dem Studenten finde ich da sogar recht passend, aber aus einer etwas anderen Sicht.
Denn der Biologiestudent wird sich bestimmt nicht hinstellt und seinen Mitstudenten da Vorwürfe machen, warum die Cluster mit Software xyz laufen und nicht abc. Oder Schnittstelle 123 genutzt wird anstatt 987. Dem Biologen ist es doch gar nicht seine Aufgabe, Programmcode zu schreiben -> der soll machen, was ein Biologe eben macht (kein Plan, ich bin kein Biologe) -> aber Programmieren gehört da definitiv nicht dazu...
Das Problem ist nämlich, du machst es dir zu einfach. Für dich als Außenstehender ist das nämlich alles kein Problem. Du sagst, macht halt OpenCL, ist weitestgehend Hardwareunabhängig (entgegen Cuda). Aber das WIE erschließt sich dir überhaupt nicht. Du kannst weder einschätzen, was da für Aufwände dahinter stehen, ob Schnittstellen so weiter funktionieren. Ob der Speed passt. Ob Bibliotheken, die man nutzt (vllt gar von Dritten), ebenso mit OpenCL nutzbar sind/wären usw. usf.
Wie bspw. besterino eben aufgeführt hat, da ist auch bei Cuda noch eine Menge "Luft" -> und man liefert dort einfach immer wieder immer was neues. Das gilt für andere Themen ebenso, aber es macht damit das eine oder andere definitiv nicht obsolet.
Das eigentlich interessante ist hier aber "weil.... Gründe". Denn genau das versuche ich dir da oben zu erklären. Die Gründe sind die, warum das eine oder das andere eben genutzt wurde. Das du das als Endkunde vielleicht nicht nachvollziehen kannst/willst/möchtest ist ja OK. Aber wie du deine Gründe hast, Cuda scheiße zu finden, haben andere ihre Gründe, doch darauf zu setzen.
Ernst gemeinte Frage, wer definiert, wer recht hat!? Warum nimmst du dir das Recht raus deine Meinung über Cuda über die der Softwareentwickler zu stellen!? Das ist irgendwie verkehrte Welt. Denn genau das, das dir jemand was vorsetzt, ist doch der Kernpunkt der Kritik!? Aber das gleiche versuchst du gerade zu erzwingen, indem sich alle nach dem von dir genannten Produkt richten sollen, ohne wenn und aber. Denn die Gründe interessieren dich ja nicth (siehe: "weil.... Gründe")
Macht er doch auch nicht... Es kommt ein Code für den DS raus. Und der läuft auch auf dem DS. Und zusätzlich, wenn gewünscht eben auch auf dem quasi virtuellen DS mit idR recht schneller Hardware.
Nach deinem Argument dürfte man Software nur auf Hardware schreiben/ausführen/entwickeln, auf der sie gemacht wurde. Stellt sich nur die Frage -> wie programmierst du die Hardware ohne Software? Denn die gibts ja noch nicht, da sie lauffähige Hardware vorraussetzt. Merkste was!?
Das ist in etwa das, was wir die Tage schonmal hatten... Mir schenkt keiner was. Dir idR auch nicht? Firmen am Markt ebenso nicht.
Da gibst eigentlich ausschließlich die ICH Ansicht. Die Wohlfahrt mal ausgeklammert...
Strohmann hilft dir da auch nicht weiter lieber Sonnenschein. OpenCL kann alles was CUDA kann und noch etwas mehr. Ich warte immer noch auf das Argument FÜR CUDA.
Soweit völlig korrekt. Er ist ein Biologe, kein Programmierer. Ich bin Ingenieur für Signalverarbeitung und kein C/C++ Hacker. Ich bastle Prototypen. In meinem Bereich gibts aber auch einige Kollegen, die Machine-Learning machen sollen. Und auf einmal kommen Leute an, die dann verlangen, dass wir auch C/C++ können sollen.
Gut, kann man verlangen, verfehlt aber völlig das Ziel. Ich als Systementwickler will mich mit dem ganzen Zeug eigentlich gar nicht auseinandersetzen, ich pack meinen Prototypen-Code in Matlab und guck mir die Ergebnisse an.
Und jetzt kommt das eigentliche Problem: Ich MUSS, wenn ich beispielsweise in Matlab einen Machine-Learning algo verwenden will entweder die CPUs verwenden (ist okay, dauert halt nur einen ganzen Tag) oder wenn ich die GPU benutzen will, CUDA benutzen. Das allein wäre auch kein Problem mit ner AMD-Karte, weil AMD ja den CUDA-Code übersetzen kann. Matlab hingegen kann das nicht. Und schon steckst du direkt in der braunen Grütze, dass du ne Nvidia Karte brauchst und du dein AMD-System unter Matlab vergessen kannst. Warum? Weil Marktmacht von Nvidia.
Deswegen mag ich CUDA nicht. Verstanden?
Muss ich auch nicht weil es die verdammte aufgabe von Mathworks gewesen wäre diese Schnittstelle zu coden - nicht meine. Mein GPU-Code wäre NULL Unterschiedlich in Matlab, egal ob CUDA oder OpenCL. Denn Matlab kümmert sich darum, den Proto-Code in Maschinencode für die GPU umzuwandeln, nicht ich.
Henne und Ei. Hätte Mathworks mit OpenCL angefangen, wären jetzt auch alle Plugins OpenCL.
Mich würde neben "Marktmacht" und der daraus resultierten Verbreitung mal interessieren, was an CUDA besser sein soll. X86 existiert ja auch nur noch wegen der allg. Verbreitung und nicht weil es so toll ist.
Recht einfach: Wenn ich mir ein auto kaufe, will ich auch nicht vorgeschrieben bekommen nur bei einer bestimmten Tanke tanken zu dürfen. So lange der Sprit korrekt ist, isses egal wo ich tanke. Kannst du hierauf übertragen:
Ich kaufe mir ein großes, teures Programm zur Erstellung von Prototypen und werde dann auch noch gezwungen, nur Nvidia zu nehmen. Vielleicht will ich das gar nicht? Vielleicht hat AMD in einem bestimmten Anwendungsfall ja mal einen Vorteil gegenüber Nvidia? In einem anderen Fall Nvidia über AMD und dann hab ich mal wieder einen Anwendungsfall für Intels Grafikbeschleuniger. Who knows? Matlab kann nicht sagen, was ich proggen will. Was Matlab mit CUDA aber macht, ist mir vorzuschreiben, was ich zu verwenden hab, mit all den damit verbundenen Nachteilen.
Ich gebe also (theoretisch) sehr viel Geld für eine Software aus, die mir dann auch noch ins eigene Fleisch schneidet. Das ist unprofessionell.
Ja dann nenne mir doch mal einen Grund FÜR CUDA. Es ist eine limitierte Sprache die nur begrenzt auf Hardware läuft mit einem begrenzten Anwendungsbereich - im Gegensatz zu OpenCL. Einzig das coden in CUDA vs. OpenCL ist unterschiedlich - ja. Das machen dann aber auch Informatiker - also die Leute, die sich damit auskennen sollten!
Wo ist das Argument?
Nope - ich sagte, dass man die passende Infrastruktur ohne Ballast erschaffen sollte, damit wir das overhead-Problem los werden. Overhead ist doof. Soweit klar?
Assembler. xD
Spaß bei Seite - es geht darum "nah ans Metall" zu kommen - ohne künstliche Schranken und Steine. Ich verstehe nicht, was du dagegen hast. Aber das hier entwickelt sich sowieso langsam in eine Schlammschlacht. *seufz*
Es geht hier auch nicht ums schenken, sondern um künstliche Schranken. Aber der Punkt ist sowieso nur noch theoretisch, da ja wie gesagt OpenCL praktisch tot ist. Da kann man nur noch resignieren und hofft darauf, dass das Übersetzungs-Plugin von AMD für CUDA den Rest übernimmt und frisst dann halt. Einen Vorteil hat die ganze Sache: Jetzt, wo die ganze Infrastruktur um CUDA herum gebaut ist, braucht es für AMD Karten auch nur noch dieses kleine plugin und dann kann ich auch auf AMD-Karten rechnen lassen.
Es ändert aber nix an meinem Code, es ändert nix an der Leistung, es ändert nix am Ergebnis - nur hat der Compiler weniger Möglichkeiten zu optimieren, weil Matlab es so will. Gründe dafür suche ich immer noch.
Ähnliche Themen
[User-Review]
LG gram 17 17Z90S-G.AA78G
