Intel, amd was ist besser für vmware ?

Wenn du viele VMs laufen lassen willst vielleicht einen 4 Kern Prozessor und 8GB RAM nach meiner Einschätzung. Hab den Q6600 und mir kürzlich eine Testumgebung für eine Windowsdomäne mit VMWare aufgebaurt und von der Geschwindigkiet her kann ich net motzen... :-)

misc, wie deflow schon sagte: nutzt du viele vms und deren zusammenspiel, etwa um ein client-server-modell durchzutesten oder brauchst du nur einen server mit einem spezifischen softwarestack?
für ersteres sind die kleinsten quadcores am nützlichsten, für letzteres reicht wohl auch ein kleineres System, das du dann vielleicht sogar paravirtualisieren könntest. dann würdest du so gut wie keine performance verlieren.
was amd und Intel angeht: es wird ja (fast) nichts emuliert, also hängt die performance fast 100% am workload - und in fast allen normalen workloads im unisocket bereich ist Intel schneller derzeit.
diese zähigkeit, die du erlebst, das sind kontextwechsel, da wird praktisch der komplette cache geflusht und neu geschrieben, das braucht halt (ein wenig). das passiert theoretisch bei jedem mausklick in die vm und auf den desktop. dabei ist aber die vt-x technologie von Intel hilfreich, um die angelegenheit zu beschleunigen - das kann man sehr gut beim mac sehen mit parallels und fusion, das geht sehr angenehm schnell, auch wenn office oder photoshop in der vm läuft.
enorm wichtig ist für meinen geschmack weniger RAM io als hdd performance. eine schnelle festplatte bringt arg viel.

@formatc: swsoft unterstützt vt-d ebenso. außerdem: weißt du, was das ist? vt-d reserviert den zugriff auf ein pci/x/e gerät für eine virtuelle maschine, um den durchsatz und die sicherheit zu erhöhen. also etwa eine ethernet schnittstelle oder eine clearspeedkarte. das hat für testing oder solche anwendungen keinerlei nutzen. vt-x bzw. vt-i sind die wichtigen technologien für endanwender und entwickler (diese technik stellt sicher, dass das gastos nicht merkt, dass es ein gastos ist). aber auch die sind nur bei mehreren maschinen auf einem Rechner wirklich nützlich, um ein linux zu testen hängt alles an der prozessor- und hddleistung. kleinigkeiten wie: den virenscanner vom imagefile zu lösen sind viel wichtiger.

EDIT: der fantastische jon stokes hat vor kurzem den ersten teil einer wirklichen einführung in virtualisierung online gestellt: http://arstechnica.com/guides/othe [...] de-1.ars/1
wie immer toll geschrieben und sehr spannend

Sicher weiß ich das

Ich arbeite seit 3 Jahren mit VMWare. Und ich weiß eine Hardware-Unterstützung, die es mir ermöglicht, I/O-Geräte virtuellen Maschinen oder Partitionen zuzuweisen, sehr zu schätzen. Dass damit die Zuverlässigkeit des Datentransports und der erzielbare Datendurchsatz steigt, ist eigentlich eine logische Folge. Und es geht beim VT-d eben nicht nur allein um Ethernet-Schnittstellen, sondern es ermöglicht auch, endlich mal eine einigermaßen befriedigende Grafikleistung in den VMs zu erreichen. Allerdings setzt dies auch VT-d fähige Chipsätze mit den betreffenden Funktionen (z.B. DMA-Remapping) voraus. Die neuen Eaglelake, Bearlake und Seaburg unterstützen dies z.B. schon. Also kommt es nicht nur auf die CPU, sondern auch aufs passende Chipset an. Im obigen Fall wirds wohl auf ein Board mit P45 Chisatz oder ein Intel-Board hinauslaufen. Ansonsten muss man sich erkundigen, inwieweit die OEM-Beschränkungen auf den Boards der einzelnen hersteller greifen

