FFT auf mehrere Rechenkerne optimieren

Hat denn noch andere Ideen oder Verbesserungsvorschläge?

Anzeige

' schrieb:@ Lucki
Ich habe halt ein zweidimensionales Array als Eingang. Du hast Dir ein eindimensionales Array erzeugt. Deshalb kann ich die Arrayfunktion "1D Array transponieren" nicht verwenden. Ansonsten ist die Idee schon mal nicht schlecht.

Kann es viellicht sein, daß Du übersehen hast, daß jede Waveform den Array eines Zeitverlaufes enthält, und daß also ein eindimensionales Array of Waverforms genau so "gehaltvoll" ist wie ein zweidimensionales normales Array???

Ich weiß Du hast eine Waveform aus 2048 Werten erzeugt. Und dies 1000 mal. Somit hast Du auch ein zweidimensionales Array. Dies mache ich ja auch mit meiner inneren For-Schleife, jedoch kann ich nicht die Arrayfunktion "1D Array dezimieren" verwenden. Warum eigentlich nicht? Wir habe dich beide ein zweidimensionales Array.

' schrieb:Nachdem die Version, die Y-P zuletzt hochgeladen hat, auf meinem Dual-Core keine besondere Verbesserung zeigt, hier nochmal Version 1.1 (die lief bei mir auf jeden Fall schneller):

Ach ja, Luckis Version bringt bei mir wieder Geschwindigkeitvorteile. Ich denke, dass liegt daran, dass bei Version 1.1 & Version 2(Lucki) erst einmal das Array in 2 (4) große Unterteile zerteilt wird, und dann 2(4) Prozesse auf diesen Sub_Arrays parallel arbeiten können.

Version 2 (also FFT_Performance_Test_Version_NEU.vi ) finde ich nicht optimal für parallele Verarbeitung, da hier in einer For-Schleife immer nur ein 1D-Array aus dem 2D-Array geholt wird. Somit müssen die parallelen PowerSpectrum VIs immer aufeinander warten...

Das kann ich nicht bestätigen und es wäre auch gegen die allgemeine Erfahrung, wonach Express-VIs (benutzt im FFT-VI Version 1) ja immer etwas langsamer sind als die entprechenden normalen Vis. (Man beachte schon mal die bytemäßige Aufgeblähtheit der Version 1, s. unten)
Beiden Vis gemeinsam ist ist aber, daß sie a) für Waveforms optimiert sind, und b) daß viele Waveforms auf einmal verarbeitet werden können.
Es ist doch Irrsinn, die Geschwindigkeit optimieren zu wollen, und dann diese beiden Eigenschaften nicht zu verwenden, und statt dessen sich in Zahlenkonvertierungen und for-Schleifen zu üben.
Hinweis noch: Auch das Fenstern schluckt etwas Zeit. Man braucht es, wenn der Zeitverlauf keine ganzzahlige Anzahl von Perioden enthält oder überhaupt nicht periodich ist. Hat man dagegen genau eine oder genau mehrere Perioden, dann ist das Fenstern nur schädlich.
Habe noch mal beide Versionen entsprechend umgestellt und poste sie in.
Es ist auch zu beachten, daß sich in LV8.6 zwar nicht sehr viel geändert hat - aber es kann beachtliche Geschwindigkeitsvorteile bringen. Die Ergebnisse der LV-Versionen sind dann schlecht vergleichbar.
2:
  FFT_Performance_Test_Version_NEU_1_2_WA.vi (Größe: 31,94 KB / Downloads: 159)

1:
  FFT_Performance_Version_1.1_WA.vi (Größe: 202,01 KB / Downloads: 174)

' schrieb:Ich weiß Du hast eine Waveform aus 2048 Werten erzeugt. Und dies 1000 mal. Somit hast Du auch ein zweidimensionales Array. Dies mache ich ja auch mit meiner inneren For-Schleife, jedoch kann ich nicht die Arrayfunktion "1D Array dezimieren" verwenden. Warum eigentlich nicht? Wir habe dich beide ein zweidimensionales Array.

Nein, ich habe ein eindimensionales Array von Waveforms, und Array dezimieren funktioniert nur mit eindimsnionalen Arrays.
Wenn Du die Funktion dezimieren für ein 2D-Array verwenden willst, dann so: jeden der Zeiverläufe mit 2048 Daten in ein Cluster packen, davon ein 1D- Array von 1000 Clustern bilden.
Edit: die zweifellos schnellste Möglichkeit, die Daten in 4 Gruppen aufzuteilen, wurde leider von niemanden benutzt - von mir auch nicht. Es funktioniert mit dem VI "Array umformen":
   

Das problem ist nur, das meine Datenerfassungskarte ein zweidimensionales Array zurückliefert. Und da denn extra so ein Wavesignal draus zu erzeugen ist der falsche Weg.

