Multicore CPUs

[mainziman]

Hallo,

folgendes ist schon etwas merkwürdig; habe 2 PCs
einer mit 32 GB RAM und einer Core-i7-3820 CPU (a) und
einer mit 16 GB RAM und einer Core-i7-2600 CPU (b)
(a) läuft ausschließlich mit WinXP x64 und (b) wahlweise mit WinXP x64 od. Win7 64-bit

dieser Benchmark hat es echt in sich ...
https://software.intel.com/en-us/articl ... k-download

läuft er direkt am Host, dann hätte (a) 26 GFlops, (b) unter XP ebenfalls 26 GFlops, aber mit Win7 stolze 48 GFlops; des alleine kommt einem schon mehr als Spanisch vor ...
während der Laufzeit dieses Benchmarks sind im Takmanager nur die linken 4 CPUs belegt; die anderen 4 CPUs sind frei;

läßt man diesen Benchmark in einer VM laufen, der man am Guest 1 CPU mit 8 Kernen(!) gibt, passiert etwas noch seltsameres;

am Rechner (a) erreicht dieser in einer Win7 64-bit VM stolze 45 GFlops und in einer WinXP x64 VM fast 47 GFlops; und jetzt das merkwürdige:

native steht sowas im Ausgabe-File:

CPU frequency: 3.699 GHz
Number of CPUs: 1
Number of cores: 4
Number of threads: 8

in der VM allerdings

CPU frequency: 3.691 GHz
Number of CPUs: 1
Number of cores: 8
Number of threads: 8

und während der Laufzeit sind alle 8 CPUs im Taskmanager ausgelastet; und die Gesamtlaufzeit verkürzte sich von knapp 1,5 Stunden auf etwa 0,75 Stunden;

ist das logisch?

[Gad]

Die VM weiß nicht das einige CPUs die sie sieht nur virtuell sind (HT) ergo geht die VM davon aus dass Sie 8 CPU mit der entsprechenden Frequenz hat.

Das System direkt auf der Maschine weiß das nur 4 reale Kerne da sind und die 4 anderen nur HT.

[mainziman]

ja das wäre mir schon klar; aber der Benchmark stammt von Intel, und Intel wird ja doch wissen, wie sie die CPU "ausquetscht", oder nicht?

[JustMe]

"Wissen" werden die das schon, aber wenn sie wegen des zwischengeschalteten Hypervisors nicht so richtig an die Hardware "drankommen", dann hilft denen das wenig.

Und dass sie nicht richtig "drankommen", sagt ja schon der geloggte Hinweis zu vorhandenen 8 Cores, die es bei dem verwendeten Typ Prozessor halt ueberhaupt nicht geben kann...
Wenn also nicht einmal eine Plausibilitaetspruefung fuer den gefundenen Prozessor durchgefuehrt wird, dann sind m.E. auch die anderen Informationen zumindest interpretationswuerdig, und nicht z.B. mit dem "Amen in der Kirche" (oder Vergleichbarem anderer Konfessionen) zu verwechseln.

[Supi]

Also ich lese aus deinen Ergebnissen nur, dass der Bechnmark unter Windows XP 64bit direkt auf einem PC nicht 100% sauber läuft.
Was auch immer VMWARE dann unter XP 64 einer VM dann macht, es hilft wohl aber, das das XP64bit virtualisert besser den Host auslastet.

Beides, also XP64bit als auch volle Auslastung eines Host durch eine VM, sind aber sehr spezielle Anwendungsfälle.

http://kb.vmware.com/kb/1010184

Wenn man hier zwischen den Zeilen liest, läuft dein XP64 als Server 2003 64bit Kopie ja maximal mit 4 CPU's je Sockel.

[mainziman]

@JustMe: eben nicht; genau wenn VM dazwischen"hängt" wird sie ausgequetscht; wenn es native am Host läuft, ist nur die halbe CPU beschäftigt;

@Supi: XP bzw. XP x64 haben ein Limit von 2 CPU-Sockeln, von daher weiß ich nicht was XP hier als VM wirklich erkennt, zumal ich ja im XP x64 Guest im Task-Manager alle 8 "CPUs" habe, genau wie auch am Host selbst ...