@formatc: hehe, ok, dein erster satz: "Selbige bietet Hardware-Unterstützung, um I/O-Geräte virtuellen Maschinen oder Partitionen zuzuweisen und sie kann außerdem die Leistung und Zuverlässigkeit des Datentransports in virtualisierten Umgebungen verbessern" klingt extrem powerpointy^^

@7oby: jupp, vanderpool ist für produktionsumgebungen gemacht, um die wahrscheinlichkeit von hypervisorbugs zu reduzieren. dafür funktioniert es auch gut. die paar befehle, die die virtualisierte umgebung sprengen können und deshalb gewrapt werden müssen sind ja eh eher weniger häufig bzw. speicheraufrufe, die ja immer umgerechnet werden müssen.
der wichtige schritt wird paravirtualisierung sein, dann gibt das gast os fast nur noch schnelle befehle aus.

@toudoku: oui, der barcelona ist ja ein echter serverprozessor in dem sinne. (das vergessen die leute leider oft)
eine der hauptanwendungen von virtualisierung ist ja schließlich grobgranulares load balancing und da ist der quad opteron bei 4 sockel systemen mächtig viel schneller als Intel.
sparc und power sind aber dummerweise keine ia, was die nützlichkeit von virtualisierung schon arg einschränkt. (zumindest alle microsoft software und eine ganze menge mainstreamlinux ausschließt). aber das ist ja auch weniger der sinn der sache - und für sap oder oracle over hypervisor kenn ich keine benchmarks, da müßte man dann auch die richtig großen jungs mitspielen lassen^^vmware bietet solaris als host an, aix aber zum beispiel nicht...
EDIT: hab mir an den kopf gehauen - vmware macht für aix gar keinen sinn, weil das os von sich aus virtualisierte umgebungen für einzelne anwendungen bereithält...

Ich denke nicht, dass es die wengisten sind. Denn selbst CALL und INT wenn sie von User-Mode -> Kernel-Mode gehen müssen umgeschrieben (oder eben mit der VT Erweiterung gefangen werden):
http://www.usenix.org/events/sec00 [...] index.html

Die Treiber im Gast-OS sind doch ohnehin paravirtualisiert?!?

Und deshalb frage ich mich, ob das überhaupt stimmt was FormatC oben geschrieben hat:
. ein physikalisches Laufwerk kann ich der VM auch ohne VT Erweiterung zuweisen
. die Fortschritte in Netzwerkspeed haben doch ganz andere Ursachen (z.B. NAT vs. Bridged Modus)
. die Treiber des GastOS werden besser

Was genau bringt die Hardware VT noch? Ich denke für das Übersetzen der nicht trappenden Befehle ist das egal. Ich denke, dass lediglich Memory-Management als Performance Hit übrig bleibt. Würde man eine Hypervisor basierte VM verwenden, dann ist man fein raus. Das gesamte Memory Management macht der Hypervisor - keine Konflikte - schnell.

Die Leute hier im Forum verwenden das aber nicht, sondern lassen ihr Gast-OS im Host-OS laufen. Und hier bringt Hardware VT vermutlich viel für das Übersetzen der MMU Tables in Form von Nested Page Tables:
http://it.anandtech.com/IT/showdoc [...] =3263&p=10

Das Problem ist aber: Das rennt nur dann schnell, wenn der TLB groß genug ist. Hier (Nested/Extended Pages) trennt sich die Spreu vom Weizen:
. Core2Duo E4x00 "Allendale" 2MB 2nd Level Cache
. Core2Duo E7xx0 "Wolfdale" 3MB 2nd Level Cache
. Core2Duo E6xx0 "Conroe" 4MB 2nd Level Cache
. Core2Duo E8xx0 "Wolfdale" 6MB 2nd Level Cache

Und beim Barcelona/Phenom erwarte ich hier durch den 3rd Level Cache noch mehr.

LoadBalancing? Kannst Du da mal die Zusammenhänge erläutern? Die Webshops, die ich bisher gesehen habe, habe das immer mit einem Hardware LoadBalancer gemacht.

