ich erstelle mehrere threads die einen algorithmus in parallel berechnen...

was sollte die min sleep time in einem thread sein um zu anderen threads zu schalten? 200ns?

std::this_thread::yield();

nehmen?

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?

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.

vorschlaege um es schneller zu machen?

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

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.

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.

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

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.