Effektiver Unterschied "Dual Core" und "Dual Processor"?

CUC

CUC

Aktives Mitglied
Thread Starter
Dabei seit
19.09.2010
Beiträge
2.563
Reaktionspunkte
403
Hi!

Beschäftige mich gerade mit G5s.
Gibt es irgendeinen effektiven Unterschied zwischen "Dual Core" und "Dual Processor" Versionen?
Also 1 CPU mit 2 Kernen oder 2 CPUs mit 1 Kern?

Irgendeinen Grund, warum eines der beiden zu bevorzugen ist?
 
Der Unterschied besteht gewöhnlich darin, wie das L2-RAM angesteuert wird. Gewöhnlich teilen sich zwei Kerne in einer CPU das L2-RAM, wohingegen zwei CPUs jeweils eigenes L2-RAM mitbringen. Das hängt allerdings auch immer noch vom Design des Rechners ab, und das Teilen muss nicht unbedingt ein Nachteil sein, sofern nämlich beide Kerne am selben Thema arbeiten.
Die 2-CPU-Lösung ist die ältere Bauweise, heute sind Mehrkerner üblich. Insofern besteht oftmals nicht mal eine Wahlmöglichkeit.
 
  • Gefällt mir
Reaktionen: CUC
Bei älteren Systemen müssen CPUs noch über den langsamen Fronsidebus ihre Aufgaben absprechen, was in der Regel auch langsamere Kommunikation ist als wenn 2 Kerne auf einem Die sind.

Beim PowerPC 970MP hat scheinbar jeder Kern seinen eigenen L2 Cache

http://pc.watch.impress.co.jp/docs/2005/1028/fpf04_13.jpg
 
Jup:

PowerPC 970MP
IBM announced the PowerPC 970MP, code-named "Antares", on 7 July 2005 at the Power Everywhere forum in Tokyo. The 970MP is a dual-core derivative of the 970FX with clock speeds between 1.2 and 2.5 GHz, and a maximum power usage of 75 W at 1.8 GHz and 100 W at 2.0 GHz. Each core has 1 MB of L2 cache, twice that of the 970FX. Like the 970FX, this chip was produced at the 90 nm process. When one of the cores is idle, it will enter a "doze" state and shut down.[6] The 970MP also includes partitioning and virtualization features.

ABER: Bei 2 CPUs hat jede CPU einen eigenen FSB, beim DualCore müssen sich 2 Kerne einen FSB teilen. Wenn also mit dem RAM oder anderen Komponenten wie der GPU kommuniziert werden muss, könnte der Dual-CPU-Rechner im Vorteil sein.

Das gilt aber nur für ältere Prozessoren.
 
Der Energiebedarf dürfte idR bei zwei 1-Kernern höher sein als bei einem 2-Kerner. Aber insgesamt ist eine pauschale Aussage etwas schwer zu treffen, weil es von vielen Faktoren abhängt.
 
Dazu kommt, daß auch die Anwendersoftware auf zwei CPUs zugreifen sollte, um einen Nutzen von zwei CPUs zu haben. Das konnte in der Regel "früher" nur "Profi"software.
 
Dazu kommt, daß auch die Anwendersoftware auf zwei CPUs zugreifen sollte, um einen Nutzen von zwei CPUs zu haben. Das konnte in der Regel "früher" nur "Profi"software.

Macht es für die Software tatsächlich einen Unterschied, ob sich 4 Kerne auf zwei CPUs verteilen, oder ob es eine CPU mit 4 Kernen ist?
Ich hätte jetzt vermutet, für die Software wäre das einerlei, und es geht ihr nur um die Anzahl der Kerne an sich.
 
Natürlich macht es einen großen Unterschied. Viele vergessen hier, dass eben nicht nur ein Programm auf einem Rechner läuft.
Auch wenn man gerne möchte, dass die Software auf der man gerade arbeitet möglichst viele Kerne nutzt, muss man sich vor Augen halten das eben der Wechsel zwischen Programmen viel teurer ist.
Man muss sich nur die Prozessliste anschauen um zu verstehen, dass jeder CPU Kern heute ein Vorteil ist, egal ob Photoshop oder was auch immer gut optimiert wurde.

Noch was zu den Kernen an sich. Die ganze Idee mehrere separat funktionierende Kerne in eine CPU zu packen sind die Signallaufzeiten gewesen.
Die hohen Taktraten die man erreichen wollte haben dazu geführt das die Signale tatsächlich nicht mehr von einer Ecke zur anderen kommen.
Deshalb hat man die Funktionen vervielfacht und den Cache auf die CPU integriert.

Ein weiterer unterschätzter Aspekt ist die Reihenfolge der Instruktionen.
Moderne CPU müssen mittlerweile magische Microcode Optimierungen vornehmen damit die einzelnen Teile einer CPU auch wirklich arbeiten und nicht nur warten.

Deshalb sind moderne Compiler mit Profiling heute so wichtig.
Früher war man froh, wenn man von Hand ein paar Register Transfers optimieren konnte. Heute kann man quasi kaum noch effizient in Assembler programmieren, wenn man die darunter liegenden Microcode Optimierungen nicht kennt.

Software ist deshalb quasi heute schlechter.
Früher konnte man nicht mehr erreichen, heute hofft jeder auf die Quaität der Compiler und spezielle Vektor Operationen, die vielleicht genau das tun was man wollte.
 
  • Gefällt mir
Reaktionen: CUC
Zurück
Oben Unten