wobei anders gefragt: in der VMware WS hat man die Möglichkeit bei der CPU nicht nur die Anzahl anzugeben sondern sowohl CPUs als auch Cores;
was bewirkt die Einstellung von 1 CPU mit 8 Kernen im Vergleich zu 2 CPUs mit 4 Kernen od. 4 CPUs mit 2 Kernen od 8 Single-Core CPUs beim Verhalten der VM?

[irix]

@Supi: XP bzw. XP x64 haben ein Limit von 2 CPU-Sockeln, ..
.. was bewirkt die Einstellung von 1 CPU mit 8 Kernen im Vergleich zu 2 CPUs mit 4 Kernen od. 4 CPUs mit 2 Kernen od 8 Single-Core CPUs beim Verhalten der VM?

Sie bewirkt das man auch einer WinXP VM mehr CPUs geben kann. Sprich 1x 8 oder 2x4. Aber nicht 8x1 oder 4x2 da die Anzahl der Sockel unter WinXP limitiert war.

Leistungstechnisch bzw. aus der Sicht des Hosts macht das keinen Unterschied. Dieser muss 8 logische CPUs bereitstellen fuer die VM. Ob sich ein virtualisiertes WinXP evtl. besser Verhaelt unter geringer Last mit 1x8 bzw. 2x4 kann ich nicht sagen. Fakt ist das ein WinXP nicht weiss das es virtuell und sich was das CPU Scheduling angeht nicht optimal verhaelt.

Gruss
Joerg

[mainziman]

Ok, soweit klar;

hier etwas "Geschichte": damals unterstützte Win2K erstmalig mit SP4 (od. doch schon mit SP3) die ersten Intel CPUs (P4) mit HT; davor waren die Threads ungenutzt;
von daher würde es mich interessieren, ob man darauf Einfluß hat, ob eine VM echte Cores od. doch nur Threads bekommt ...

bei entsprechender unorthodoxer Programmierung bremsen sich zwei CPU-Threads gegenseitig aus; mit zwei Cores läuft es aber immer echt parallel;

[JustMe]

@JustMe: eben nicht; genau wenn VM dazwischen"hängt" wird sie ausgequetscht; wenn es native am Host läuft, ist nur die halbe CPU beschäftigt;

Wieso nicht? Das steht doch nicht im Widerspruch zu dem, was ich schrieb...
Edit: Und entspricht im Uebrigen genau dem, was Gad auch schon schrieb. /Edit

Du hast insgesamt 4 Kerne. Die 4 HT-Nachgeburten sind keine echten Kerne. Wenn der Hypervisor aber insgesamt 8 "Kerne" (d.h. vCPU) signalisiert, dann versucht der Benchmark, der in der VM die HW nicht korrekt erkennen kann, auch diese 8 Kerne zu verwenden. Dass diese 8 "Kerne" nur von einer einzigen Quad-Core-CPU kommen, kann er nicht ermitteln.
Wenn er dagegen direkt auf der HW laeuft, erkennt er korrekt, dass es absolut sinnlos ist, die HT-Fakes auslasten zu wollen, wenn die 4 "echten" Kerne schon brummen.

Und das "ausgequetscht" will ich mal dahingestellt lassen.

Aber um es vielleicht noch etwas zu ergaenzen:
Die Einstellung in WS erlaubt, die CPU-Praesentation in der VM hinsichtlich Cores/Socket anzupassen. Das hat an sich erst einmal mit Hyper-Threading ueberhaupt nichts zu tun. Das OS in der VM bekommt eben die genannte Konfiguration zu Gesicht. Ob man hier nun echte Kerne bereitstellt, oder mit HT schummelt, ist der WS egal.
Ich koennte mir vorstellen, dass auch die WS zwischen echten Kernen und HT unterscheiden kann (so wie der ESXi-Hypervisor), aber sicher wissen tu ich es nicht. Und das wuerde sich dann auch eher auf das Ausfuehren von mehreren VMs parallel auswirken, und vmtl. nicht bei einer einzigen VM direkt bemerkbar sein.

[mainziman]

Wieso nicht? Das steht doch nicht im Widerspruch zu dem, was ich schrieb...
Edit: Und entspricht im Uebrigen genau dem, was Gad auch schon schrieb. /Edit

doch steht schon im Widerspruch; weil in der VM ist die Laufzeit nur knapp mehr als die Hälfte ..., also kommen die schon dran;

