RootForum Community

Moin all,

ich frage mich gerade ob es Performance-Unteschiede gibt wenn sich die CPU-Cores auf mehrere Sockel verteilen. Also:

- 1* Xeon mit 8Cores
gegen
- 2* Xeon mit jeweils 4 Cores

Wenn CPU-Typ und -Takt und sonstige Parameter gleich sind, sollten dann beide Kombinationen gleich schnell sein oder was für Unterschiede wird es geben?


Gruß, Karsten

Hi,

meine nicht ganz blöde Anlaufstelle ist hier immer das Oracle Lizenzmodell.

Die berechnen bei x86 CPUs immer nach Cores mit dem Faktor 0,5 je Core, unabhängig der Anzahl der physischen CPUs. Zumindest scheint das schon länger die Berechnungsgrundlage für AMD/Intel CPUs zu sein. ein Single Core CPU hingegen wird mit Faktor 1 gerechnet.

Nachteile 1 CPU, der Durchsatz wird durch den einen Sockel beschränkt. Ebenfalls könnte der Zugriff auf den RAM und grössere Datenverarbeitungen hier zum Bottleneck werden. Ebenfalls müssen sich, je nach Typ, die Cores den Cache teilen und haben nicht, so weit ich weiss, einen dedizierten Cache.

Nachteile 2 CPUs, die Ansteuerung und Verteilung muss das Board entsprechend unterstützten.
Die Verwaltung der CPUs sowie das Board selbst kann hier den Bottleneck darstellen.

Insgesamt dürfte aber der Unterschied nur marginal sein. Zumindest mal im typischen Betireb kaum messbar.

Wie es so immer in der EDV ist, es kommt darauf an

Zum einen hängt es am OS-Scheduler, ob es einen (meßbaren) Performance-Unterschied (jenseits der normalen statistichen Streuung) gibt oder nicht. Das Stichwort hier heißt topologisches Scheduling. Bei aktuellen Multi-Core CPUs teilen sich alle Kerne der CPU einen gemeinsamen L2-Cache. Wird ein Prozess vom Scheduler immer wieder von CPU zu CPU (Sockel) "herumgeschubst", werden die ganzen tollen Cache-Logiken (u. a. instruction prediction usw.) böse ausgehebelt; mehrere Sockel sind in diesem Fall gegenüber weniger Sockeln im Nachteil. Bleibt ein Prozess jedoch auf demselben Sockel, bleiben auch die zugehörigen Cache-Einträge erhalten, und die CPU-Leistung wird deutlich besser ausgeschöpft.

Zum anderen ist natürlich zu bedenken, dass 8 Kerne auf einer CPU sich auch nur einen gemeinsamen L2-Cache teilen. Der ist zwar i.d.R. größer als auf einer CPU mit weniger Kernen; Operationen auf dem L2-Cache können AFAIK aber nur sequenziell, nicht parallel ausgeführt werden. Daher würde ich vermuten, dass dieser Faktor einen leichten Bremseffekt hat - das müsste aber jemand bestätigen, der das schon mal ausprobiert hat. Insbesondere wo hier die Grenze liegt - wäre mal interessant, das zu erfahren... :-?

Und zu guter Letzt muss man sich den Anwendungsprozess selbst noch anschauen. Läuft auf dem Server ein Dienst der Sorte "ein Fetter Prozess, viele Threads" (z. B. MySQL), könnte ich mir vorstellen, dass dieser eher von der Konfiguration "wenige Sockel, viele Kerne" profitieren würde (auch hier wieder: je nachdem, wie der OS-Scheduler tickt, und wie er mit Threads umgeht).

daemotron wrote:Operationen auf dem L2-Cache können AFAIK aber nur sequenziell, nicht parallel ausgeführt werden.

Das hängt von der Architektur der CPU ab: Bei x86 ist das zutreffend, bei RISC ist es zum Beispiel parallel. Deshalb kommt RISC auch mit erheblich weniger GHz auf deutlich höhere Performance.