Habe keine Statistik zur Hand, aber Virtualisierung hat in meinen Augen zwei komplett andere Anwendungen:
. Testen von Multi-Tieranwendungen. Oder auch Testen von einfachen Anwendungen unter zig verschiedenen OS.
. Management von Software-Landschaften: Wenn jeder Service auf einer VM läuft, kann man leichter migrieren.

Und eine Reihe von Nebenschauplätzen wie z.B.:
. Legacy Software: Manche Leute haben viel Geld für Legacy Software bezahlt, um wollen diese erhalten, obwohl sie auf ein neues OS umgestiegen sind.

P.S.: Ich sehe auch, dass wir uns vom ursprünglichen Fragesteller entfernt haben. Aber bzgl. Virtualisierung lerne ich gerne noch etwas dazu, wenn sich hier etwas Kompetenz zusammenfindet, möchte ich das auch ausnutzen. Ich hab' nämlich auch nicht alle VMWare Versionen getestet.

Wenn man mal ehrlich ist, dann bringen die Dinger außer I/O keine Leistung. Es ist schon richtig, dass eine SunFire (noch die UltraSPARC basierten) für EUR 500.000 inkl. Storage mal ganz nett sein kann, aber die CPU Power kann sie auch nur bei massiv parralleler Software (wie z.B. Webshops) umsetzen. Und auch dort limitiert üblicherweise das I/O und nicht der Prozessor oder das RAM. Wenn man mal selbst auf so einem Ding software laufen lässt, stößt man viel früher an Skalierungsgrenzen und ist mit einem 64-Bit Barcelona MultiCore oder Xeon um ein x-faches schneller, da die Leistung pro Core deutlich höher ist.

Hinzu kommt, dass so viel Geld immer nur alle paar Jahre in die Hand genommen wird. In der Zwischenzeit wurden x-mal die x86_64 Hardware ausgetauscht und diese ist widerrum um ein x-faches schneller als die UltraSPAC Geschichten.

Es hat auch etwas mit Bestätigung zu tun, wenn Software auf 08/15 BilligHardware (die immer noch ein paar tausend EUR kostet) schneller ist als auf einem Server für'eine halbe Million. Manche kaufen teurer Hardware, um die Unfähigkeit mancher Softwareentwickler zu kaschieren. Das gehört auch mal gesagt.

7oby, dann wollen wir mal.
also, so wie ich das verstehe sind bei klassischem host/guest vm modell wirklich recht wenige calls abzufangen. vmware sagt, dass bei standardtasks 3-6%overhead durch den vmm entstehen. das ändert sich mit: secure vm. sobald die eine vm vor der anderen und alle vor dem host gesichert werden sollen wird es anspruchsvoller.

zur paravirt. treibern: ja, die treiber wissen bescheid, aber der normale windows kernel oder auch die standard (non xen) builds von linux haben keine ahnung.
der treiber bzw. das kernelmodul kann dann die aufrufe nur noch abfangen, nachdem sie gemacht wurden. das macht aber die vm sonst auch - und da alles auf dem gleichen prozessor läuft, ist es egal. die treiber sind vor allem input- und dateisystemtreiber, afaik

der translation lookaside buffer sitzt in der CPU als hardwarelogik mit tabelle, der ist so eine art schnellrateabkürzung für speicheradressen. der ist sehr groß bei allen derzeitigen architekturen, aber immer noch ziemlich klein im vergleich mit dem cache. ich denke nicht, dass an der speicherumrechnung bei normaler nutzung zu viel hängen bleibt, wenn man nicht zu viele vm einsetzt. (mit anderen worten: bei wirklich großen servern mit sehr kleinen vms mag es performance hits geben, aber sonst kaum - und bei den großen jungs erschlägt man das dann mit noch nem server^^)

