Follow along with the video below to see how to install our site as a web app on your home screen.
Anmerkung: this_feature_currently_requires_accessing_site_using_safari
Ich würde vielmehr vermuten, dass die Margen der AMD-Boards wohl solche Rabatte schlicht nicht hergeben.
Eher ne Schätzung. Es dürfte eher ne Mischung aus 4th Floor´s, che new´s und Undertaker´s Annahmen sein.gibts dazu auch zahlen oder ist das nur schätzung
Treiberversionen
* Nvidia GeForce 185.68 (GTX 275, 9800 GT)
* Nvidia GeForce 182.46 (GTX 260²)
* Nvidia GeForce 181.22 (GTX 295, GTX 285)
* Nvidia GeForce 180.48
* ATi Catalyst 8.60-090316a1 (HD 4770, HD 4830, HD 4850)
* ATi Catalyst 8.592.1 (HD 4890)
* ATi Catalyst 9.3 (HD 4870 1GB)
* ATi Catalyst 8.11
Man kann diese Resteverwertung auch possitiv sehen.
Die AMD-Boards verkaufen sich halt momentan besser.
Achso, Du meinst die internen Versionsnummern ?öhm ist der 8.60 nicht gleich einer mit 9.xx?
Diese interne Versionsnummer hat der 9.4
Treiber-Paketversion 8.60-090316a1-078237C-ATI
Hmmm ... am besten von jemanden, der nur ne HD4770 hat. Die ist dann subjektiv schneller als eine GTX285 und das bei besserer BQ ... woher nehmt ihr immer solchen Quatsch?Der subjektive Eindruck des Users ist IMHO mehr Wert als jeder Test.
Nein. Wie ich schon schrieb, der Punkt ist, dass hier Virtualisierung weitaus praxisbezogener getestet wurde.Mir scheint, hier wird mal wieder nur an Hand des Ergebnisses zwischen der Bewertung "gutes Review" und "schlechtes Review" entschieden...
KalleWirsch schrieb:Die Reviewer im Netz werden immer abhängiger von den Herstellern aus diversen Gründen. Vor allem weil die Werbepreise so im Keller sind. Da alle nur noch über geizhals einkaufen, bleibt oft für Werbung bei Herstellern und Händlern kein Geld mehr. Hersteller, die dann mal Werbung machen, will man auch nicht vergraulen usw.
Nein. Wie ich schon schrieb, der Punkt ist, dass hier Virtualisierung weitaus praxisbezogener getestet wurde.
Und die Interconnects spielen hier auch keine Rolle. Ob du es bemerkt hast oder nicht, Anandtechs Betrachtung bezieht sich auf den Unterschied nativ vs virtualisiert. Das war aber gar nicht das Thema. Das Thema war ausschliesslich Virtualisierung bzw eben VMmark vs vApus.
Deine Einschätzung zu ESX kann ich auch nicht teilen. AMD besitzt ja ein vergleichbares Feature wie EPT, nur nennt es sich dort RVI. Und laut Anandtech bringt das zumindest unter vApus maximal 20-25%.
Erstmal bezieht sich Anandtechs Vergleich auf Harpertown und nicht Shanghai. Schnellere Interconnects, NUMA, IMC und L3 hat AMD nämlich genauso. Und der zweite Grund ist lediglich die Erklärung, wo Unterschiede nativ vs virtualisiert entstehen. Das hat alles erstmal grundsätzlich nichts mit der Virtualisierung von Shanghai und Nehalem zu tun. Dafür sind die Infrastrukturen zu ähnlich.It seems like all the advantages of the new platforms such as fast CPU interconnects, NUMA, integrated memory controllers, and L3 caches for fast syncing have evaporated. In a way, this is the case. You have probably noticed the second flaw (besides ignoring the hypervisor) in the reasoning above. That second flaw consists in the fact that the "native scores" in our server CPU roundup are obtained on eight (16 logical) physical cores.
Also exakt hat Anandtech 22% ermittelt. Und das liegt für mich zwischen 20 und 25%. Wo siehst du knapp 20%?RVI war bei Shanghai bereits aktiv. Dessen knapp 20% (wo siehst du 25%?) sind also schon "drin".
Das kommt noch hinzu, richtig. Auch der ist bei weitem nicht so abgeschlagen gegenüber Nehalem. In gewisser Weise spiegelt sich zumindest ansatzweise die Situation im Client Bereich wieder.Das träfe dann in gleicher Weise aber auch auf die guten Ergebnisse der Core 2 - Xeons zu.
Wie gesagt, das ist erstens zweifelhaft und zweitens wohl irrelevant. Istanbul steht ja praktisch vor der Tür. Der sollte auch einiges mehr an Performance haben.Die EPT-Problematik bleibt davon natürlich unbeeinflusst, mit ESX 4 sind es damit dann etwa 40-50% Vorsprung des Nehalem bei gleichem Takt.
@Undertaker
Lies du doch bitte erstmal sorgfältig.
Erstmal bezieht sich Anandtechs Vergleich auf Harpertown und nicht Shanghai. Schnellere Interconnects, NUMA, IMC und L3 hat AMD nämlich genauso.
Auch mit deiner Bemerkung zu den 4 CPUs hast du wohl etwas falsch verstanden. Hier wurden 4 VMs zu je 4 CPUs getestet, sozusagen 16 virtuelle CPUs.
So wie ich das dem Artikel entnehme, entstehen die Unterschiede eben dadurch, dass vApus deutlich praxisbezogenere Workloads testet.
Also exakt hat Anandtech 22% ermittelt. Und das liegt für mich zwischen 20 und 25%. Wo siehst du knapp 20%?
Und dass RVI aktiv war, geht aus dem vorherigen Test auch nicht zweifelsfrei hervor. Oder ich habe irgendetwas übersehen.
Lange Rede, kurzer Sinn. Du kannst erstmal nicht davon ausgehen, dass Shanghai mit Version 4 nicht auch zulegen kann.
Ohne konkrete Belege ist so eine Aussage nichts wert. Ich gehe auch mal davon aus, dass dem nicht so ist. Womit Nehalem gegenüber Shanghai Vorteile hat, ist eigentlich vor allem Bandbreite und Speicher. Opterons sind momentan ja immer noch an HT1 und DDR2 gebunden.Und genau in diesem Punkt der Anbindung ist der Nehalem nocheinmal deutlich schneller als der Shanghai.
Und was genau soll das mit VMmark vs vApus zu tun haben? So wie ich das verstehe, kamen bei VMmark 6 VMs zum Einsatz, bei vApus 4. Keine VM muss also bei ausreichend cleverer Anwendungslogik, was ich einfach mal voraussetze, auf mehrere Prozessoren zugreifen. Weder bei VMmark noch bei vApus.Nein, denn genau das ist doch der Punkt! Keine VM muss auf Ressourcen mehrerer CPUs zugreifen.
Wenn zB SPECjbb weniger als 1% den Hypervisor in Anspruch nimmt, hat das für mich wenig mit der Praxis zu tun. Das schreibt ja auch Anandtech zurecht. Ich möchte den Entwicklern von vApus grundsätzlich auch erstmal keine Inkompetenz unterstellen.Oder eben praxisfernere. Das einzig korrekte Adjektiv in diesem Zusammenhang ist "andere".
Das steht aber nirgendwo explizit. Nur weil Support vorhanden ist, muss RVI noch lange nicht aktiv gewesen sein. Dazu auch ein Kommentar unter dem Artikel:"The table below tells what mode the VMM (Virtual Machine Monitor), a part of the hypervisor, runs. To refresh your memory:"
Dann die Tabelle Seite 9, sowie:
"Thanks to being first with hardware-assisted paging, AMD gets a serious advantage in ESX 3.5: it can always leverage all of its virtualization technologies."
Und auf Seite 8:
"All tests run on ESX 3.5 Update 4 (Build 153875), which has support for AMD's RVI. It also supports the Intel Xeon X55xx Nehalem but has no support yet for EPT."
RVI war an.
Anandtech ist sich also selbst nicht sicher.I was under the impression that ESX now choses RVI+SVM automatically, but that might have been ESX 4.0. I am going to check again on monday
Es geht nicht um das "darüber hinaus". Der RVI Support selbst kann, auch wenn er schon vorher aktiv gewesen sein sollte, trotzdem noch Verbesserungen bringen. Wie gesagt, Anandtech hat keine offizielle VMmark Version getestet.Das bestreitet auch keiner, dazu braucht es Benches. Es geht nur um den Punkt RVI/EPT: Bringt ~20/25%, war an/aus. Das Version 4 darüber hinaus nun weitere Performanceverbesserungen durch andere Optimierungen bringen kann steht außer Frage
Ohne konkrete Belege ist so eine Aussage nichts wert. Ich gehe auch mal davon aus, dass dem nicht so ist. Womit Nehalem gegenüber Shanghai Vorteile hat, ist eigentlich vor allem Bandbreite und Speicher. Opterons sind momentan ja immer noch an HT1 und DDR2 gebunden.
Und was genau soll das mit VMmark vs vApus zu tun haben? So wie ich das verstehe, kamen bei VMmark 6 VMs zum Einsatz, bei vApus 4. Keine VM muss also bei ausreichend cleverer Anwendungslogik, was ich einfach mal voraussetze, auf mehrere Prozessoren zugreifen. Weder bei VMmark noch bei vApus.
Das steht aber nirgendwo explizit. Nur weil Support vorhanden ist, muss RVI noch lange nicht aktiv gewesen sein. Dazu auch ein Kommentar unter dem Artikel:
Anandtech ist sich also selbst nicht sicher.
Es geht nicht um das "darüber hinaus". Der RVI Support selbst kann, auch wenn er schon vorher aktiv gewesen sein sollte, trotzdem noch Verbesserungen bringen.