c++.de :: [gelöst Danke]Parallelisierung einer For-Schleife

Unregistrierter

... sowie -march=native

ComputerCarl Mitglied 20:34:18 25.05.2012 Titel:

Die Einstellungen bringen auch einige wichtige Sekunden, aber die Rechnungen
dauern immernoch Minuten. Müssen sie auch, es geht um große Datenmengen. Aber das
alles bringt mich wieder zurück zur Parallelisierung. Bzw. gibt es noch weitere
Compiler-technische Vorschläge?

Ethon Mitglied 20:38:35 25.05.2012 Titel:

Nö. Jetzt solltest du einen Profiler auspacken und nachsehen, wo das Programm am Längsten braucht.
Wenn sich das Problem gut parallelisieren lässt, mach ruhig, schau dir dazu std::thread/std::mutex/std::fure an.

cooky451 Mitglied 20:53:02 25.05.2012 Titel:

Zwischen O0 und O3 liegen nur sekunden? Zeig vielleicht doch mal deinen Code.

Ansonsten mit 4.7 kannste std::thread nutzen und std::future nutzen.

ComputerCarl Mitglied 21:24:53 25.05.2012 Titel:

Also ich habe erneut mit clock() Messungen durchgeführt und die meiste Zeit
geht in den 3-verschachtelten for-Schleifen drauf. (Die sind notwendig:
erste geht über alle Daten und die beiden Folgenden gehen über die Zeilen
und Spalten der Forward- und Backwardmatrix der jeweiligen Sequenz) Die Berechnung der Schätzer nimmt weniger Zeit ein. Sollte, aber vermutlich auch parallelisiert werde.
Ich werde mich jetzt einfach in die threads reinlesen. Danke nochmal an alle
Mitdiskutierer.

Michael E. Mitglied 21:34:51 25.05.2012 Titel:

Wie sieht deine Definition von data_array aus? Sind das verschachtelte std::vector? Wenn ja, geht dir hier die Cachelokalität flöten. Dazu findest du genügend Threads.

SeppJ Moderator 23:31:07 25.05.2012 Titel:

Was soll denn dieses Gemesse mit clock? GCC unterstützt nativ den gprof. Einfach mit -pg (und Optimierung!) compilieren und das Programm mit einem kleinen(!) Testfall testen. Danach hat man eine sehr genaue Auflistung was im Programm wie lange braucht. Ganz ohne eigene Annahmen die das Ergebnis verfälschen. Und viel einfacher zu bekommen.

Und wie schon gesagt, kann zwischen keine Optimierung und O3 eigentlich nicht nur ein paar Sekunden von ein paar Minuten gewonnen werden. Zumindest bei "richtigen" Rechnungen sollte O3 einen Faktor 5 bis 20 bringen. Wenn dies nicht so ist, dann wirst du höchstwahrscheinlich irgendwelche Dummheiten machen, z.B. ewig lange Systemaufrufe oder riesige Kopieraktionen, bei denen die Optimierung des eigenen Programms nicht viel ausmacht.

(Es gibt in neueren GCCs, wie dem 4.7, übrigens auch noch Ofast für noch heftigere Optimierung, aber da sollte man verstehen was dies genau tut, da es die Semantik leicht verändern kann.)

ComputerCarl Mitglied 14:51:23 26.05.2012 Titel:

Also ich habe heute und gestern Abend noch einige Optionen mit dem Compiler
ausprobiert. die -Ofast liefert mir interessanter Weise falsche Ergebnisse.
Lasse ich diesen weg kommen wieder korrekte Ergebnisse. Das ist zumindest
für mich leicht irritierend. Ich weiß nicht was mit "richtigen" Rechner
gemeint ist, aber ich hab nur einen sehr kleinen und sehr, sehr alten Rechner.
Also vermute ich mal, dass das damit gemeint ist.

Der -pg flag ändert irgendwie nichts. Jedenfalls nicht in der Konsolenausgabe.
Nach Beendigung des Programms wird eine Datei.out beschrieben. Diese kann ich
jedoch nicht lesen, da nur kryptische Zeichen drin stehen. Ich weiß aber auch
nicht mit welchem Programm ich das öffnen muss.

Mein Data-Array war ursprünglich ein 3-Dim Vector. Nun ist es ein 2-Dim Array:
1-Dim ist die jeweilige "Datenpunkt", 2-Dim indexiere ich mit i * Spalte + j
selbst. Also dürften keine Cachelokalität mehr eine Rolle spielen. Oder doch?

cooky451 Mitglied 14:58:50 26.05.2012 Titel:

Na am besten ist alles am Stück (1-Dimensional) im Speicher zu halten und den Index zu berechnen.

SeppJ Moderator 15:56:51 26.05.2012 Titel:

ComputerCarl schrieb:

Also ich habe heute und gestern Abend noch einige Optionen mit dem Compiler
ausprobiert. die -Ofast liefert mir interessanter Weise falsche Ergebnisse.
Lasse ich diesen weg kommen wieder korrekte Ergebnisse. Das ist zumindest
für mich leicht irritierend. Ich weiß nicht was mit "richtigen" Rechner
gemeint ist, aber ich hab nur einen sehr kleinen und sehr, sehr alten Rechner.
Also vermute ich mal, dass das damit gemeint ist.

Der -pg flag ändert irgendwie nichts. Jedenfalls nicht in der Konsolenausgabe.
Nach Beendigung des Programms wird eine Datei.out beschrieben. Diese kann ich
jedoch nicht lesen, da nur kryptische Zeichen drin stehen. Ich weiß aber auch
nicht mit welchem Programm ich das öffnen muss.

Du bist nicht besonders gut mit diesem "Internet", oder?

http://www.tty1.net/smart-questions_de.html#answers
http://searchengineland.c ....... w-to-use-google-to-search

SeppJ schrieb:

Was soll denn dieses Gemesse mit clock? GCC unterstützt nativ den gprof. Einfach mit -pg (und Optimierung!) compilieren und das Programm mit einem kleinen(!) Testfall testen. Danach hat man eine sehr genaue Auflistung was im Programm wie lange braucht. Ganz ohne eigene Annahmen die das Ergebnis verfälschen. Und viel einfacher zu bekommen.

Und wie schon gesagt, kann zwischen keine Optimierung und O3 eigentlich nicht nur ein paar Sekunden von ein paar Minuten gewonnen werden. Zumindest bei "richtigen" Rechnungen sollte O3 einen Faktor 5 bis 20 bringen. Wenn dies nicht so ist, dann wirst du höchstwahrscheinlich irgendwelche Dummheiten machen, z.B. ewig lange Systemaufrufe oder riesige Kopieraktionen, bei denen die Optimierung des eigenen Programms nicht viel ausmacht.

(Es gibt in neueren GCCs, wie dem 4.7, übrigens auch noch Ofast für noch heftigere Optimierung, aber da sollte man verstehen was dies genau tut, da es die Semantik leicht verändern kann.)