hehe, load balancing bei web servern ist was ganz anderes, wenn auch im prinzip nicht zu verschieden. es geht dabei um folgendes:
wenn du eine große serverfarm hast, dann möchtest du die gern auslasten, soweit es geht. es gibt techniken (auch von vmware), womit du laufende vm's im betrieb von einer hardware auf die andere umziehen kannst, ohne dass der user mit seinem word dokument was davon merkt. dadurch verteilst du die user gleichmäßig auf die server, so dass alle genug abbekommen - und wenn einer doch mal power braucht, dann schickst du alle anderen weg in den cluster. boom, hat der eine user einen 16 kern Rechner mit 32gb an der hand, ohne dass es sonst wen stört. beachte: fehlertoleranz!!
das, also server consolidierung und load balancing sind die beiden gründe, warum vmware so viel wert ist mittlerweile und warum das thema so groß ist. nicht, weil ein paar nerds dann leichter testen können ;-)

@toudoku: hast ganz klar recht. wenn man in der it- oder finanzbranche irgendwas drauf gäbe, wer in wen investiert hat...alle gehören allen, das ist branchenhedging sozusagen - und Intel vc investiert eh in alles, was nicht sofort pleite umfällt

Ich schreib' gleich noch was zu den anderen Punkten, aber fang' mal hier an:

Dieses Wissen ist sogar so alt, dass es Einzug in das Benutzerhandbuch von VirtualBox gefunden hat:

S.43 im Usermanual von VirtualBox:

http://www.virtualbox.org/download [...] Manual.pdf

Binary Translation ist schneller als VT-x. Auch VMWare benutzt Binary Translation:

http://en.wikipedia.org/wiki/Vmware

--

Ich bin kein PHP Experte, aber meine C/C++/Java Compile-Vorgänge skalieren linear auf Multicores. Wenn der Apache PHP Code kompiliert würde ich ähnliches erwarten. Und das ist ein Nachteil von VirtualBox: Es ist nicht MultiCore fähig im Gegensatz zu VMWare. Da wäre also auf jeden Fall noch Performance zu holen.

@pool1892

Ja, Kommunikation läuft über das virtuelle vmware Netzwerk.
Hat momentan allerdings sogut wie keinen Einfluss auf die Performance, hauptsächlich brauch ich das Netzwerk zum Einloggen per ssh / bzw. eben für das CGI Benutzerinterface.

Wobei unter dem Link ja auch steht:
Speichervirtualisierung: Nested Page Tables

Die zweite Hilfestellung seitens der Prozessorhersteller könnte Speichervirtualisierung sein. Sie ist heute bei Intel gar nicht und bei AMD zum Teil implementiert.
[..]
AMD hat Nested Page Tables für dieses Jahr angekündigt und will diese Technologie in allen zukünftigen Opteron-Prozessoren standardmäßig anbieten. AMD und Vmware haben bereits eine "Experimentalversion" eines Quad-Core-Opteron mit Nested Page Tables demonstriert. Intel ist inzwischen verdächtig ruhig und verweist auf seine bestehende VT-x-Technologie.

Dies hat sicherlich den Grund, dass Intel einen externen Memory-Controller verwendet, den so genannten Frontsidebus, während dieser bei AMD auf dem Prozessor integriert ist. Will Intel hardwareseitige Unterstützung für Memory-Virtualisierung anbieten, so muss der Memory-Controller grundlegend modifiziert werden.

Ist aber alles für mich irgendwie etwas zu theorethisch, leider konnte ich auch absolut keine vergleichenden Benchmarks finden.


@7oby
Die Anwendung selbst ist in den entscheidenden Abschnitten mehr als schnell genug, ich find's an sich sogar vorteilhaft auf älterer Hardware zu testen da dann die Bottlenecks viel deutlicher werden.

Problem und zu zeitaufwendig ist wirklich der "Kompiliervorgang", auch wenn ich's nativ laufen lasse, mal schnell bis zu 40 Sekunden warten bis eine Fehlermeldung kommt ist irgendwie unproduktiv.
An zu wenig RAM liegt's definitiv nicht, Festplattenzugriffe hab ich so gut wie keine mehr wenn die virtuelle Maschine erst mal läuft, allerdings auch nativ eher weniger - und das Netzwerk spielt da bei mir auch keine Rolle.