mehr nachfolgend;

Du hast insgesamt 4 Kerne. Die 4 HT-Nachgeburten sind keine echten Kerne.

offensichtlich aber doch 8 CPUs bzw. Kerne, weil mit zwischengeschaltetem "Hypervisor" kann die verfügbare Rechenleistung nicht vermehrt werden ...

Wenn er dagegen direkt auf der HW laeuft, erkennt er korrekt, dass es absolut sinnlos ist, die HT-Fakes auslasten zu wollen, wenn die 4 "echten" Kerne schon brummen.

was im Widerspruch zur Leistung mit zwischengeschaltetem "Hypervisor" steht; ...

Das OS in der VM bekommt eben die genannte Konfiguration zu Gesicht. Ob man hier nun echte Kerne bereitstellt, oder mit HT schummelt, ist der WS egal.

auch wenn mit HT geschummelt wird, müssen es zwangsreise autarke Recheneinheiten sein, weil spätestens wenn man auf so einem System bereits 4 VMs mit je einer virtuellen CPU, welche bis zum Anschlag in Verwendung sind, am laufen hat, es unmöglich wäre weitere solcher VMs laufen zu lassen ...

[JustMe]

Kurz zusammengefasst:

A) Es darf jeder glauben, was er (oder sie) will.
B) Es darf jeder solchen Marketing-Hypes wie HT aufsitzen, wie er (oder sie) will.

Der HT-Leistungszuwachs ist anwendungsbezogen sicherlich von 0 verschieden, aber genauso sicher weit von der Verdoppelung entfernt. Die Meinungen zur Ausbeute gehen da auseinander, und haengen stark von der verwendeten Messung und Messmethode ab ("Wer misst, misst Mist").

es unmöglich wäre weitere solcher VMs laufen zu lassen

Das wiederum hat absolut nichts mit dem von mir Geschriebenen zu tun, und die Schlussfolgerung bzgl. der autarken Recheneinheiten ist schlicht falsch. Was genau sich "echter" und "ge-fake-ter" Kern teilen (muessen), ist mit ein wenig Web-Recherche identifizierbar.
Der Hypervisor verteilt die vorhandene Rechenleistung auf die laufenden Maschinen. Wenn mehr Kerne zugewiesen als HW-technisch vorhanden sind, dann heisst das nur, dass die VMs halt nicht mehr 100% der Faehigkeit eines Kernes zugewiesen bekommen (koennen). Angenommen, man hat nur 1 Kern, aber zwei VMs mit je einem Kern am laufen, dann bekommt jede davon nur knapp 50% der vorhandenen CPU-Ressourcen (gleiche Aufgabe vorausgesetzt, und Hypervisor-Overhead abgezogen). Trotzdem meinen BEIDE VMs, dass sie "IHRE" CPU zu 100% auslasten wuerden.

[Dayworker]

Der HT-Leistungszuwachs ist anwendungsbezogen sicherlich von 0 verschieden, aber genauso sicher weit von der Verdoppelung entfernt. Die Meinungen zur Ausbeute gehen da auseinander, und haengen stark von der verwendeten Messung und Messmethode ab ("Wer misst, misst Mist").

Ausgehend von meiner BOINC-Erfahrung mit Primegrid, kann ich sagen, daß alle Integerberechnungen dank HT bis zu 40% zulegen und für Gleitkomma oder bei Nutzung spezieller CPU-Funktionen (AVX, FMA) der HT-Gewinn nur Null oder deutlich negativ ist.

Du hast insgesamt 4 Kerne. Die 4 HT-Nachgeburten sind keine echten Kerne.

offensichtlich aber doch 8 CPUs bzw. Kerne, weil mit zwischengeschaltetem "Hypervisor" kann die verfügbare Rechenleistung nicht vermehrt werden ...

Ob mit oder ohne aktiviertem HT hat deine CPU nur 4 Kerne. Mit aktivem HT werden jedoch zwei logische Kerne auf einem physikalischen CPU-Kern abgebildet.



