Thema: Dual Core
Einzelnen Beitrag anzeigen
Alt 19.07.2005, 08:00   #4
alfora
Inventar
 
Registriert seit: 23.02.2001
Beiträge: 2.954


Standard

Nur noch ganz allgemein ein bissel Hintergrundinformation.

(Das ist natürlich nur eine vereinfachte Ansicht. Wer Fehler findet oder Verbesserungen anbringen will, nur zu.)

Ein Dual-Core-Prozessor verhält sich gegenüber dem Betriebssystem so, wie wenn es wirklich zwei "echte" CPUs gäbe.

Das Betriebssystem kann dann selbsttätig zwei voneinander unabhängige Prozesse auf je einer CPU laufen lassen.

Klassisches Beispiel: man schneidet gerade ein Video aber kann trotzdem ohne Zeitverlust nebenbei ein paar Effekte rendern lassen.

Innerhalb eines Prozesses (=Programm im herkömmlichen Sinn) gibt es tw. sehr viele verschiedene sog. Threads, das sind sozusagen parallele Sub-Prozesse.

Wenn die voneinander unabhängig sind, dann können sie auch problemlos (sogar selbsttätig vom Betriebssystem) auf die unterschiedlichen CPUs/Cores aufgeteilt werden.

Klassisches Beispiel: ein Thread für die Berechnung von Daten, ein Thread für die Benutzeroberfläche. Während z.B. Excel eine große Tabelle berechnet kann man trotzdem Menüs aufmachen oder Tabellenspalten vergrößern. (Ich hab jetzt nicht getestet, ob Excel das WIRKLICH kann aber das ist zumindest die Grundidee.)

Leider sind nicht alle Threads voneinander unabhängig. Man unterscheidet die folgenden Fälle (die natürlich auch für ganze Prozesse gelten):

* Lese-Lese-Abhängigkeit
* Schreib-Lese-Abhängigkeit
* Schreib-Schreib-Abhängigkeit

Wenn beide Threads nur Daten lesen wollen, dann können sie das auf jeden Fall tun, ohne den jeweiligen Partner dabei zu beeinflussen. Die Daten ändern sich ja nicht. Beispiel für Flusi: Darstellung der Landschaft und Darstellung der Wolken im Wetterradar.

Werden hingegen die Daten von jemandem geändert, dann kann es Konflikte geben. Ändert nur ein Thread die Daten, dann muss das dem anderen Thread irgendwie mitgeteilt werden. Eventuell benötigt man sogar bestimmte Synchronisationspunkte. Bei zwei Schreibern sowieso.

Jetzt gibt's in den modernen CPUs aber viele viele Zwischenspeicher: Pipelines und Caches in bis zu drei Ebenen. Diese Caches sind bei zwei CPUs/Cores voneinander unabhängig. Es muss also einen zusätzlichen Mechanismus geben, der dem Cache der zweiten CPU "sagt", dass Daten durch die erste CPU verändert wurden. Sonst würde die zweite CPU ja nur fröhlich weiter die alten Daten aus dem Cache lesen und kriegt von der Änderung nichts mit.

Genau hier ist der Punkt, wo man als Programmierer bzw. wo der Compiler dem Betriebssystem Hilfestellung geben muss. Man muss quasi dem Betriebssystem die "Erlaubnis" geben, die Threads auf mehrere CPUs aufteilen zu dürfen und welche eher nicht. Bei viel Kommunikationsaufwand zwischen den CPUs würde man ja den Geschwindigkeitsvorteil durch die Parallelverarbeitung komplett verspielen.

Das bedeutet aber, dass Programmierer ihre Programme anpassen müssen, damit sie die Möglichkeiten der modernen CPUs auch ausnützen können.

Was mich persönlich sehr wundert ist, dass erst JETZT überhaupt von dieser Möglichkeit Gebrauch gemacht wird. Multi-Prozessorsysteme und die Unterstützung durch das Betriebssystem gab es bei Microsoft schon seit Windows NT! Warum wurde das nicht schon seit Jahren in irgendwelche offiziellen Programmierrichtlinien verpackt, die vorschreiben, dass ein Programm Multi-Prozessortauglich sein muss?
____________________________________
Alex

Home Page: http://homepage.mac.com/alfora/

O\'Hare Approach Control: \"United 329 heavy, your traffic is a Fokker, One o\'clock, three miles, eastbound.\"
United 239: \"Approach, I\'ve always wanted to say this... I\'ve got the little Fokker in sight.\"
alfora ist offline   Mit Zitat antworten