-> Da der webserver zusammen mit meiner Anwendung doch relativ viel Speicher braucht, ~100MB, lief bei mir der Gedanke in Richtung Speicherdurchsatz als Bottleneck, und der dürfte auf einem Laptop wohl sowieso alles andere als berauschend sein.
In diesem Sinne wird der Prozessortakt auch wirklich eher nebensächlich sein.

Damit ist doch klar, dass all dies überhaupt nichts mit Virtualisierung zu tun hat. Dieses Problem solltest Du Dir also losgelöst anschauen.

Du schreibst, dass Du Perl verwendest. Perl ist nicht wirklich interpretiert, sondern der Code wird eben in einen Bytecode übersetzt. Enthält der Perl Code Fehler, gibt's eine Fehlermeldung beim Übersetzen. Kompilieren und Parsen sind Tätigkeiten, die überlicherweise CPU limitiert sind (und wenn es das bei Dir ist, brauchst doch nur auf die CPU Auslastung zu schauen während der 30/40 Sekunden).

Die üblichen Techniken, um diese Art von Wartezeiten zu vermeiden sind doch:
. On-the-fly Syntax Check wie's auch das Perl für Eclipse Plugin anbietet:
http://www.epic-ide.org/index.php

. incrementelles Build: Also nicht immer alle Files zum Server kopieren, sondern nur diejenigen, die sich geändert haben. So hat der Server eine Chance zu erkennen welche Files sich geändert haben, und übersetzt nur diese neu. Dazu hat man Skripte.

. Multi-Core Build: Bei fast allen Build Umgebungen, muss man MultiCore Builden erst aktivieren. Bei make mit "-j". Das wird beim Perl Übersetzer auch nicht anders sein.

. Neue Perl Version: Perl verwendet schon sehr effiziente Tools (z.B. Bison) um den Quelltext zu parsen. Trotzdem lohnt sich wahrscheinlich das Updaten auf neuere Perl Versionen, da dort sicher auch Performancesteigerungen gemacht werden.

Ich fange immer gerne bei Adam und Eva an. Das liegt so in meiner Natur.

Dein Beispiel handelt von Workload Balancing. Ich behaupte: Für alle wichtigen Bereiche ist dieses Problem seit Anfang der 70er Jahre gelöst. In der Tat würdest Du ohne Workload Balancing Dein Gehalt immer an anderen Tagen bekommen und Überweisungen würden zwischen morgen und vielleicht irgendwann ankommen.

OS/360 (danach OS/390, z/OS, etc. vermutlich hatte BS2000 auch ähnliches) hatte dies wie gesagt schon Anfang der 70er Jahre intrgriert:
http://en.wikipedia.org/wiki/Workload_Manager

Das ganze Hot/Live Migration und Hot Swap Geschwafel sind Kopien von Dingen, die's im Mainframebereich schon lange gibt. Jetzt zieht eben die 08/15 Software/Hardware mit AIX/Linux und VMWare/Xen etc. in dem Bereich nach.

Technologien ändern sich also muss man auch alte Praktiken auf neue Technologien portieren. Wie gesagt: Für alle wichtigen Bereiche funktioniert das schon seit Jahrzehnten prima. Im Super-Computer Bereich ist Resourcenmanagement auch bereits in OS und die Bibliotheken integriert.