Ich denke nicht das das Express vi langsamer ist. Ich werde es morgen mal mit Express VIs und ohne Express VIs testen.

Anzeige

' schrieb:Das problem ist nur, das meine Datenerfassungskarte ein zweidimensionales Array zurückliefert. Und da denn extra so ein Wavesignal draus zu erzeugen ist der falsche Weg.

Was soll denn daran falsch sein? Wenn Dus nicht machst dann machen doch die Umformung die VIs. Und wenn Die FFT-Vis sowieso damit erbeiten dann ist es doch am besten, gleich am Anfang demit zu beginnen, dann hast Du für die Zeit-und Frequenzdiagramme gleich die richtigen Skalierungen.

Eine andere in sich konsepuente Vorgehensweise ist dann alledings die, die FFT-VIs durch solche zu ersetzen, welches nicht mit Waveforms arbeiteten. Die gibt es auch, und vielleicht wird das sogar die schnellste Möglichkeit sein.

   

' schrieb:.... und hier noch das von mir (bzw. das von Pimbolie, bei dem die Express-VIs ersetzt wurden).

[attachment=44248:FFT_Perf...sion_NEU.vi]


Gruß Markus

Hier ist eine geänderte Version des obigen VIs, dass das Array wieder korrekt zusammensetzt. Denn nur so kann man einen korrekten Geschwindigkeitsvergleich machen!

  FFT_Performance_Test_Version_NEU_korrekt.vi (Größe: 31,84 KB / Downloads: 168)

' schrieb:Es ist auch zu beachten, daß sich in LV8.6 zwar nicht sehr viel geändert hat - aber es kann beachtliche Geschwindigkeitsvorteile bringen. Die Ergebnisse der LV-Versionen sind dann schlecht vergleichbar.

Jaaa, das kann ich bestätigen!!!

Ich sitze nämlich gerade vor meinem Laptop mit Intel-DualCore Centrino, auf dem ich neben 8.6 auch 8.5.1 habe. Da konnte ich mich natürlich nicht zurückhalten und musste mal einige Geschwindigkeitsvergleiche durchführen, mit interessanten Resultaten:

Fangen wir mit dem ersten VI von pimbolie1979 an, also dem VI FFT_Performance_Version_1.1.vi (Länge der Arrays auf 2048 gekürzt):
Durchlaufzeit unter 8.5: ca. 120 ms (seriell UND parallel)
Durchlaufzeit unter 8.6: ca. 120 ms seriell, ca. 85 ms parallel

So, jetzt Version FFT_Performance_Test_Version_NEU-korrekt.vi, also die korregierte Version, die das Array am Ende korrekt zusammensetzt!
Durchlaufzeit unter 8.5: ca. 120 ms seriell, ca. 130 ms parallel
Durchlaufzeit unter 8.6: ca. 120 ms seriell, ca. 95 ms parallel

Dann testen wir noch Luckis VIs, zuerst FFT_Performance_Version_1.1_WA.vi:
Durchlaufzeit unter 8.5: ca. 138 ms seriell, ca. 152 ms parallel
Durchlaufzeit unter 8.6: ca. 138 ms seriell, ca. 108 ms parallel

Und zum Abschluss FFT_Performance_Test_Version_NEU_1_2_WA.vi:
Durchlaufzeit unter 8.5: ca. 130 ms seriell, ca. 148 ms parallel
Durchlaufzeit unter 8.6: ca. 130 ms seriell, ca. 101 ms parallel

Fazit dieses Tests aus meiner Sicht: Es scheint eine signifikante Verbesserung bei der Erzeugung von Code für die parallele Verarbeitung von Daten bei LV8.6 gegenüber der Vorgängerversion zu geben.

Gruß, Jens

EDIT: Links zu den getesteten VIs eingefügt.

' schrieb:Fazit dieses Tests aus meiner Sicht: Es scheint eine signifikante Verbesserung bei der Erzeugung von Code für die parallele Verarbeitung von Daten bei LV8.6 gegenüber der Vorgängerversion zu geben.

Gruß, Jens

Vielen Dank für die Gegenüberstellung. Vielleicht werde ich jetzt doch auf 8.6 umsteigen. (Oder doch noch auf 8.7 warten? So lange kann das ja auch nicht mehr dauern...)

Wäre mal interessant die MFlops zu diesen Zeiten zuerrechnen..
Wenn jemand auch noch Matlab installiert hat könnte man das ja auch mal zum Vergleich heranziehen.

Ansonsten hab ich noch diesen Link aufgetan: FTTW, kommt zwar aus der Unix-Welt es lässt sich aber wohl auch unter Win compilieren. Die Seite hat auch schöne Links auf weitere FFT-Implementationen und die Theorie dazu.

Was vielleicht auch noch einen Zeitgewinn liefern kann is Singlepresicion vs. Doubleprecision, sofern man mit der schlechteren Genauigkeit leben kann..

Gruß,
Rob