Stichwort Linpack...
Jedwede Performancemessungen innerhalb jeder Virtuellen Maschine (VM) sind geraten, da die Zeit in einer VM immer in Abhängigkeit zur Auslastung von Host und Gast steht und somit variabel ist. Da der Hypervisor egal ob ESXi oder die VMware-Desktopprodukte immer auch etwas Verwaltungszeit benötigt, kann die Leistung einer VM nie höher als die native Systemleistung des Hosts sein. Wenn du wissen willst, was dein Gast-OS an Host-CPU sieht, lies dir mal mein Posting "Beobachtungen mit 2 v.CPU-Kernen in einer VM" im Monsterthread Server2,HW-Upgrade,VI-Client,supp.Host-OS,Permission,Optimum durch. Den habe ich zwar für den seit Jahren eingestellten VMware-Server2 geschrieben, der VMware-Hypervisor ist jedoch im Kern fast gleich.
Unabhängig davon sieht die VM keine HT-Kerne sondern bekommt vom Hypervisor immer logische Kerne zugewiesen. Ob diese Kerne physikalisch oder per HT abgebildet sind, ist innerhalb einer VM nicht zu erkennen.

[mainziman]

@Dayworker: so seltsam es klingt; es ist schon klar, daß die Zuweisung der CPUs an den VM-Guest dynamisch ist; aber in diesem Linpack-Benchmark ist es schon etwas paradox, daß eben durch die Zuweisung von einer CPU mit 8 Kernen an diese VM, der Benchmark in knapp etwas mehr als der Hälfte der Zeit fertig ist, als er native am VM-Host gebraucht hat ...

wobei ein spannendes Detail: ein "Hardcore" Rechenprogramm läuft bei der Core-i7-3820 CPU mit 8 parallel laufenden "Rechenkernen", aber bei der Core-i7-2600 CPU mit nur 4 parallel laufenden "Rechenkernen";
beides jeweils mit WinXP x64 als Host Betriebssystem;
(es scheint einen Unterschied zu geben, was sich beide Threads innerhalb eines CPU-Kern teilen müssen)

irgendwie ein Mysterium;

@JustMe: Dein Beispiel von 2 VMs mit nur einem CPU-Kern ist gut, aber sowas meinte ich nicht; auch wenn beide VMs bei einer Berechnung meinen sie würden mit dieser ihre CPU jeweils zu 100% auslasten; die Gesamtlauifzeit ist hier sogar länger als wenn Du diese beiden VMs hintereinander laufen lassen würdest ...;

[Martin]

"etwas mehr als die Hälfte der Zeit"

Wurde diese vom Benchmark selbst angezeigt, oder hast Du sie "von außen" z.B. per Stopuhr gemessen?

[Dayworker]

@Dayworker: so seltsam es klingt; es ist schon klar, daß die Zuweisung der CPUs an den VM-Guest dynamisch ist; aber in diesem Linpack-Benchmark ist es schon etwas paradox, daß eben durch die Zuweisung von einer CPU mit 8 Kernen an diese VM, der Benchmark in knapp etwas mehr als der Hälfte der Zeit fertig ist, als er native am VM-Host gebraucht hat ...

wobei ein spannendes Detail: ein "Hardcore" Rechenprogramm läuft bei der Core-i7-3820 CPU mit 8 parallel laufenden "Rechenkernen", aber bei der Core-i7-2600 CPU mit nur 4 parallel laufenden "Rechenkernen";
beides jeweils mit WinXP x64 als Host Betriebssystem;
(es scheint einen Unterschied zu geben, was sich beide Threads innerhalb eines CPU-Kern teilen müssen)

irgendwie ein Mysterium;

Wenn ich den Linpack noch richtig in Erinnerung habe, brauchst du pro CPU-Kern sprich logischen Prozessor volle 2GB RAM plus OS. Dein 3820 ist mit 32GB RAM ausgestattet, der 2600 dagegen nur mit 16GB. Von der Warte reicht der RAM auf dem 2600er nicht für 8 logische Prozessoren aus.
Oder bringe ich da was mit einem anderen Benchmark (SPEC etc) durcheinander???

Falls ich da etwas durcheinander bringe, hier mal die Daten vom Core_i7-2600 und Core_i7-3820. Beide entstammen der SandyBridge-Generation und sind bis auf RAM-Kanalanzahl, RAM-Grösse und Sockel zwei Quadcores mit HT.

Wie Martin schon anmerkte, zählt bei jedem Benchmark nur die externe Stoppuhr.

