?
XSpille schrieb:
Jeder Thread hat einen eigenen Vektor. Deine Aussage ist daher (wie ich denke) falsch.
Ah ja... War gestern etwas in Eile. Mein Fehler...
Pikkolini schrieb:
Das der Hauptspeicher nicht schneller wird ist klar. Aber wird der schon der Flaschenhals, wenn ich auch nur eine Variable schreiben will?
DDR-400 hat eine Datenrate von 3.2 * 10^9 Bytes pro Sekunde. Eine double Variable hat 8 Bytes. Ein moderner x86 kompatibler Prozessor kann pro Takt und pro Kern 2 Gleitkommaberechnungen durchführen. Gehen wir (der Einfachheit halber) von einem 3.2 GHz Prozessor aus, so kann der Prozessor 16 mal so schnell Gleitkommazahlen berechnen, wie er sie in den Speicher schreiben kann. DDR2-1066 schafft 8.533 ^ 10^9 Bytes pro Sekunde. Da ist der Prozessor immer noch um einiges schneller.
Der Prozessor hat noch einen Cache. Der macht die Sache schneller. Wenn man aufpasst, dann ist das Problem nicht so groß. Wenn man nicht aufpasst, kann es sein, dass der Code durch den Cache langsamer läuft.
Um deine Frage zu beantworten: Falls die Berechnung trivial ist, dann wird der Speicher der Flaschenhals. Du musst auch bedenken: Du schreibst ja nicht nur eine Variable. Der Zustand der rand Funktion muss gesichert werden. Und ein vector<T>::push_back hat auch einiges an Speicher zu verwalten.
Pikkolini schrieb:
Und mit dem Problem mit rand() und der Threadsicherheit. Nach den ganzen google Ergebnissen, die ich durchforstet habe, deute ich die Threadunsicherheit von rand() so, dass grob gesagt einfach in den verschiedenen Threads die gleichen Zahlen erzeugt werden. Aber wenn ich ich mit srand() vor jedem Aufruf von rand() benutze, sollte das Problem doch behoben sein.
Bitte korrigiert mich, wenn ich falsch liege.
Du liegst Falsch.
Mit welchem Parameter willst du denn srand Aufrufen? Macht keinen Sinn.
Und selbst wenn: Wenn du den Aufruf von rand und srand nicht in einen Mutex packst, dann rufen mehrere Threads gleichzeitig srand mit verschiedenen seeds auf und überschreiben gegenseitig jeweils die Werte des anderen. Und wenn du dann rand aufrufst, dann kriegst du im schlimmsten Fall in allen Threads einen Wert von rand zu einem seed, der eine Mischung aus den seeds der Verschiedenen Threads ist. Z.b. die ersten 2 Byte des ersten Threads und die letzten 2 Bytes des zweiten Threads. Aber in allen Threads den selben Wert.
Wenn du aber einen Mutex verwendest, dann läuft dein Code wieder vollkommen seriell ab. D.h. er wird durch die Threads nur langsamer.
Und mal zu dem, vor dem dich die anderen warnen:
Du arbeitest mit Zufallszahlen. Du hast also keine Möglichkeit, überhaupt zu überprüfen, ob die Ergebnisse richtig sind.
Und Threads sind sehr böse. Da jetzt die Reihenfolge der Befehle nicht mehr fest steht, in der die Aktionen ausgeführt werden, kann es sein, dass ein Fehler nur ein einem von zehn Fällen zum Vorschein kommt. Das macht das Debuggen extrem schwierig.
Wenn du also nicht genau weißt, was du tust, wirst du Fehler in deine Programme bauen, die extrem schwer zu finden sind und vollkommen unerwartet auftreten. Und wenn du irgendwelche Berechnungen machst, wird es noch schlimmer. Weil du die Fehler nicht mal mehr siehst. Die Ergebnisse sind einfach hin und wieder mal falsch...
Also achte drauf, nur Funktionen zu verwenden, die als thread-safe ausgewiesen sind! Also z.B. rand_r . Und schau dir ruhig noch ein wenig mehr Theorie zu der Materie an.