Was jetzt nachkommt ist Spielzeug. Das fängt schon damit an, dass man sich überlegen muss welches überhaupt eine sinnvolle Umgebung ist: Standalone PC? Fat-Client? Thin-Client? Ultra-Thin-Client? Und das ganze in allen möglichen Technolgieausprägungen. Nur ein Beispiel: Wenn ich eine Anwendung als Ultra-Thin-Client im Browser hab', dann hab' ich überhaupt kein Migrationsproblem. Dem Applikationsserver kann ich zur Laufzeit Resourcen geben und nehmen wie ich's brauche. Downtimes gibt's in diesem Nicht-Hochverfügbaren Bereich doch immer. Allein um Sicherheitslücken zu schließen. Dann kann ich das Migrieren von Servern/Clients - so denn notwendig - auch darüber abfackeln. So sieht die Praxis doch aus.

Wer testet eigentlich die Software, die auf so'nem Server läuft? Ist es Zufall, dass user "misc" auch seine Anwendungen auf dem VM-Server deployen/testen will? Meinst Du nerds haben die Software geschrieben, die Du verwendest? Warum sagte Bill Gates auf die Frage wie wichtig Testen ist: "Wenn ich nach den Tätigkeiten gehe, die unsere Firma macht, dann müsste ich sagen wir sind eine Testfirma, denn über 50% der Mitarbeiter beschäftigen sich ausschließlich mit Testen."

Server Konsilidierung ist ein Untergebiet von Mangement von Software-Landschaften was ich vorhin schon erwähnte. Und Hot/Live Migration ist halt 'eine weitere Spielwiese der Hersteller, damit sie ihre neuen Produkte verkaufen können. Ich hab' im Bereich Hot/Live Migration - wie gesagt - noch wenig sinnvolles gesehen und für alle wichtigen Bereiche ist das Problem schon gelöst.

@7oby

Muss ich Dir rechtgeben.
Vermutlich muss ich, was den Kompiliervorgang angeht, mir auch noch mehr Gedanken über Alternativen machen.
Angefangen habe ich da schon, d.h. viele Dateien werden nach Änderungen separat neu übersetzt.

Epic kannte ich gar nicht !
Eigentlich ziehe ich ja vim vor, aber ich werd's doch noch mal ausprobieren, bzw. mir eine Syntaxprüfung in vim reinbasteln.

Ist wohl auch besser als einfach zu sagen schnellerer Rechner her.
Die falsche Fragestellung wars definitiv.. Da haben mir Deine Beiträge echt weitergeholfen, auch eben mir meiner Probleme erstmal bewusst zu werden. Danke dafür!

Dennoch ist in der Anwendung ein Bottleneck, im Speziellen beim parsen von Html-Dateien.
Auf der Zielarchitektur ist das momentan uninteressant, denn auf einem Core2 6300 läuft das wieder ausreichend schnell.

Ich hab nichts gemessen, aber könnte durchaus 3x schneller sein.

Hilft mir beim Entwickeln (auf einem Turion TL60) nur leider wenig..

Das ist jetzt alles nicht unbedingt entscheidend über den Erfolg, allerdings lästig und teilweise auch zeitintensiv.



Insofern würde mir ein weiterer Rechner glaub ich schon einiges abnehmen.

Amd ist dann wohl leider ausgeschieden, obwohl mir das irgendwie leid tut.

Stellt sich für mich noch die Frage ob Dual- oder Quadcore, bzw. Xeon oder Core2.

EDIT: eine, eigentlich alles doch nicht so klar.
Denn: Virtualisieren will ich ja immer noch, und auch nächstes Jahr möglichst schnell.
Obendrein hab ich gesehen dass ich für gleiches Geld wie für einen Core2 /Xeon auch einen Phenom X4 bekomme, der ja bei einigen Benchmarks auch gar nicht so schlecht abschneidet.

Genau. Sein könnte.

Hat mich jetzt auch interessiert. Gibt von VMWare einen Benchmark VMMark und Ergebnisse:
http://www.vmware.com/products/vmmark/results.html

Picke da jetzt mal 3 Systeme raus. Es sind alles 2x Quads (= 8 Cores), da ich bei den 4-Cores nur ein Ergebnis finden konnte:

