Nicht auf gleicher Ebene. Wollen wir mal versuchen das als Eisenbahn-Strecke zu verdeutlichen xD Eine CPU soll nun also eine Eisenbahnstrecke sein. Irgendwo beginnt sie, hat mehrere Zwischenstationen und irgendwann endet sie. Wird glaub ich normalerweise Pipeline genannt. Eine Berechnung oder irgendein Befehl (eine Zugfahrt) an die CPU braucht nun selten alle Teile (Zwischenstationen) der Pipeline. Meinetwegen haben wir da eine Öl-Quelle, nen Holzwerk und ne Eisenmine in einer ABC strecke vereint (jetz mal die Sinnhaftigkeit völlig aussen vor gelassen ^^). jetzt kommt da ein Befehl (ein Zug), der nur Öl und Holz anfahren muss - der lässt also Eissen aussen vor und unbenutzt. Kommt ein zweiter Befehl/Zug, der jetzt nur Eisen benötigt, so kann er im selben Durchlauf auf die Strecke - man kann also 2 Züge in einem Rutsch bedienen. Das ist bei HT wie bei MC so. Ist der 2. Zug allerdings auch an Öl oder so mit interessiert, dann sagt HT ganz einfach: nö, is nich - schon belegt. Bei Multicores hast du aber quasi 2 seperate Strecken - der 2. Zug kann also durchaus ebenfalls benutzt werden.
Das is sicherlich jetzt sehr abgespeckt beschrieben, aber ich hoffe, es verdeutlicht die Problematik etwas. Generell muss man auch den Grad der Parallelisierbarkeit betrachten. Was für ein Problem könnte man haben? Wir brauchen auf jedenfall ein mehrteiliges Problem 
Meinetwegen irgendeine Berechnung in mehreren Schritten, jeder Schritt baut auf dem Ergebnis des vorangegangenen auf - das is rein garnix parallelisierbar. Bevor der 2. Teil berechnet werden kann, muss auf das Ergebnis des 1. gewartet werden usw usf. Könnte zum bsp die Ermittlung des Weges eines Sims sein. Oder etwas erweiterte Betrachtung: Bewertung aller Möglichkeiten mit anschließender Bewertung und Selektion. Algorythmus könnte so aussehen:
for each(line as L) {
dauer = berechne_dauer(L);
linien[index_L] = dauer;
}
sortiere(linien, minimum);
wähle(linien[0]);
Bitte unbedingt als Pseudocode verstehen Was wäre hier parallelisierbar und was nicht? die foreach wäre definitv parallelisierbar, da jede Fahrzeitberechnung völlig unabhängig voneinander funktioniert. Nur beim Speichern in das linien-Array/Liste müsste man eben wegen kritischem Bereich bla aufpassen. Das Sortieren hingegen ist nicht parallelisierbar, da alle Ergebnisse miteinander (in Abhängigkeit zueinander) verglichen werden müssen. Auch ist der frühestmögliche Ausführungszeotpunkt fürs sortieren erst dann erreicht, wenn alle Ergebnisse vorliegen.
Was könnte man sich noch vorstellen? Das war jetzt ein einzelner Sim. Diese Berechnung wird aber für alle Sims beim Erstellen benötigt. Und kein Sim schert sich um den anderen also wäre das voll parallelisierbar. Jeder einzelne Sim kann seine Entscheidungen unbeflusst von den anderen Treffen - parallel.
Jetzt die nächste Frage: Wo ist der Grad höher? Dazu die Frage: Wieviele parallelisierbare Elemente bieten sich an? Bei dem ersten Bsp mit der foreach wären das meinetwegen 2 linien. oder im Endausbau irgendwas im Bereich von 100? Auch wenn viele davon sicher verworfen werden, weils zu lange dauert (also mal angenommen, es geht darum zu ermitteln, wo kann ich den überall hin), sollten alle mal gecheckt werden. Und dann haben wir noch die Sims. Anfangs hat sone Stadt an die 250 Einwohner rum. Bei kleinen Karten mit 6 Städchen oder so also ~1200 Sims. 100-200 Linien im "Extremfall" vs 1200 Sims allein als Minimum? Klar, dass sich bei den Sims der theoretische Vorteil von Parallelisierung um ein vielfaches größer auswirkt. Wieso theoretisch? Nunja, wieviele Kerne hat man denn so im Schnitt in heutigen Rechnern? 2-4 oder 1200-20000? 
Knallt man der CPU nun seine endgeilen 1200 Threads für jeden Sim vor die Füße, wird die sich mit ihren 4 Kernen (4 reell parallel bearbeitbare Threads) aber freuen! Die CPU wird mehr mit shedulen wie mit arbeiten zu tun haben ><
Ihr seht, Multicore-Support sagt sich in der heutigen Zeit immer so leicht - dabei ist es bei weitem nicht so trivial wie es klingt.
