Hat jemand einen link, wie man schnell in CUDA einsteigen kann?
wikipedia war für mich immer ein ganz guter Anlaufpunkt. google.de soll auch ganz gut sein, hab ich aber bisher nicht ausprobiert, ist mehr so ein Geheimtipp
Hi, Andreas schrieb: > schnell Schnell und CUDA gilt meines Erachtens nach nur fuer die Ausfuehrungsgeschwindigkeit. Es dauert einfach seine Zeit, bis die Konzepte der Parallelprogrammierung verinnerlicht sind, da es vom Ansatz komplett anders ist, als die "normale" lineare Programmierung. Ohne echte Parallelitaet und auf dieses Konzept ausgerichtete Algorithmen verblaest die GraKa einfach masslos Energie ohne entsprechende "Gegenleistung". Mir hat als Einstieg das Buch "Programming Massive Parallel Processors" and "CUDA by Example" gut geholfen. Eventuell findet sich in Google Books ein Abzug oder irgendjemand hat das ganze als gescanntes PDF ins Netz gestellt. Nach Durcharbeit der beiden Buecher fuehle ich mich nun ziemlich sicher im Umgang mit CUDA und Parallelalgorithmen (okay, das Informatik-Studium hat zu letzterem auch seinen Beitrag geleistet). Aber ich kann mich "nemo" nur anschliessen... Gruesse, TommyS
Ich würde gleich OpenCL nehmen, da es herstellerunabhängig ist, bzw. ich hab das so gemacht. Tommy hat aber Recht. Das ganze steht und fällt mit massiv parallelisierbaren Aufgaben. Wenn du die nicht hast, bringt dir das ganze überhaupt nichts.
Also ich habe mit der ganzen Geschichte ohnehin ein Problem, da die Grundargumentation der GraKa-Nutzung ja die ist, dass sie aufgrund der grossen Verbreitung so billig sind und sich trotz der umständlicheren Programmierung und des zusätzlichen Datentransferaufkommens noch rechnen. Der Denkfehler, den viele dabei machen: Nur die billigen Grafikarten haben eine derart grosse Verbreitung, dass die Rechenleistung je Euro so gewaltig gut ist. Sobald man da über die 50,- oder 100,- Euro kommt, wird der Markt für die Karten wieder enger und die Verbreitung geringer, zumal die Chips immer besser werden und schon die Mainboards nicht nur Office- sondern auch schon Workstation-Apps absorbieren. Damit braucht keiner mehr einfache oder mittelmässige Grafikarten, die man sich als Zusatzteil zweckentfremdend in den Rechner stecken kann. Die "rechnenden Karten" werden in einem eigenen Marktsegement immer spezieller, haben immer mehr Rechenfunktionen, oft nicht mal mehr einen Monitorausgang und migrieren zu reinen Rechenkarten, die einen speziellen Markt bedienen. Der Knackpunkt ist, dass die Karten, die man braucht, um richtig was damit zu machen, auch ordentlich teuer sind. Mit einer Karte unter 300,- ist nicht viel anzufangen und schon die Summe liegt weit ausserhalb des Consumer-Fensters. Diese rein rechnenen Zusatzkarten sind also keine wirklichen Grafikarten mehr, die zufällig im Markt eine grosse Käufergruppe hat und die man in einem parasitären Effekt nutzend, bei sich einbauen kann, um sie als Rechner zu misbrauchen, sondern die Karten sind dedizierte Systeme für genau diesen Zweck. Dafür gibt es aber schon seit Jahren Karten auf DSP-Basis, die man immer schon entlang der Anwendungen gebaut und optimiert hat. Wenn ich mir dann 2 Grafikarten reinstopfen muss, sie über PCIe koppeln muss, um denn mal 8GB RAM zu haben, dann nehme ich lieber einen Tausender, invesitere in eine dedizierte DSP-Karte, wie sie für Audio und Video in Massen exisitieren und habe gleich 32 GB Speicher, genug IO und optmierte DSP-Elemente mit 48 Bit/64 Bit, die die Auflösung bringen und richtig schnell sind. Man muss nämlich nicht vergessen, dass die jeweilige Rechen-App nicht gerade zu den Massenprodukten gehören, sondern im Massstab von einigen Hunderten laufen und damit der Produktpreis ziemlich unerheblich wird. Entscheidend ist am Ende die Entwicklungszeit und Sicherheit und warum soll ich meine getestete und validierungssichere DSP-Software Landschaft gegen eine open source Quasi-Plattform austauschen, mit der ich ein nichtoptimiertes Rechensystem habe? Das macht irgendwo keinen Sinn! Vergleiche fallen im Übrigen meistens so aus, dass Leistungs-Apps in DSPs besser aufgehoben sind und dort geht es teilweise sogar schon in Richtung embedded PC, weil diese Prozessoren so leistungsfähig werden, dass sie immer mehr DSP-Apps absorbieren. Von der anderen Seite rücken die FPGAs vorwärts. Die CUDA Sache ist nur dann ok, wenn man billige Karten zweckentfremded, die überwiegend nicht für diesen Zweck eingesetzt werden, weil eben genau dann die Stückzahlen stimmen. Der Grund, warum die Hersteller das nun machen und forvieren, liegt daran, dass sie sich diesen Markt erschliessen wollen. Daher unterstützen sie, was nur geht. Wenn aber eine Graka sich als gute Rechenkarte etablieren will, dann muss sie letztlich eine DSP-Karte werden und dann ist sie da, wo die heutigen DSP-Karten schon sind. Die Frage die man sich stellen muss, ib man diesen Weg mitgeht oder wartet, bis die Graka-Hersteller angekommen sind.
Nun, die Rechenleistung einer abgehobenen Grafikkarte und einer DSP Karte werden sich kaum vergleichen lassen. Eine Notebook CUDA karte hat eine Busbandbreite um die 80GByte/s, eine fuer einen Desktop liegt bei 140GBte/s und erreicht 500GFlop mit Doubleprecision, das doppelte mit Singleprecision. Die DSP Loesung sind nicht annaehernd da, denk ich. Die Verbreitung ist alles eine Frage der Marktgroesse.
Das sind ja schon etwas widersprüchliche Aussagen. Warum, wenn die Grafikkartenarchitektur und deren Anbindung an den PC-Bus so effektiv ist, hat man dann die DSPs nicht von vorn herein ähnlich aufgebaut bzw so angeschlossen? Meines Wissens nach, werden doch gerade die leistungsfordernden DSP-Plattformen in der Bildverarbeitung eingesetzt, wo man immer mehrere Kanäle (Quellen und Farben) und Datenbereiche (Pixelflächen) vorfindet. Wie könnte man die Rechenkapazitäten genauer aufschlüsslen und vergleichen? Ich habe dazu einen thread gemacht, weil mich das stark interessiert. Beitrag "Ein- und Abschätzung zum Grafikkarten-CoPro-Thema" Zum Markt: Wie gross ist etwa der Markt für Video-DSPs und wie positionieren sich hier die Grafikkarten-Chips? Eine mir bekannte Firma produziert komplexe FPGA-Kartensysteme, um Berechungen für Biochemie, Biogenetik und Wetter-Applikationen durchführen zu können. Der Grund ist die mangelnde Parallelität der Daten und der Aufwand, den es kostet, Rechenergebisse hin- und her zu bewegen, um sie an anderen Stellen verarbeiten zu können. Die Grafikkartensysteme sind da auch nicht für geeignet gewesen.
Bei normalen floating-point Anwendungen ist die Sache mehr als klar: Geforce GTX 560 Ti 200€ SP 1263 GFLOPs Altera EP2S180 7000€ 25 GFLOPs http://www.altera.com/literature/wp/wp-01028.pdf http://de.farnell.com/jsp/displayProduct.jsp?sku=1637235&CMP=e-2072-00001000&gross_price=true
@Udo 300€ Grafikkarten sind Mainstream, da werden richtig Stückzahlen an die Gamer verkauft. Welche FPGA oder DSP Lösungen du meinst, weiss ich nicht, aber meines Wissens benutzt man aus Kostengründen nirgends mehr FPGAs wenn GPUs auch gehen.
Was ja auch logisch ist, denn ein FPGA ist weitgehend frei strukturierbar, während die GPU hochspezialisiert ist und bereits beim Hersteller auf Die-Größe optimiert wird. Die späteren Herstellungskosten sind in etwa proportional zum Quadrat der Die-Fläche!
Hans Mayer schrieb: > Geforce GTX 560 Ti 200€ SP 1263 GFLOPs > Altera EP2S180 7000€ 25 GFLOPs Das gilt für die voll parallelen Berechungen bei 100% Auslastung und eben nur für die Berechungen. Der nächste Schritt ist, die Daten zu verwerten und dies gfs auch untereinander, wofür sich in FPGAs optmierte pipelines aufbauen lassen. Aufgrund der flexiblen Schaltungsstruktur lassen sich die Daten im FPGA dann auch mit der Bandbreite verschalten, bei der Karte musst Du erst über den Bus und gfs Daten umsortieren. Des Weiteren braucht es eine schnelle RAM-Anbindung, um an die Daten und Parameter heranzukommen: Geforce GTX 560 Ti: 1GB "GDDR5" RAM Anbindung an 64 Bit Datendurchsatz 0,5 GBPS Spartan 6 ($79,-!!!) mit 4 internen DDR3-Controllern: 4 x 4GB RAM = 16 GB RAM 4 x 400 MHz @ 34 Bit d.c. = ca. 50 GB/s Für dieselbe externe Bandbreite eines $79 FPGAs brauche ich 10 Grafikarten, für den Speicher gfs 16. Ich habe mal ausgerechnet, was man so an Berechungszeit und Ladezeit verbrät und komme immer auf die IO-Leistung als Flaschenhals, zumal der PC dann auch noch bremst, wenn er sein RAM ins Spiel bringen will. Für eine umfangreiche Berechung von 3D-Daten im Bereich Radar/Lidar braucht es rasch etliche GBs an RAM. Bei der internen Datentransportierung ist es schwer abzuschätzen: Für ein neuronales Netz mit m*n Knoten entsteht so schnell soviel Verschaltung, dass in einen kleinen FPGA nicht viel rein geht. Das aber, was reingeht, ist dann so extrem schnell, dass die Rückkopplungen und Berechungen quasi mit Taktfrequenz/n geschehen. Für ein mittleres Netz kam ich mal auf insgesamt 10MHz Daten-Loop-Frequenz und da war jedes Element mit jedem verschaltbar. Allein der Datentansport über PCI in eine Karte hätte keine 10kHz erlaubt, also nicht mal ein Tausendstel. Da ist die Rechenzeit dann unerheblich. Hans Mayer schrieb: > meines Wissens benutzt man aus Kostengründen nirgends mehr FPGAs > wenn GPUs auch gehen. Das ist wohl wahr. Langfristig müssen aber die PCs mitziehen, wenn aus der Geschichte mehr werden soll. Mindestens müssen mehrere Karten parallel betreib- und ansprechbar sein. Was ich mir vorstellen könnte wäre eine Chipsatznutzung durch FPGAs, womit eine anwendungsspezifische Architektur angewendet werden kann, die dann die parallele Architektur als schnellen CoProzessor nutzen könnte. Damit entfiele der Flaschenhals des PCI Busses, weil jeder Chip Zugriff auf beliebige RAMs bekäme und zudem beliebige Zahlen von Chips intergrierbaren wären.
Ja, wir werden in 6 Jahren wieder dort angelangt sein, wo transputer, connection machine und Co vor 20 Jahren aufgehört haben.
@B.: Geforce GTX 560 Ti: 1GB "GDDR5" RAM Anbindung an 64 Bit Datendurchsatz 0,5 GBPS Wie kommste denn auf den Trichter? Die hat 256Bit und der Speicherbus rennt mit 1GHz! Kann natürlich sein das es andere Modelle davon gibt. Spartan 6 4 x 400 MHz @ 34 Bit d.c. = ca. 50 GB/s Die Speichercontroller des FPGAs haben nur je 16 Bit soweit ich mich erinnere also insgesamt 4x16 Bit = 64 Bit @400MHz versus 256 Bit @1GHz. Allet kloar? ;-) Ein paar Deiner Argumente passen - aber das da ist Blödfug ;-)
Höffi schrieb: > 4x16 Bit = 64 Bit @400MHz versus 256 Bit @1GHz Sind das jetzt jeweils die DDR2/DDR3 Raten oder die Taktfrequenzen? Fehlt da noch ein Faktor? Ich habe auf Wikipedia gerade mal was über GDDRx gelesen, die in den Karten verbaut sein sollen, aber bin nicht sicher, wie das zu werten ist. Ist das ein externer Speicher oder steckt der in den Grafik-chips? Ich nehme an, die 256 Bit beziehen sich auf die Verbindung zwischen Chip und Garafikartenspeicher. Aber wie sieht es mit dem Transfer zum Rechner aus?
Fragi schrieb: > Aber wie sieht es mit dem Transfer zum Rechner aus? PCIe 16x Ver: 2.0/2.1 8000 MB/s Ver: 3.0 15754 MB/s
die neue ATI/ADM 7970 ist mit Speicherdurchsatz 264 GB/s angegeben, der GDDR5 ist mit 384bit angebunden.
Es gibt verschiedene GPUs , die GeForce 560 ist ein Einsteigermodell. Siehe mal etwas Besseres. Zb die nVidia Quadro 6000. CUDA Recheneinheiten 448 Gigaflops (Einfache Genauigkeit) 1030.4 Gigaflops (Doppelte Genauigkeit) 515.2 Gesamt-Framebuffer 6 GB GDDR5 Speicherschnittstelle 384-bits = 48 byte Speicher-Bandbreite (GB/s) 144 GB/s = 48 byte * 3G/s dh um an eine Grafikkarte ranzukommen muss man einen Satz FPGA's parallel laufen lassen.
Peter II schrieb: > PCIe 16x Nicht jeder hat ein PCIe Main Board und mit den Daten muss auch was passieren. Dort oben im PC sitzt ja immer noch ein langsamer Intel auf dem ein noch langsameres Windows mit einem extrem langsamen Matlab drauf, der das ganze dann visualisiert :-)
O.N. schrieb: > Nicht jeder hat ein PCIe Main Board also wer heute noch kein PCIe Board hat, der braucht sich auch keine Gedanken über Grafikkarte als Co Prozessor zu machen.
O.N. schrieb: > Nicht jeder hat ein PCIe Main Board Was denn dann? AGP? Da wirst du mit Cuda eh nicht viel holen können.
Rolf Magnus schrieb: > Ich würde gleich OpenCL nehmen, da es herstellerunabhängig ist, bzw. ich > hab das so gemacht. > Tommy hat aber Recht. Das ganze steht und fällt mit massiv > parallelisierbaren Aufgaben. Wenn du die nicht hast, bringt dir das > ganze überhaupt nichts. Da wäre ich noch etwas vorsichtig. Ich habe einen FFT-basierenden Algorithmus sowohl in CUDA als auch in OpenCL implementiert. Am Anfang war ich von OpenCL begeistert, da ich nach der sehr maschinennahen CUDA-Schnittstelle eine sehr aufgeräumte Schnittstelle vorfand, die mir sehr viele Arbeitsschritte und Absicherungen ersparte. Später allerdings mußte ich feststellen daß die von OpenCL zur Verfügung gestellte FFT leider keine Real-Transformation vorsah (was den Speicherbedarf drastisch erhöhte) und vor allen Dingen bei höheren Transformationsgrößen deutlich ungenauer war, so daß durch die Begrenzung derselben der Algorithmus langsamer lief als die CPU-Implementierung. Ansonsten kann ich in beiden Fällen (CUDA/OpenCL) nur raten, sich anhand von einfachsten Beispielen heranzutasten. Also: 1. Datenvektor zur Grafikkarte und Zurück. 2. Datenvektor auf der Grafikkarte durch einen simplen Kernel manipulieren, am besten erst einmal einen Beispielkernel nehmen! Weitere Hinweise: * Transferoperationen per memcpy-Derivaten innerhalb des Grafikkarten-Speichers sind sehr kostspielig, dafür am besten einen eigenen Kernel nehmen. * Wichtig ist das Verständnis der Organisationseinheiten - Man definiert eine Matrix von Transformationseinheiten, welche die Aufgabe parallel angehen sollen. CUDA/OpenCL müssen dann evt. die vorhandenen GPU-Kerne sequentiell anwenden, um diese Aufgabe zu absolvieren. Und immer daran denken: die Kerne arbeiten allein schon deshalb nicht im Gleichschritt, d.h. erst nach einer Barriere sind die Zwischenergebnisse auf dem gleichen Stand!
Anbei mal echte Ergebnisse (Korrelationssuche mittels FFT) FFT-Größe Zeit CUDA Zeit CPU Einsparung CUDA 2^18 00:03:00 00:03:06 -3,14% 2^20 00:02:25 00:01:50 23,73% 2^21 00:02:29 00:01:48 27,52% 2^22 00:02:30 00:01:49 27,27% Grafikkarte: GeForce 8400 GS CPU: Intel(R) Core(TM)2 Duo CPU E8200 @ 2.66GHz
Das Thema interessiert mich: Rolf schrieb: > .h. erst nach einer Barriere sind die Zwischenergebnisse > auf dem gleichen Stand! Das wäre dann ein Nachteil gegenüber FPGAs, sehe ich das korrekt? Rolf schrieb: > Anbei mal echte Ergebnisse (Korrelationssuche mittels FFT) Gegenüber WAS hast Du 22% eingespart?
Also, ich denke Leute, die mit noch CoreDuo arbeiten brauchen sich nicht mit Grafikcoprozessoren befassen. Entweder man hat ein Problem, oder eben nicht. Ich kann CPU und GPU auf aktuellem Niveau vergleichen. Zum Einen einen i7 mit 8GB RAM, auf Win7-64 und zum Anderen einen per 100MBit angebundenen i7 Server mit einer Tesla 2075. Anwendung sind Maxwell Gleichungen auf gegittertem 3D, dh finite elemente. Der lokale i7 ist mit seinen 8 Threads schon viel schneller wie ein Vorgaenger Rechner unter WinXP. Der externe Tesla bringt nochmals einen Faktor 10 in Geschwinigkeit. Dh ich kann jetzt in einer viertel Stunde mit der Teslakarte mehr rechnen wie frueher an einem ganzen Tag.
@Delta Oschi Mit welcher Rechengenauigkeit wurde da gerechnet? Single precision(32bit) oder double precision(64bit)?
Der urspruengliche Rechner war ein CoreDuo, glaub ich mit 4G auf WinXP. Die Tesla2075 kann double in HHardware, ob's gebraucht wird weiss ich nicht. Ich hab die Applikation nicht geschrieben.
Angeblich eignen sich AMD GPUs besser zum rechnen. So haben es jedenfalls die Bitcoin-Miner herausgefunden. Inwiefern sich das auf andere Rechenaufgaben auswirkt, kann ich allerdings nicht beurteilen. https://de.bitcoin.it/wiki/Mining_hardware https://en.bitcoin.it/wiki/Why_a_GPU_mines_faster_than_a_CPU#Why_are_AMD_GPUs_faster_than_Nvidia_GPUs.3F
Andi schrieb: > Delta Oschi schrieb: >> viel schneller wie > viel schneller als viel schneller als wie
Ich haette den i7 als etwa 4 mal schneller wie den CoreDuo eingeschaetzt. Dabei ist zu sagen, dass der i7 mit 8 threads rechnet und auch auf 64bit laeuft, waehrend der CoreDuo auch weniger Speicher hatte. Und der Tesla ist nochmals um den Faktor 10 schneller.
Mal ein kleiner Denkanstoß an diejenigen die immer Sagen GPGPU is ja soooo viel schneller als CPU: http://www.hwsw.hu/kepek/hirek/2010/06/p451-lee.pdf Conclusio des papers: eine GPU ist ca um den faktor 2.5x schneller als eine CPU. Und es hängt stark von der Anwendung ab. Wer sich weiter für FPGA interessiert, der sollte ich dieses paper genauer anschaun, da wird dann auch gleich noch power-consumption betrachtet: http://www.ece.cmu.edu/~pam/papers/micro43.pdf - Azrael
Naja, der erste Artikel ist von Intel. Der geringe Faktor sollte also keine Überaschung sein. Z.B. wird ein moderner i7 mit einer schon ins Alter gekommenen GTX280 verglichen, insbesondere in Bez. auf DP-Floats. Die aktuellen GraKas haben dagegen eine wesentlich höhere DP-Leistung. Und für im Artikel genannte DP-Leistung des i7 muss auch erst in SIMD geschrieben w erden (und das auch noch auf mehrere Threads verteilt.. nicht gerade einfach). Einfacher dagegen sind CUDA etc.
Markus H schrieb: > Das Thema interessiert mich: > > Rolf schrieb: >> .h. erst nach einer Barriere sind die Zwischenergebnisse >> auf dem gleichen Stand! > Das wäre dann ein Nachteil gegenüber FPGAs, sehe ich das korrekt? Nun ja, auch bei einem FPGA muß man Synchronisierungspunkte definieren (z.B. Taktflanken, bis zu denen ein Volladdierer sein Ergebnis stabil haben muß). > > Rolf schrieb: >> Anbei mal echte Ergebnisse (Korrelationssuche mittels FFT) > Gegenüber WAS hast Du 22% eingespart? Die Einsparung bezieht sich auf die Bearbeitungszeit mit Ausnutzung von CUDA im Vergleich zur Bearbeitungszeit mit der CPU-basierenden FFT-Bibliothek. Meiner Meinung nach hätte ein in den PC integrierter und auf Berechnung hin optimierter FPGA (evtl. als variabler Koprozessor) ebenfalls großes Potential. Ansonsten sollte man nicht vergessen: CUDA- bzw. OpenCL-fähige Grafikkarten stecken mittlerweile auch in Büromaschinen, FPGA-Karten sind weniger vorauszusetzen. CUDA und OpenCL erschließen vorhandenes Potential, weniger für diese Anwendungen geschaffenes Potential.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.