Quad-Core Intel Xeon X5365; 2x 65nm Quad 8MB Cache @3GHz; VMWare ESX 3.0 : 7,03 Score
Quad-Core AMD Opteron 2360 SE ; 2x BarcelonaQuad 2+2MB Cache @ 2,5GHz; VMWare ESX 3.5 : 7,96 Score
Quad-Core Intel Xeon X5460; 2x 45nm Quad 12MB Cache @ 3,16GHz; VMWare ESX 3.5 : 8,46 Score

Der Vergleich hinkt etwas:
. nur Serveranwendungen getestet, die aufgrund ihrer Unabhängigkeit ohnehin mit den Cores skalieren.
. Wie groß ist der Nachteil, den der X5365 mit dem ESX 3.0 gegenüber den anderen mit ESX 3.5 erleidet?

Trotzdem meine ich eine Tendenz erkennen zu könnnen, dass der Barcelona sich ziemlich gut gegen den Xeon mit 3,16GHz schlägt. Bis auf Fileserver und Database ist der Barcelona im Einzeltest gleich auf und das mit "nur" 2,5GHz und dem Ach-so-schlechten-IPC und "nur" 4*512KB Cache + 2MB = 4 MB gegen 12 MB eines Xeon Cores. Also durchaus beachtlich!

Ich finde nur, dass AMD mit 124% geworben hatte. Und zwar ein 3.2 GHz Opteron 2224 SE (2 Cores) gegen einen 2,5GHz Barcelona Opteron 2360 SE (4 Cores). Meintest Du diesen?

Um von den 124% auf die 23% Performancegewinn zu kommen, muss man mehrere Verrenkungen machen:
1. Annehmen, dass die Cores linear skalieren. Wenn das I/O System nicht mit skaliert fast unmöglich
2. Die 3,2GHz nicht mit den 2,5GHz verrechnen
3. Die 24% nicht durch zwei teilen und schlecht runden oder so ähnlich

Auf jeden Fall wurden diese 124% auch sehr stark relativiert von TGH:
http://www.tgdaily.com/content/view/33770/135/

Oder waren die 23% bei den MS Terminal Servern gemeint?

Wo sehe ich Vorteile durch NPT? Kann nicht sagen, ob bei wenigen oder vielen VMs. Server haben lange CPU Scheduling Time-Slices. Linux z.B. 100Hz. Bei einer CPU mit 2GHz also 20,000 Takte / CPU Slice. Da ist egal wie lange ich initial irgendwas aus dem Speicher einlesen muss (z.B. PageTables). Deshalb denke ich, dass es egal ist ob ich viele VMs oder wenige habe. Viel Cache hilft aber die TLB Misses nicht so teuer zu machen. Da spielt keine Rolle ob viele oder wenige VMs und auch nicht wie "fett" sie sind. Das ist aber nur geraten - keine fundierte Messung dahinter.

Ich sehe aber gerade, dass AMD doch ziemlich mit dem VMMark wirbt:
http://www.amd.com/us-en/Processor [...] dir=seop01

Ich will das Thema nicht runterspielen. Aber das letzte was ich dazu im Bereich der VMs gesehen habe ist das folgende: Jede VM kann einen Snapshot anfertigen (selbst meine "Billig"-VirtualBox). Dieser Snapshot wird auf einen anderen Rechner kopiert. Das sind 1-2GB vom RAM-Image und nochmal 5GB vom Filesystem. Beide kann ich und innerhalb weniger Sekunden über das Gigabit Netzwerk schießen, wenn ich diese on-the-fly ("gzip --fast" ) zuvor komprimiere und auf einem anderen Rechner starten. Das kann ich soweit schon ohne Hot-Migration support. Und an dem Ding optimieren sie.

Man kann sich die Welt auch kompliziert machen. Storage ist bei größeren Servern komplizierter als das 5GB Filesystem Image, z.B. ein redundantes Fibrechannel Storage. Was man da jetzt auf Biegen und Brechen live migrieren muss, weiß ich nicht, aber sollen die die's brauchen (oder die die's verkaufen wollen) ruhig machen. Ob das irgendein Problem löst, ist nicht immer gesagt. Zumal diese Storage Systeme oft ohnehin Downtimes haben.

