Theoretische Frage zu Dual vs Single Core

[Morpog]

So, dank registrierungszwang hab ich mich nach 5-6 Jahren als Gast mal angemeldet :-)

Aber jetzt zu meiner Frage:

Wird eine Single Core CPU Software die auf Dual Core (also mehrere threads) optimiert ist langsamer verarbeiten?

Oder wird das ähnlich wie in 3D Engines (ala Doom3) durch verschiedene "Renderpfade" umgangen?

[Ganon]

Öhm, "Ja". Fragt sich nur ob es messbar ist. Das liegt dann am Betriebssystem und der Programmierung der Software.

Denn die ganze Thread-Verwaltung kommt ja nun hinzu.

[andr_gin]

Etwas langsamer wird es schon, da bei einem Threadwechsel immer etwas Aufwand vorhanden ist und in dieser Zeit kann kein anderer Thread abgearbeitet werden. Messbar wird das allerdings kaum sein.

Der eigentliche Nachteil an mehreren Threads ist, dass die Programmierung viel schwieriger ist, da sich hier eine Menge Fehler einschleichen können, die nicht vorhersagbar sind und nur manchmal auftreten, was die Fehlerbehebung fast unmöglich macht. Hier einmal ein Beispiel:

1.) Die Variable hat den Wert 5.
2.) ThreadA ist am Arbeiten und liest den Wert aus.
3.) ThreadA erhöht diesen Wert um 1 (5+1=6)
4.) ThreadB kommt an die Reihe, liest den Wert 5 aus.
5.) ThreadB erhöht diesen Wert um 2 (5+2=7)
6.) ThreadB schreibt den Wert 7 an die Variable zurück
7.) ThreadA kommt wieder an die Reihe und schreibt seinen Wert 6 zurück

Und schon haben wir 5+1+2 = 6 gerechnet und unser schönes Programm wird wahrscheinlich ziemlich bald crashen. Leider passiert diese Situation nur ca. alle 1.000 Durchläufe. Der Fehler äußert sich nur dadurch, dass das schöne Spiel dann alle 5 Minuten abkratzt und keiner weiß warum. Man kann sich dann den ganzen Code durchschauen, da es im Einzeltest ja wunderbar funktioniert.

[SGT.Hawk]

Na ja, so schlimm ist es auch wieder nicht.Es ist nur ein höherer Aufwand bei der Programmierung, da man nicht mehr rein sequentiell denken kann.:eek:
Nicht umsonst gibt es Synchronisationsmechanismen, die solche Race Conditions unterbinden.Stichwort Mutex, Semaphoren usw.:wink:

[Coda]

Klar, aber die vergisst man auch mal aus versehen ;)

[GloomY]

Ich nehme mal an, dass wir von korrekten Programmen ausgehen können, d.h. überall wo wechselseitiger Ausschluss für den Zugriff auf Variablen benötigt wird, ist dies über entsprechende Synchronisationsobjekte geregelt.

Dann stellt sich die Frage nach der Performance. Ich gehe davon aus, dass die Synchronisation der Threads einen nur unerheblich kleinen Anteil an der gesamten Ausführungszeit hat, denn sonst würde sich die Parallelisierung auf mehere Threads ja gar nicht lohnen.

Unter dieser Annahme kann man die Frage des Threadsstarters eigentlich verneinen. Oder genauer gesagt dürfte sich der Verlust im Bereich von Null bis "nicht sehr groß" bewegen. :)

[andr_gin]

Nicht umsonst gibt es Synchronisationsmechanismen, die solche Race Conditions unterbinden.Stichwort Mutex, Semaphoren usw.:wink:

Natürlich kann man das unterbinden. Es geht ja nicht darum, dass sich die Threads bei korrektem Code in die Quere kommen, sondern darum, dass man den Fehler unmöglich finden kann, wenn man irgendwo eine Variable zu wenig gesperrt hat, da es nicht reproduzierbar ist. Bei anderen Fehlern kann man davon ausgehen, dass gleiche Eingaben zu dem gleichen Ergebnis führen.

[don_salieri]

Natürlich kann man das unterbinden. Es geht ja nicht darum, dass sich die Threads bei korrektem Code in die Quere kommen, sondern darum, dass man den Fehler unmöglich finden kann, wenn man irgendwo eine Variable zu wenig gesperrt hat, da es nicht reproduzierbar ist. Bei anderen Fehlern kann man davon ausgehen, dass gleiche Eingaben zu dem gleichen Ergebnis führen.Stimmt, das ist eine echte Herausforderung. Daher gilt hier besonders:
testen, testen, testen, und immer an die User denken ;)

[Coda]

Unter Linux gibt's für sowas ja valgrind. Nur leider für Windows nicht :(