thread min sleep time



  • Youka: damit ein anderer thread auch rechenzeit bekommt?

    ich habe einen 2d vector<vector<char>> vec; // erste dimension ist die thread_id
    thread 1 greift auf vec[1] zu und schreibt in die zweite dimension
    thread 2 greift auf vec[2] zu und schreibt in die zweite dimension

    muss ich das ganze dann synchronisieren obwohl die unterschiedliche indices nehmen?



  • algoman1 schrieb:

    Youka: damit ein anderer thread auch rechenzeit bekommt?

    Das sollte der Scheduler deines Betriebssystems auch so hinbekommen. Zudem ist nichts gewonnen wenn man so viele Threads erstellt, dass die die meiste Zeit nur darauf warten die CPU zu bekommen.

    algoman1 schrieb:

    ich habe einen 2d vector<vector<char>> vec; // erste dimension ist die thread_id
    thread 1 greift auf vec[1] zu und schreibt in die zweite dimension
    thread 2 greift auf vec[2] zu und schreibt in die zweite dimension

    muss ich das ganze dann synchronisieren obwohl die unterschiedliche indices nehmen?

    Nein musst du nicht. Allerdings macht es dein Programm durch die implizite Synchronisierung (z.B. Cache-Cohärenz) wahrscheinlich sehr langsam, wenn du ständig mit verschiedenen Threads auf benachbarte Speicherbereiche zugreifst.



  • und wenn der speicherbereich als ganzes gecached wird?

    vorschlaege um es schneller zu machen?



  • algoman1 schrieb:

    und wenn der speicherbereich als ganzes gecached wird?

    Das wid er ja wahrscheinlich und genau das ist das Problem. Beide Cores haben den selben Speicherbereich im Cache und müssen den cache immer sofort aktuallisieren sobald der andere da was reinschreibt.

    algoman1 schrieb:

    vorschlaege um es schneller zu machen?

    Vectoren immer in möglichst großen, zusammenhängenden Blöcken aufteilen, also z.B. Thread 1 bearbeitet Index 0-999 und Thread 2 1000 bis 1999 usw. oder noch besser gleich die Daten für jeden Thread getrennt halten



  • So kann jemand aufschliss geben ueber das sync issue?



  • TNA schrieb:

    Nein musst du nicht. Allerdings macht es dein Programm durch die implizite Synchronisierung (z.B. Cache-Cohärenz) wahrscheinlich sehr langsam, wenn du ständig mit verschiedenen Threads auf benachbarte Speicherbereiche zugreifst.

    Das ist quark. Da wird niemals auf benachbarte Speicherbereiche zugegriffen in dem layout. Die Speicherbereiche von vec[1] und vec[2] können beliebig im RAM liegen(beachte, dass vec[i] eine Referenz auf einen weiteren std::vector zurückgibt!) und mit ziemlicher Sicherheit nicht in der selben cache line.



  • otze schrieb:

    Das ist quark. Da wird niemals auf benachbarte Speicherbereiche zugegriffen in dem layout. Die Speicherbereiche von vec[1] und vec[2] können beliebig im RAM liegen(beachte, dass vec[i] eine Referenz auf einen weiteren std::vector zurückgibt!) und mit ziemlicher Sicherheit nicht in der selben cache line.

    Hast recht, ich hatte mir den genauen Inhalt des Vectors nicht angeschaut.



  • koennen bielibig heisst aber nicht muessen?

    ich verwende den lock und start mal das benchmarking...



  • Der lock machts zu 100% langsamer.



  • otze schrieb:

    Der lock machts zu 100% langsamer.

    Definitiv. Ein Lock macht aus einem parallelen Programmabschnitt einen seriellen. Die Kunst parallele Programme zu schreiben die gut skalieren besteht unter Anderem darin, mit möglicht wenig locks, am besten gar keinem auszukommen.


Anmelden zum Antworten