3. OpenMP Schleife langsamer als serielle Schleife?

OpenMP Schleife langsamer als serielle Schleife?

  • G

    Hallo zusammen,

    ich wollte ausprobieren einige Schleifen in meinem Programm zu paralellisieren und bin dabei auf OpenMP gestoßen.

    Ich habe dies wie folgt eingebunden:

    #pragma omp parallel for
for (int k=0;k<nodes.size();k++)
	{	
		vector<double> axe(3);
		axe=middlepaxis(&ax,&elements,&nodes,&nodes[k],1);
		output<<axe[0]<<" "<<axe[1]<<" "<<axe[2]<<endl;

	}

    Header usw. sind alle eingebunden und omp im Compiler ist auch aktiviert. Es funktioniert also eig. alles. Jedoch benötigt diese Schleife deutlich länger als die Schleife ohne die Parallelisierung. Mach ich was falsch?

    Freu mich auf eure Antworten.

    LG
    Gebb 🙂

    0
  • Mod

    Wie groß ist nodes.size()? Das sollte mindestens ein paar Tausend, besser mehr, sein.

    Außerdem sollte eine Schleife mit Ausgabeoperationen (erst recht wie hier mit einem anschließenden flush) sowieso durch das Ausgabegerät begrenzt sein, insofern wirst du nie etwas gewinnen.

    0
  • T

    sorry falsch gelesen..

    Es hängt von der Anzahl der Durchläufe..

    0
  • G

    SeppJ schrieb:

    Wie groß ist nodes.size()? Das sollte mindestens ein paar Tausend, besser mehr, sein.

    In diesem Fall sind es knapp 200. Es können aber durchaus über mehrere Tausend werden, ist nur ein Testfall der Software.

    SeppJ schrieb:

    Außerdem sollte eine Schleife mit Ausgabeoperationen (erst recht wie hier mit einem anschließenden flush) sowieso durch das Ausgabegerät begrenzt sein, insofern wirst du nie etwas gewinnen.

    Das versteh ich jetzt nicht. (Sorry bin noch nicht sooo fortgeschritten ;))
    Was meinst du mit Ausgabegerät begrenzt?
    Wie könnte ich es ändern das es was bringt, wenn dies zu diesem Zweck überhaupt geht.

    0
  • Mod

    Gebb schrieb:

    SeppJ schrieb:

    Wie groß ist nodes.size()? Das sollte mindestens ein paar Tausend, besser mehr, sein.

    In diesem Fall sind es knapp 200. Es können aber durchaus über mehrere Tausend werden, ist nur ein Testfall der Software.

    Wenn nicht jeder Schleifendurchgang sehr lange dauern sollte, dann ist der Aufwand der Parallelisierung größer als der Gewinn 👎 .

    SeppJ schrieb:

    Außerdem sollte eine Schleife mit Ausgabeoperationen (erst recht wie hier mit einem anschließenden flush) sowieso durch das Ausgabegerät begrenzt sein, insofern wirst du nie etwas gewinnen.

    Das versteh ich jetzt nicht. (Sorry bin noch nicht sooo fortgeschritten ;))
    Was meinst du mit Ausgabegerät begrenzt?
    Wie könnte ich es ändern das es was bringt, wenn dies zu diesem Zweck überhaupt geht.

    Wenn ein Koch 10 Kartoffeln in 25 Minuten kochen kann, wie lange brauchen dann 10 Köche für die gleiche Aufgabe?

    Wenn output irgendein periphäres Ausgabegerät ist (Bildschirm, Festplattendatei, o.Ä.), dann ist das Gerät der bremsende Faktor der Schleife, weil es einfach nicht schneller ausgeben kann, egal wieviel parallel kommt. Außerdem wird dann natürlich die Reihenfolge total durcheinander sein und insbesondere muss der Ausgabestream auch noch threadsicher sein, was hier sicherlich nicht gegeben ist, da du nicht dran gedacht hast.

    0
  • G

    Danke, jetzt hab ichs 🙂

    0
  • G

    insbesondere muss der Ausgabestream auch noch threadsicher sein, was hier sicherlich nicht gegeben ist, da du nicht dran gedacht hast.

    Eine Frage habe ich noch. Wie würde ich das Threadsicher machen? Ich habe da gerade ein bisschen gelesen und mich informiert, aber so richtig steig ich da noch nicht dahinter.

    0
  • T

    In deinem Fall gar nicht.. Die „omp parallel for“ teilt deinen vector (?) in gleich große Stücke quasi auf und bearbeitet die gleichzeitig.

    0
  • Mod

    Gebb schrieb:

    insbesondere muss der Ausgabestream auch noch threadsicher sein, was hier sicherlich nicht gegeben ist, da du nicht dran gedacht hast.

    Eine Frage habe ich noch. Wie würde ich das Threadsicher machen? Ich habe da gerade ein bisschen gelesen und mich informiert, aber so richtig steig ich da noch nicht dahinter.

    Durch einen Mutex.

    0
  • T

    dadurch kriegt er die Ausgabe aber immer noch nicht in die richtige Reihenfolge. Er kann höchstens erst die alles vorbereiten ( vorrechnen ) und dann nacheinander ausgeben. In dem Fall, wenn ich es richtig lese braucht er nix zu synchronisieren.

    0
  • Mod

    Travor schrieb:

    dadurch kriegt er die Ausgabe aber immer noch nicht in die richtige Reihenfolge. Er kann höchstens erst die alles vorbereiten ( vorrechnen ) und dann nacheinander ausgeben. In dem Fall, wenn ich es richtig lese braucht er nix zu synchronisieren.

    Nein, die Reihenfolge ist natürlich hin. Das lässt sich auch Prinzipbedingt gar nicht parallelisieren, falls es auf die Reihenfolge ankommt. Aber durch den Mutex verhindert er, dass komische Sachen mit dem Stream geschehen, wenn gleichzeitig aus mehreren Threads geschrieben wird.

    0
Anmelden zum Antworten