[mainziman]

"etwas mehr als die Hälfte der Zeit"

Wurde diese vom Benchmark selbst angezeigt, oder hast Du sie "von außen" z.B. per Stopuhr gemessen?

bei der Laufzeit brauchts keine Stoppuhr; die Küchenuhr reichte aus
> 90 min nativ vs. < 50 min VM
(das deckte sich auch mit den Angaben des Benchmarks selbst)

@Dayworke: keine Ahnung wie das mit dem RAM von diesem Benchmark ist, aber nativ hatte er am 3820 irgendwann mal was von auslaufendem virt. Speicher angezeigt;
der VM gab ich 16 GB und da kam keine derartige Meldung ...; auch sehr merkwürdig ...

die ark.intel...-Seiten kenn ich; hier die Ausgaben der jeweiligen CPUID-Werte

Core-i7-2600


Core-i7-3770 (rein zum Vergleich)


Core-i7-3820

[Supi]

Also ich lese aus deinen Ergebnissen nur, dass der Bechnmark unter Windows XP 64bit direkt auf einem PC nicht 100% sauber läuft.
Was auch immer VMWARE dann unter XP 64 einer VM dann macht, es hilft wohl aber, das das XP64bit virtualisert besser den Host auslastet als nativ.

Beides, also XP64bit als auch volle Auslastung eines Host durch eine VM, sind aber sehr spezielle Anwendungsfälle.

http://kb.vmware.com/kb/1010184

Wenn man hier zwischen den Zeilen liest, läuft dein XP64 als Server 2003 64bit Kopie ja maximal mit 4 CPU's je Sockel.

Viel Text zu wenig Inhalt/Ergebnis: XP64 kann den I7 nativ nicht 100% auslasten. Und? Das OS ist knapp 10 Jahre alt und kam zu Zeiten raus, da intel noch nicht mal die Core2 draußen hatte.
Wie lange willst du da das tote Pferd noch reiten? Man kann sich auch an sowas festbeißen.
Oder anders ausgedrückt, gibt es nicht wichtigere Probleme als 1 Benchmark unter einem 10 Jahre alten OS, der virtualisiert sich anders verhält?

[mainziman]

Viel Text zu wenig Inhalt/Ergebnis: XP64 kann den I7 nativ nicht 100% auslasten.

falsch, und Du hast eigentlich den Sinn nicht wirklich so verstanden, wie er zu verstehen ist ...

Das OS ist knapp 10 Jahre alt ...

irrelevant; weil so seltsam es klingt, der selbe Benchmark liefert unter Win7 nativ ein schlechteres Ergebnis als ein WinXP x64 in einer VM auf einem WinXP x64 Host bringt;
immer noch der Meinung XP x64 ist alt und schlecht?

nebenbei: es geht darum, daß Intel eigentlich wissen sollte wie man CPUs korrekt benchmarked ...

Wie lange willst du da das tote Pferd noch reiten?

NT 6.x war leider schon tot, als NT 5.x noch quicklebendig war ...

Man kann sich auch an sowas festbeißen.

darum pass auf ...

[Dayworker]

Sämtliche XP-artigen OS können kein AVX nutzen und deshalb ist der GFlops-Wert unter Win7 ab SP1 fast doppelt so hoch.
Ob man AVX in einer VM überhaupt nutzen kann, hängt auch von der v.HW-Version ab.

Hast du die HW-Virtualisierung in der VM fest eingeschaltet oder läuft die auf dynamisch?
Im letzteren Fall kann VMware durch BT eventuell doch einige, normalerweise nicht in der Gast-HW verfügbare CPU-Features auf der Host-HW ausnutzen und reicht diese dann per BT an das Gast-OS durch...
Das ist aber hochspekulativ von mir und ich würde die Linpack-Frage mal direkt im VMTN stellen. "jmattson" dürfte darauf direkt anspringen und die Frage vermutlich als einzigster auch wirklich beantworten können.

[~thc]

Ich persönlich glaube eher, dass du da eine besondere Konstellation hergestellt hast, die den LinPack-Test schlicht überrumpelt. Wenn du dir ähnliche Tests

http://blogs.vmware.com/performance/tag/linpack

anschaust, kommen diese zu nachvollziehbaren Ergebnissen.