Berechnung mit OpenMP zu langsam
-
Klassische Noob-Paranoia.
-
hustbaer schrieb:
Klassische Noob-Paranoia.
ich?
-
Klar, wer sonst.
Google auch gerne mal NIH (not invented here).Bzw. allgemein Dinge selbst zu implementieren nur weil man meint (ohne gute Grundlage) dass die fertigen Implementierungen evtl. nicht gut genug sein könnten...
Trotz dem diese von Teams entwickelt wurden die sich wirklich mit der Materie auskennen...
Das macht keinen Sinn.Passt aber genau zu dir.
ps: Wenn man früh Testläuft macht, kommt man üblicherweise recht schnell drauf ob das gewählte Tool den Anforderungen entspricht. Und dann tauscht man es einfach aus, bzw. schreibt dann was eigenes. Bzw. wenn die Softwarearchitektur halbwegs sauber ist, ist es auch kein grosses Problem wenn man erst sehr spät draufkommt.
-
hustbaer schrieb:
@Simon S.
Hast du mal probiertnum_threads
beim#pragma parallel for
zu verwenden statt bzw. zusätzlich zuomp_set_num_threads
?
Oder mal nen anderen Compiler probiert (MSVC, GCC)?Hat nichts geändert. Der Intel war am besten, habe die anderen beiden schon getestet.
Habe jetzt noch paar Messungen mit verschiedenen Varianten durchgeführt.
Variante0:(ohne RunFull(), läuft in einem Thread)
0,2s
Diese müssen also bei allen folgenden Werten abgezogen werden um die Zahlen für RunFull() zu erhalten.Variante1:(ein großer LUT)
1 Thread: 13s
2 Threads: 7s
8 Threads: 4s
16 Threads: 2s
32 Threads: 1,5sVariante2:(ein großer LUT und alle Schleifen guided)
32 Threads: 1,22sVariante3:(Schleifen 42, 42, 42, 43)
1 Thread: 6,3s
2 Threads: 3,3s
4 Threads: 2,1s
8 Threads: 1,4s
16 Threads: 1,3s
32 Threads: 1,3sVariante4: (Schleifen 42, 42, 42, 43 und alle Schleifen guided)
8 Threads: 1,22s
16 Threads: 0,92s
32 Threads: 1,15sVariante5: (Schleifen 32, 32, 32, 32, 41)
8 Threads: 1,46s
16 Threads: 1,24s
32 Threads: 1,33sVariante4: (Schleifen 32, 32, 32, 32, 41 und alle Schleifen guided)
8 Threads: 1,23s
16 Threads: 1,07s
32 Threads: 1,06sVariante6: (Schleifen 32, 32, 32, 32, 41 nur Schleife mit 41 guided)
8 Threads: 1,55s
16 Threads: 1,14s
32 Threads: 1,18sDie CPU-Auslastung ist wie gesagt laut htops nicht bei 100%.
z.B. bei Variante 4 32Threads nur bei 50%
Da später mal noch mehrere Berechnungen in die 3er for-Schleife kommen, würde sich die Berechnungszeit erstmal hoffentlich nicht erhöhen und die CPU-Auslastung Richtung 100% gehen, oder ist das Quatsch?So richtig zufrieden bin ich mit den Ergebnissen nicht wirklich. Ich würde mich jetzt für die Variante 4 entscheiden.
Es ist wohl guided all > guided last > non guided und LUT split passend zu threadzahl > LUT split random > LUT bigZu arr[i] = func();
Das verstehe ich nicht. Wieso soll ich die Werte erst in ein Array speichern.
Ist das so gedacht, dasarr[i] = ((3.0f*iterations1) * lut3Linear[zwischenErgebnis1] - iterations2) * zwischenErgebnis2;
sich leichter vektorisieren lässt und nach der Vektorisierung wird das Array aufaddiert um auf
berechnung1 = berechnung1 + ((3.0f*iterations1) * lut3Linear[zwischenErgebnis1] - iterations2) * zwischenErgebnis2;
zukommen.
Ich bin für jeden weiter Hilfe sehr dankbar und möchte mich bei allen für ihre Antworten bedanken.