Bei Multisockel ist nur der Interconnect also die Datenverbindung zwischen den einzelnen Sockeln der bremsende Faktor, ansonsten bringt Multisockel nur Vorteile. Zum Einen lassen sich Anwendungen auf die Sockel verteilen, so dass beispielsweise das OS und der Kleinkram auf dem ersten Sockel laufen und fettere Prozesse wie MySQL exklusiv auf dem zweiten Sockel. Dadurch kann MySQL auf Volllast laufen, während der Rest des Systems idled und der erste Sockel so Stromsparfunktionen nutzen kann. Desweiteren bremst MySQL so auch das OS und die anderen Anwendungen trotz Volllast nicht aus.

Problematisch wird Multisockel eben erst, wenn der Cache-Ping-Pong zwischen den Sockeln anfängt, da dadurch wie bereits geschrieben, sämtliche Cachingfunktionen des OS mehr oder weniger ausgehebelt werden. Denn der Transfer der Cacheinhalte von einem Sockel zum Anderen dauert physikalisch bedingt wenige Milisekunden (abhängig von der Länge, Dicke und Qualität der Leiterbahn auf der Platine).

Wenn man das beachtet und etwas mit dem Scheduler trickst, dann ist Multisockel definitiv zu bevorzugen.

Joe User wrote:

daemotron wrote:Operationen auf dem L2-Cache können AFAIK aber nur sequenziell, nicht parallel ausgeführt werden.

Das hängt von der Architektur der CPU ab: Bei x86 ist das zutreffend, bei RISC ist es zum Beispiel parallel. Deshalb kommt RISC auch mit erheblich weniger GHz auf deutlich höhere Performance.

Stimmt so nicht. SPARC64 als auch Niagara sind 2 RISC Prozessoren Typen, deren Charakteristika nicht unterschiedlicher sein könnte.
Entscheidender Unterschied, Niagara hat nur einen 2. Level Cache und zwar für alle Cores geshared.
Der SPARC64 hat meines wissens dedicated 1. und 2. Level Cache.
Man unterscheidet zwischen dem Niagara und SPARC zwischen Threads und Cores.

Das Problem am Niagara, durch den shared buffer, je CPU kann je nach Rechenoperationen der Durchsatz und die Leistung auf theoretisch 1/8 der theoretischen Gesamtleistung "zusammen brechen". Geschuldet ist es der Reservierung des Caches für den jeweiligen Core. Umso komplexer die Rechenoperationen um so mehr wird der Durchsatz daran gemindert. Hat Daemotron schon gut beschrieben.
Das Lizenzmodell von Oracle zeigt den wesentlichen Unterschied in der Praxis, gut auf.

Hingegen ist der SPARC64 erhebliche Robuster bei der parallelen Ausführung von Prozessen und skaliert Verhältnismässig lang sehr stabil und linear mit zunehmenden gleichzeitigen Operationen.

Im Vergleich der Rechenleistung haben allerdings die AMD Cores kaum ein nachsehen zu den Sparc CPUs.
Ähnlich wie die Niagare CPUs, reagieren diese auf dynamische Laständerungen sehr agil allerdings skalieren diese eben auch mit einer , wenn auch deutlich geringeren Toleranz, bei zunehmender paralleler Last.

Der Toleranzbereich bei einigen Datenbanktests lag hier bei ca. 5-10% (x86) CPUs.
Das getestete System war Sun Solaris 10.

Für mein empfinden lag beim Benchmark der AMD sogar vorne. Die Zahlen selber sagten, leicht dahinter.

Da ich schon länger nichts ernsthaftes mehr mit Linux gemacht habe - wie ist denn dort der Stand bezüglich topologischem Scheduling? Kann man dort bestimmte Prozesse an einen bestimmten Sockel binden, oder wie anno dazumal nur an ein bestimmtes CPU-Device?