URL: https://www.overclockers.at/coding-stuff/c_libraries_fuer_matrixoperationen_und_matlab_117037/page_2 - zur Vollversion wechseln!
Wenn er schreibt, dass er noch nie was in C/C++ gemacht hat, sollte er allerdings die Finger davon lassen. Numerische Routinen selber zu schreiben ist wohl das schwierigste, was es gibt. Und so lang gibt's die Möglichkeit der GPU-Auslagerung noch nicht, dass es da schon vernünftige Bibliotheken gäbe.Zitat von SYSMATRIXwenns echt um killer performance geht, solltest du auch in erwähnung ziehen GPUs als rechenknechte zu misbrauchen, eine halbwegs moderne GPU sind wie geschaffen für matrix operationen(besonders wenn sie im fp format sind).
daß er noch nie was mit C/CPP gemacht hat, hab ich überlesen :/Zitat von RingdingWenn er schreibt, dass er noch nie was in C/C++ gemacht hat, sollte er allerdings die Finger davon lassen. Numerische Routinen selber zu schreiben ist wohl das schwierigste, was es gibt. Und so lang gibt's die Möglichkeit der GPU-Auslagerung noch nicht, dass es da schon vernünftige Bibliotheken gäbe.
fragt sich nur noch wie du aus der renderpipeline etwas rausholen willst. textur = input daten -> pixelshader mit code -> und ergebnisse dann wieder aus der textur rausholenZitatwenns echt um killer performance geht, solltest du auch in erwähnung ziehen GPUs als rechenknechte zu misbrauchen, eine halbwegs moderne GPU sind wie geschaffen für matrix operationen(besonders wenn sie im fp format sind).
ZitatWenn er schreibt, dass er noch nie was in C/C++ gemacht hat, sollte er allerdings die Finger davon lassen
A quick search brought me to some preliminary work done at the University of Washington with a GeForce4 TI 4600 pitted against a 1.5GHz P4. My Favorite excerpt from the paper: 'For a 1500x1500 matrix, the GPU outperforms the CPU by a factor of 3.2.'
http://www.cs.washington.edu/homes/...n-micro2002.pdf
BrookGPU:
generap purpose comuting with GPUs compiler:
http://graphics.stanford.edu/projects/brookgpu/
mat, lach nicht. Das geht wirklich schneller. Allerdings erst auf der GF 6800
vielleicht noch ein paar infos:
wir werden mit teil-matrizen von ca. 1500x1500 integer elementen rechnen, weil wir vermuten, dass es mit zum beispiel 10000x10000 elementen schon problematisch wird mit dem speicher. also matlab wird zum beispiel bei der großen matrizen schon ziemlich langsam, auch beim einlesen aus einer datei... welche größen schaff ich denn auf einem standardrechner?
1500x1500 ist nicht sonderlich groß, groß ist ca 2mio x 2mio
außerdem kommts auf die non-zero stellen der matrix an wie schnell oder wie langsam es dann im endeffekt sein wird.
was wollt ihr denn eigentlich machen ?
wie schnell muß es denn sein?
wenns echt schnell sein muß -> mit FPGA in hw implementieren
konkret sind es landschaftsdaten (digitale karte) mit einer ziemlich feinen auflösung (<50 meter) und je mehr elemente wir abbilden können in eine matrix, um so besser. alle elemente dieser matrix sind mit verschiedenen höhen belegt.
könnt ich in c++ theoretisch eine matrix mit 10 000x10 000 elementen anlegen und vernünftig damit arbeiten?
/add: tja, sind diese karten einmal im speicher abgelegt brauch ich schnelle funktionen, die zum beispiel die interpolierte höhe an einem punkt liefern. dann gibts noch eine reihe anderer funktionen, die sichtlinien zwischen 2 punkten, etc berechnen sollen. all diese kleinen funktionen sollten aus dem grund flott sein, weil sie ein anderer ziemlich langsamer pseudo-rekursiver algorithmus braucht, der viel rechenzeit in anspruch nimmt (flugplanung durch die karte).
andere funktionen, wie höhenschichtmodelle und so anlegen, dürfen ruhig eine zeit brauchen.
aber auf nen FPGA oder DSP wird des ganze zeug nicht ausgelegt, sondern der darf ruhig schon mal eine nacht rechnen oder so.
Also eine Matrix-Multiplikation trau ich mir schon nicht mehr so ohne weiteres zu, wenn sie wirklich schnell sein soll (blocking wegen cache size ist da z.B. zu berücksichtigen). Wie sich das mit dem Cache auf der Grafikkarte verhält, ist halt fraglich. Da weiß ich leider noch nichts genaues darüber.
Naja brauchst halt 800MB RAM für eine einzige Kopie dieser Matrix -> wird schon sehr eng auf einer x86 Maschine. Aber glaub ja nicht, dass das Zeug schneller wird, weil du es als unerfahrener C Programmierer einfach mal in C schreibst. Die Matlab-Routinen sind schon sehr gut optimiert, es ist schon nichttrivial, mit der Geschwindigkeit überhaupt mitzuhalten, geschweige denn, sie zu schlagen.Zitat von NullSpacekönnt ich in c++ theoretisch eine matrix mit 10 000x10 000 elementen anlegen und vernünftig damit arbeiten?
unpackbar, das geht ordentlich am sinn vorbei
ok.. ich hab das pdf nicht (ganz) gelesen: benutzen die für die CPU irgendwelche speziellen instruktionen wie siehe oben? ausserdem muss input + output in/aus den videoram kommen => über AGP und das is ebenfalls nicht schnell. und dann kommt dazu, dass wirklich komplexe funktionen in shadern, wie zB inverse von matrizen > 3x3 berechnen, noch nicht möglich sind, weil shader nur bis zu einer gewissen anzahl von instruktionen gut performen (kommt auf die grafikkarte an).
Zitat von RingdingAber glaub ja nicht, dass das Zeug schneller wird, weil du es als unerfahrener C Programmierer einfach mal in C schreibst. Die Matlab-Routinen sind schon sehr gut optimiert, es ist schon nichttrivial, mit der Geschwindigkeit überhaupt mitzuhalten, geschweige denn, sie zu schlagen.
das darf ich leider nicht, weil mein professor es in c++ haben will (er meint ich soll ja auch was dabei lernen, weil in matlab gehts ja so gschwind *g*). Hmm, das gibt's anscheinend nur für 32 bittige Architekturen (schade).Zitat von RingdingWenn's Matlab für Itanium gibt, dann kauft euch so ein Ding mit ein paar Gig RAM und vergiss das wieder mit C++.
Das mit der GF 6800 hab ich geschrieben, weil die erstens viel komplexere Shader verwenden und zweitens FP-Zahlen im double Format verarbeiten kann.Zitat von RingdingAllerdings erst auf der GF 6800
Die Operationen, die du oben erwähnt hast, schauen alle nach einfachen Array Lookups aus. Die sind natürlich kein Problem, trotzdem sollte man aber einen genügend großen Adressraum haben (möglicherweise >32 bit), wenn das ganze nicht furchtbar kompliziert werden soll.
overclockers.at v4.thecommunity
© all rights reserved by overclockers.at 2000-2026