Könnte mir bitte jemand kurz eine Idee geben, wie man den Zeitbedarf für
eine Berechung in einer Grafikkarte abschätzen kann, um zu sehen, wie
sich Parallelisierung und Datenverschiebung auswirken?
Für reines C lassen sich die Zyklen ja recht gut gut schätzen, wenn man
z.B. Laden, Elekemtarrechungen und Speichern abschätzt:
2Z Wert A aus RAM holen
1Z Wert C = A * A
2Z Wert B aus RAM holen
1Z Wert D = C + B
2Z Wert D als Ergebnis speichern
macht 8 Zyklen und somit für 768 Werte etwa 60us bei 100MHz
Für einen AVR sieht es freilich anders aus, als bei einem ARM oder DSP
oder einer Plattform CPU, aber es wird mehr oder weniger in einer
Schleife gerechnet und man kann es durch Variation schätzen.
Wei sieht das bei einer Grafikarte aus?
Wenn ich für 768 Werte jeweils die o.g. Formel Y(k) = A(k)*A(k) + B(k)
rechnen will, wie lange daurt die Rechung, was ist dabei parallel und
wie lange muss ich die Werte einladen?
Soweit ich weiss, können die Grafikchips nicht beliebige Auflösungen
rechnen, sagen wir mal die Werte wären alle unterschiedlich und im
Bereich von 16Bit Integer positv (0 ... 65536).
Können beim Einladen die 66MHz Bustakt angenommen werden oder kann hier
auch parallel geladen werden, z.B: 8 Werte x 16 Bit auf 64 Bit auf
einmal rein? Das wären dann 768 / 4 * 2 Zyklen
Vor allem interessiert mich, wie die Parallelisierung ins Spiel kommt.
Wenn ich die ersten Werte über den Bus geladen habe, dann könnte die
Grafikarte ja schon losrechnen und hätte die ersten Werte schon fertig.
Wieviele Rechnungen welcher Komplexität können da parallel ablaufen?
Aus meiner Sicht müsste sich für einen parallel abarbeitbaren Block
sowas ergeben wie:
Elementarberechungszeit = Funktion (Formeltiefe; Formelbreite)
Sequenzialisierung = Ganzzahl (gef. Auflösung / Grafikkartenauflösung)
Berechnungszeit je Block = Elementarberechungszeit * Sequenzialisierung
Zahl der Blöcke = Zahl der Daten / Parallelität
Zeit für alle Blöcke = Zahl der Blöcke * Berechnungszeit je Block
Ein-ausschreibezeit = Zahl der Daten * Bitbreite / Busbreite
Gesamtzeit = Zeit für alle Blöcke + Ein-ausschreibezeit (pipelined)
oder:
Gesamtzeit = Zeit für alle Blöcke + Zahl der Blöcke *
Ein-ausschreibezeit (vollständig gelooped)
Das ist natürlich eine unbefriedigende Antwort. Wie müsste man der
Grafikkarte mitteilen, dass sie was rechnet und was hat man da zur
Verfügung?
Gehen wir mal konkret davon aus, dass alle der 768 Kalkulationen
unabhängig laufen können und sollen. Wieviele kann man da parallel
reinladen?
Irgendwo im Hinterkopf klingelt da c´t Artikel irgendwann in 2011, API
Schnittstelle für solche Sachen von nVidia bei mir. Da stehen die Basics
zur Grafikkartennutzung drin. Imho bekommste bei nVidia auch die API
Doku auf der Webseite. Da es nicht meine Profession ist, hab ich den
Artikel leider nicht geistig archiviert, war aber interessant zu lesen.
mfg
Joerg
Von M$ gabs da mal ne Vorstellung eines deren Software-Gurus. Ich glaube
der Link kam hier von µC.net
Da gibts ein API, mit dem man normalen aussehenden C-Code automatisch in
eine Variante für GPU umcompilieren lassen kann.
Zumindest war das hier schon öfters Thema. Also lesen.
Es gab auch mal ne Anfrage an den Programmierer von LTspice
diesbezüglich obs Sinn machen würde, SPICE auf einer GPU laufen zu
lassen. Sinngemäß war seine Antwort:
Nein, weil die FPU auf den heutigen CPUs extrem schnell ist und alles
eher durch das I/O zeitlich begrenzt wird.
Er hat sich dafür einen internen Compiler ausgedacht, der den SPICE-Code
auf alle Cores der CPU verteilen kann und einen Zwischencode benutzt.
Abdul K. schrieb:> Von M$ gabs da mal ne Vorstellung eines deren Software-Gurus. Ich glaube> der Link kam hier von µC.net> Da gibts ein API, mit dem man normalen aussehenden C-Code automatisch> in eine Variante für GPU umcompilieren lassen kann.http://herbsutter.com/2011/06/16/c-amp-keynote/
Guter Überblick über die verfügbaren Libraries und Sprachen
http://gpgpu.org/tag/programming-languages> Zumindest war das hier schon öfters Thema. Also lesen.>> Es gab auch mal ne Anfrage an den Programmierer von LTspice> diesbezüglich obs Sinn machen würde, SPICE auf einer GPU laufen zu> lassen. Sinngemäß war seine Antwort:> Nein, weil die FPU auf den heutigen CPUs extrem schnell ist und alles> eher durch das I/O zeitlich begrenzt wird.
Extrem schnell? Momentan liegt die schnellste CPU i7 SB bei ~100 GFlops
(alle Cores zusammen), eine HD 7970 bei 947 GFlops (double precision)
und 3.78 TFlops (single precision).
"Performance Comparison of Single-Precision SPICE Model-Evaluation
on FPGA, GPU, Cell, and multi-core Processors"
http://authors.library.caltech.edu/18923/1/Kapre2009p10508Fpl_2009_International_Conference_On_Field_Programmable_Logic_And_Applications.pdf
(eine 9600 GT GPU war da Faktor 3 bis 131 schneller als ein Xeon 5160)
http://www.nvidia.com/object/cuda_app_tesla.html
listet ein paar SPICE/Simulationspakete
Die Frage ist nur ab welcher Modellgröße/komplexität sich das lohnt.
Zitat aus dem Vergleich FPGA, GPU und CPU:
We are able to show that we can accelerate Single-Precision
SPICE Model-Evaluation by
1- 33 when using an IBM Cell
3-131 when using the NVIDIA 9600 GT GPU
3–182 when using a Xilinx Virtex5 FPGA
compared to 3 GHz Intel Xeon 5160.
Der Virtex 6 lief auf nur 200 MHz. Allerdings kostet der auch x-mal mehr
und frisst das dreifache an Strom.
> We are able to show that we can accelerate Single-Precision SPICE
Model-Evaluation by ...
Natürlich haben die ihre Benchmarks mit single precision laufen lassen,
damit das auf einer GPU gut aussieht.
Gerade bei SPICE sollte man aber mit 64bit floating point rechnen. Das
zieht die GPU-Performance um Faktor 5 herunter. Da bleibt dann gar nicht
mehr so viel Geschwindigkeitsvorteil, dass sich das für die Masse der
Anwendungen lohnen würde.
Da muß ich Helmut leider recht geben. Ich muß bei vielen Sims die
Precision auch hochstellen. Soll sagen, Single-Precision lohnt nicht
wenn dafür extra Code erstellt werden müßte.
Ich denke, der ganze GPU-Kram ist für die breite Anwendung auch noch
nicht genug gefestigt. Wer weiß, obs das in 10 Jahren noch gibt. Ich
kann mich noch gut an die vielen CPU/DSP-Einsteckkarten für PCs
erinnern. Da ist doch der Run schon vorbei und es blieben allenfalls
wenige Speziallösungen übrig - da wo es sich finanziell wirklich lohnt.
Früher lief Elektronik-Software auf sogenannten Workstations - die
keiner zuhause hatte.
Na, von denen gibt es noch reichlich, aber die sitzen in der Niesche und
man darf annehmen, dass sie ihre Produkte soweit optimiert haben, dass
das Preis/Leistungsverhältnis stimmt.
Die Frage ist, wie man seine Rechenkapazität erweitert, wenn man mit dem
Prozessor am Ende ist. Entweder man nutzt eine Dual CPU oder schleift
einen weiteren Rechner ein. Im AV-Bereich wird einfach die SW nochmal
installiert und ber Ethernet drangekoppelt.
..oder halt eine DSP-Karte.
Oli schrieb:> Na, von denen gibt es noch reichlich, aber die sitzen in der Niesche und> man darf annehmen, dass sie ihre Produkte soweit optimiert haben, dass> das Preis/Leistungsverhältnis stimmt.>
Bis die betreffende Firma dann plötzlich verschwand ;-)
> Die Frage ist, wie man seine Rechenkapazität erweitert, wenn man mit dem> Prozessor am Ende ist. Entweder man nutzt eine Dual CPU oder schleift> einen weiteren Rechner ein. Im AV-Bereich wird einfach die SW nochmal> installiert und ber Ethernet drangekoppelt.
Es scheitert an der Software Verfügbarkeit bzw. dem Willen der
Programmierer/Geldgeber.
SETI@Home ginge auch für andere Anwendungen.
Speziell für den Bereich SPICE ist eine vernünftige Auslegung der
Simulation zielführender. Wenn man natürlich meint, man könne den AVR
gleich mit in SPICE simulieren, wird das sicherlich scheitern oder
zumindest sehr schwierig werden. Also Probleme möglichst kleinmaschig
aufspalten und einzeln simulieren. Die Ergebnisse dann per Brain
zusammenführen.
>> ..oder halt eine DSP-Karte.
Sehe ich keine Zukunft. Sowas wird vielleicht für CTs und ähnlich
bildgebende Sachen verwendet. Man muß den ständig steigenden Kostendruck
in Form des PC-Preisverfalles im Auge haben.
Der PC wird immer billiger? Sehe ich eigentlich nicht. Die Chips werden
wohl etwas besser, aber der PC als solcher nicht wirklich. Ausserdem
würde die DSP Chips ja mit billiger werden.
Der PC ist genau genommen auch noch ein unterschätztes Thema, denn
schließlich ist er ein Grössen und ein Kostenfaktor. Man rechnet ja
gerne vor, dass bei der Nutzung eines PC keine Kosten entstünden, weil
der ja ohnehin vorhanden ist, aber wenn eine APP ihn belegt, ist er
rechentechnisch weg.
Wenn man da nur mal an MATLAB und Konsorten denkt.
> ..oder halt eine DSP-Karte.
Ich kenne es nur von den Audio-DSP-Plattformen: Wenn man die einmal
konfiguriert hat, also einen Synthesizer, ein Mischpult oder einen
Klangprozessor eingebaut hat, laufen die autark ohne Rechnerbelastung,
weil sie ihre IOs selber treiben.
Bei den Grafikkarten kommt man meines Wissens nur über den PC an die
Aussenwelt heran, oder kennt jemand eine Applikation, wo eine einmal
geladene Karte selber rechnet und auch IO-Kanäle besitzt?
Udo schrieb:> wo eine einmal> geladene Karte selber rechnet und auch IO-Kanäle besitzt?
Das ist wohl was für die Zukunft. Für das Treiben von IOs müssten aber
schon FPGAs her, die die Grafik-Chips passend ansteuern. Dazu müssten
die Hersteller die Chips aber solo liefern und ich weiss nicht, ob da
Interesse besteht.
Ich fände die Vorstellung aber reizvoll, weil man an einen FPGA
sicherlich gleich mehrere Grafik-Chips samt RAMs dran bekommt und
parallel laden und entladen kann.