Fixpunkttheorie und Differentialgleichen sind gut verstanden. Selbst wenn diese da reinspielen, sollte dies kein Problem darstellen. Aber ich bezweilfe noch etwas, dass diese Probleme nicht hausgemacht sind. Üblicherweise gibt es eine Ordnung auf den Systemen und in dieser Ordnung kann man das System in einen Standby versetzen. Sonst wäre ein kontrolliertes Herunterfahren von System ja ebenfalls nicht möglich.

Natürlich werden ein Haufen geräte und Strom gespart. Aber auch nur, weil sich vorher keiner die Finger dreckig machen wollte und jeder rumgebrüllt hat: Jede Anwendung = ein Server. Dass das nicht so sein muss, haben andere (auch ohne Mainframes) auch schon vorher erkannt.

Jetzt kann man's halt von der Stange kaufen und die faulen IT-ler sparen tatsächlich etwas.

Also auch bei den VMware-Benchmarks schlaegt sich der Phenom, eh Opteron, ganz hervorragend. Was in den bisherigen Anmerkungen auch hervorkommt, ist das die Intels durch den hoeheren Takt das erreichen, was der Opteron durch besseres Scaling erreicht. Aber das schrieb ich ja auch in meinem ersten Posting. Darum wird dann letztendlich auch die 16-Core Tabelle absolut von den Opterons dominiert, weil dann Scaling einfach so wichtig ist, dass man die Xeons wohl auf 4GHz bringen muesste.

Sowohl Xeon als auch Opteron haben so ihre Starken und Schwaechen und beide muessen den Anorderungen entsprechend ausgewaehlt werden. Wenn man den Xeon, also allgemein die Intels, mit der falshen Aufgabe betraut, sind sie ebenso langsamer als die Konkurrenz, wie in der von 7oby angsprochenen Situation.

Aus dieser Sicht sollte man sogar ernsthaft ueberlegen, ob es nicht sinnvoller ist, gleich einen 45nm-Nehalem (aehnliche Architektur wie die derzeitigen AMDs) oder einen 45nm-K10 (geringere TDP und geht auch auf 3GHz) zu nehmen, ein alter Q6600 ist da von der Architektur und auch ansonsten die schlechteste Variante.

Aber selbst 10 Prozent Unterschied, wirst Du in Deiner taeglichen Arbeit kaum merken, weshalb es wiederum fast wieder egal ist, ob Du den mit Erdbeergeschmack oder den mit Schoko-Banane nimmst. ;-)

Na ja, wer fuer ein paar VMs solch eine Diskussion startet, dem scheint es schon wichtig sein und dann kann man evtl. auch noch einen oder zwei Monate warten, vor allem da es ja schon eine Maschine gibt, auf der es erst mal laeuft. Und noch wichtiger: die beiden im kommenden Quartal zu erwartenden Architekturen merzen beide ihre jeweiligen Nachteile aus, sind jedoch, da neu, anfangs teuer.

Jetztzustand je nach Prioritaet:
Skalierung, Fluessigkeit -> AMD
Rechenpower pro Kern -> Intel

Im Umgangssprachgebrauch oft im Zusammenhang mit SLI und Crossfire genannte Mikroruckler sind einfach ein Skalierungs- und Synchronisierungsproblem, da die GPUs auch primaer auf Rechenpower pro Kern bzw. Karte optimiert sind. In FPS bzw. FPM sind sie trotzdem schneller als eine Einzelkarte, welche dafuer fluessig durchlaeuft. (Der Vergleich hinkt, da der Opteron natuerlich auch ein Mehrkernprozessor ist).

Und wenn 7oby "wuergen" meint, dann wuerde ich das uebrigens auch auf den Q6600 bei 3,6GHz erweitern. Aber wir wollen ja hier keinen AMD vs. Intel Thread starten. ;-)