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)
> Vor allem interessiert mich, wie die Parallelisierung ins Spiel kommt.
So wie du sie machst.
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
Wenn du 768 Cores hast, dann Alle. Aber da Sie ja Erst mal aus dem Hauptspeicher über den PCIe Bus muß wird hierdurch die Geschwindigkeit begrenzt.
Uwe schrieb: > Wenn du 768 Cores hast, dann Alle. Was meinst Du mit Cores? Irgendwo gibt es dort doch ein Limit bez. des Produkts aus Zahl und Grösse.
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.
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.