Neue 64Bit Erkenntnisse von Au-Ja

[Tigerchen]

Gibt ja schon einen Thread der den Test von XBitlab zum Inhalt hat. Jetzt hat mal ein anderes Onlinemagazin einen kleinen Test gemacht und die Ergebnisse sprechen doch deutlich für AMD's 64 Bit Lösung. Auch werden Probleme nicht verschwiegen. Ein gutes Preview.:up:

http://www.au-ja.org/review-wxp64rc2-4.phtml

Fazit:
Bei unserem Test des Windows XP 64-Bit Edition Release Candidate 2 sahen wir zwei Seiten. Zum einen ist die Performance von 32-Bit Software erstaunlich gut, WoW64 bremst 32-Bit Programme keinesfalls aus und kam - mit Ausnahme von Aquamark03 - mit allen Testprogrammen problemlos zurecht. Wir erwarten zwar nicht, daß bei der Markteinführung der 64-Bit Edition alle 32-Bit Programme reibungslos funktionieren werden, doch unser erster Eindruck ist positiv. Auch die 64-Bit Performance konnte uns voll und ganz überzeugen: Hier steckt viel Potential, das aber zunächst einmal durch die Verfügbarkeit von 64-Bit Software freigesetzt werden muß. Leistung und Stabilität hinterließen einen sehr positiven Eindruck.
Allerdings laufen auf dem heimischen PC nicht nur Benchmarks, sondern vor allem Spiele und Anwendungssoftware. So schön es auch ist, nicht mit Leistungseinbrüchen rechnen zu müssen, so muß man dennoch festhalten, daß eine Windows XP 64-Bit Edition für 32-Bit Anwendungen keinerlei Vorteile bringt. Zudem finden wir an und in einem Desktop-PC eine Unzahl zusätzlicher Hardware, für die es zum größten Teil noch keine Treiber gibt. Wahrscheinlich werden die meisten namhaften Hersteller für aktuelle Modelle die passenden Treiber nachliefern, doch was ist mit älterer Hardware? Für diese bleiben nur 32-Bit Windows oder aber 64-Bit Linux.
Der Windows XP 64-Bit Edition Release Candidate 2 zeigt Potential und kann durchaus überzeugen, gleiches gilt für die 64-Bit Performance des AMD Athlon 64. Wir raten dennoch zunächst abzuwarten, wie sich die Software- und Treiber-Situation entwickelt, denn eine Plattform ohne Treiber ist für den Desktop-Einsatz kaum geeignet.

[BlackBirdSR]

Ich fürchte, dass die verwendeten Compiler in Zukunft einen gigantischen Unterschied machen werden.

Programm A wurde z.B mit gcc oder pathscale kompiliert, welches seit Jahren an den K8 angepasst wird.
Der P4 tut sich sehr schwer damit.

Programm B wird mit Intels Compiler übersetzt und zeigt dann für den P4 und K8 Gewinne.

Die Ergebnisse sind schwer vorherzusagen, und die eine Seite wird der anderen Widersprechen. Solange bis man sich von Tester und Programmiererseite gleichfalls auf einen Compiler geeinigt hat.
Wahrscheinlich für die meisten Programm der Intel oder Microsoft Compiler

Das sind aber fast alle bisherigen Benchmarkergebnisse für die Tonne.
Nicht falsch verstehen: Für Leute die die Architekturen an sich betrachten wollen, und im Hintergund behalten, welche Compiler zum Einsatz kamen - ist das Alles ganz nett.
Für alle Anderen ist es ziemlich nutzlos wie ich finde.
Darunter fallen Mandelbrot genauso wie wahrscheinlich Povray und ganz sicher Sandra

[Avalox]

Einen sehr grossen Vorteil werden die K8 aus der SSE3 Kompatibilität ziehen.
Nicht weil SSE3 nun die Antwort auf alle Fragen ist, sondern weil Intels Compiler mächtig den Code optimieren bei setzen der SSE3 Optimierung -QxP.

Andreas Stiller von der c't hat mal spaßeshalber mit -QxP optimierten Code an den K8 angepasst. Nach setzen des Flags, war gar oftmals kein SSE3 Code vorhanden, trotzdem und deshalb lief das Programm um bis zu 30% schneller auf dem K8 als ohne dieses Optimierungsflag.

SSE3 wird momentan von Intel als K8 Bremse genutzt. Schön, wenn AMD nun endlich auch SSE3 unterstützt.

[BlackBirdSR]

Andreas Stiller von der c't hat mal spaßeshalber mit -QxP optimierten Code an den K8 angepasst. Nach setzen des Flags, war gar oftmals kein SSE3 Code vorhanden, trotzdem und deshalb lief das Programm um bis zu 30% schneller auf dem K8 als ohne dieses Optimierungsflag.


Das "Programm" sind einzelne Tests der SpecSuite oder?
Das hat sowieso kaum Aussagekraft für andere Programme.

[Coda]

SSE3 hilft sicher keiner 30%. Wenn dann wurde vorher auch kein SSE2 benützt.

[Avalox]

@BlackBirdSR

Ja. Aber alle einzelnen Test legten u.a. sogar sehr kräftig zu. Einer Tests um 36% auf einem K8.

@Coda

Du hast es nicht richtig gelesen. Nicht SSE3 ist für die Beschleunigung verantwortlich, sondern Optimierungen welche der Intel 64Bit Compiler neben den SSE3 Befehlen bei der -QxP (nur SSE3 CPUs) Einstellung verwendet. Schliesslich hat der K8 noch gar kein SSE3. Trotzdem wurden entsprechend compilierte Programme um bis zu 36% schneller. Wie sich rausstellte führte die SSE3 Optimierung gar nicht in jedem Fall zur Verwendung von SSE3 Code. Andreas Stiller hat dazu die Prozessorabfragen von Hand aus dem Code gepatcht. Diese Programme liefen dann auf einem K8 erheblich schneller, als mit der sonst bei den K8 verwendeten Optimierungen.

SSE3 wird z.Z. von Intel dazu verwendet Compiler Optimierungen nur der eigenen Architektur zugute kommen zu lassen.
Unter dem Vorbehalt einer SSE3 Optimierung, wird der Code generell fortschrittlicher optimiert.

Die SSE3 tauglichen zukünftigen K8 werden von dieser Optimierung partizipieren, ob SSE3 denn nun direkt genutzt wird oder nicht.

Übrigens zog der SSE3 lose K8 deutlich mehr Vorteile aus dieser "SSE3" Optimierung, als der P4 mit EM64T.

[BlackBirdSR]

@BlackBirdSR

Ja. Aber alle einzelnen Test legten u.a. sogar sehr kräftig zu. Einer Tests um 36% auf einem K8.

@Coda

Du hast es nicht richtig gelesen.

Du hast auch nicht richtig gelesen ;)

SpecSuite und "Programme" gleichzusetzen ist sehr riskant.
Die Compiler sind extensiv für die Spectests getuned.
Viele der Compiler existieren nur um bei Spec bessere Werte zu erzielen.

Dass Intels Compiler hier durch mehr Erfahrung und mehr Tricks bessere Ergebnisse erzielen kann, als ein Pathscale oder gcc sollte einleuchten.
Allerdings ist die Transferierbarkeit dieser Ergebnisse auf echte Programme geradezu nicht vorhanden.

Das ist, als würde man die SiSoft Sandra Ergebnisse auf Videocodierung oder Spiele übertragen wollen.

[Avalox]

Da magst du ja auch Recht haben.
Es handelte sich allerdings in beiden Fällen um den selben Compiler und den selben Source. Allein die Compiler Einstellung war eine andere. Es wurde nämlich eine (noch) Intel Only Einstellung gewählt.

Es sind Code Optimierungen welche erst aktiviert werden, wenn das Programm eine Umgebung vorfindet, welche z.Z. nur die Intel eigenen Architekturen liefern. Obwohl die Merkmale dieser Architektur nicht genutzt werden, weshalb diese Optimierung als separat und unabhähgig zu betrachten sind.

Bei Verwendung des -QxP Flags profitieren übrigens nicht nur die SPEC Benchmarks.

[BlackBirdSR]

Da magst du ja auch Recht haben.
Es handelte sich allerdings in beiden Fällen um den selben Compiler und den selben Source. Allein die Compiler Einstellung war eine andere. Es wurde nämlich eine (noch) Intel Only Einstellung gewählt.

Es sind Code Optimierungen welche erst aktiviert werden, wenn das Programm eine Umgebung vorfindet, welche z.Z. nur die Intel eigenen Architekturen liefern. Obwohl die Merkmale dieser Architektur nicht genutzt werden, weshalb diese Optimierung als separat und unabhähgig zu betrachten sind.

Bei Verwendung des -QxP Flags profitieren übrigens nicht nur die SPEC Benchmarks.
Du hast schon recht.
Aber bei echten programmen würde ich die 30% mal sehr anzweifeln, und mich eher auf einstellige Prozentwerte einstellen.
Schließlich ist Intel ziemlich egal, wie der Compiler die meisten unkritischen Programme beschleunigt. Zumal es hier noch Konkurrenten wie Microsoft gibt.

Bei Spec dagegen. Das ist wie ATI und Nvidia Treiber + 3DMark.
Und wie realitätsnah deren Optimierungen für Spiele sind, haben wir ja gesehen.

Ich möchte damit einfach sagen, dass man das Ganze vielleicht nicht so enthusiastisch sehen sollte.

[Ghast]

@Avalox: du hast, was die Optimierung mit QxP angeht, nicht recht. Auch QxN läuft nicht auf AMDs, mich wunderts, dass QxW angeblich auf dem Athlon64 läuft - das hat aber nix mit SSE1/2/3 zu tun, sondern damit dass der Intel Compiler einfach beim Start des compilierten Programms/Tests die CPUID ausliest und das Programm auf nicht-Intel CPUs beendet.

Diese Abfrage hat der Stiller rausgepatcht.

Und nur ein einziger (181.cmf) lief um 36% schneller mit QxP als mit QxW (am 2GHz A64).

[Avalox]

QxP ist eine Optimierung für Prescotts, diese setzt SSE3 voraus.
"The /QxP and /QaxP options (-xP and -axP on Linux) enable optimizations for processors that support the new Intel® Streaming SIMD Extensions 3 (SSE3). We recommend using 'P' for processors that support SSE3"
Aus der Beschreibung des Compilers.

Damit ist diese Optimierung für alle anderen x86 z.Z. tabu, was Intel scheinbar gezielt nutzt. Implementierter SSE3 Code macht diese Anwedungen z.Z. manipulationssicher unausführbar auf CPUs ohne eben SSE3.

[onkel2003]

Zurzeit ist keine aussage möglich.
die anwendungen womit getestet wird sind immer die gleichen.
somit muss natürlich immer das gleiche raus kommen.

da können noch 100 andere seiten testen.

abwarten tee trinken, sobald eine grosse auswahl an programme da ist, ist erst möglich etwas zu testen,
alles was in ersten test war, wird jetzt einfach immer nur wiederholt.

Momentan könnte man fast sagen, man kann sich 2 pc kaufen, einmal läuft es auf intel besser dann wieder amd.
können die da nicht mal irgend wie ne linie rein bringen, oder müssen wir damit leben ?

oder sind es einfach wirklich nur beta test und sagen 0 aus ?

[Ghast]

@Avalox: ich arbeite schon länger mit dem Intel-Compiler und ich hab noch einiges mehr an Dokumentation dazu gelesen. Da brauchst du mich nicht aufklären, was die Switches bedeuten.

Tatsache ist, dass der Compiler prinzipiell verhindert, dass die executables auf nicht-Intel Maschinen laufen. SSE3 ist da komplett wurscht, ausserdem können die 90nm A64er eh SSE3, also was soll das Theater.

Du solltest nicht so oberchefmässig auftreten, wenn du nicht mal eigene Erfahrungen mit dem icl hast.

[zeckensack]

Tatsache ist, dass der Compiler prinzipiell verhindert, dass die executables auf nicht-Intel Maschinen laufen.Äh, jein. Der ICC kann prinzipiell Code erzeugen der auch auf der Konkurrenz lauffähig ist. Zumindest ältere Versionen konnten gar Binaries erzeugen, die den gesamten Code doppelt enthielten, einmal für zB SSE2, und nochmal extra für "plain x86". Die Entscheidung was davon dann läuft wurde direkt beim Start des Programms über eine Prozessor-Identifikation getroffen.

Natürlich wird der ICC seine SSE-Erkennung immer mit der Überprüfung Vendor==GenuineIntel beginnen. Das heißt aber nicht dass die Programme nicht laufen.

Wie das nun genau mit -QxP ist, weiß ich leider nicht, aber ich glaube trotzdem nicht daran dass deine Aussage generell korrekt ist.
SSE3 ist da komplett wurscht, ausserdem können die 90nm A64er eh SSE3, also was soll das Theater.Können sie eben nicht. Die D0-Version, die man seit einiger Zeit kaufen kann, beherrscht nur SSE2. SSE3 (minus monitor und mwait) kommt erst mit E0.

[Tigerchen]

Zurzeit ist keine aussage möglich.
die anwendungen womit getestet wird sind immer die gleichen.
somit muss natürlich immer das gleiche raus kommen.

da können noch 100 andere seiten testen.

abwarten tee trinken, sobald eine grosse auswahl an programme da ist, ist erst möglich etwas zu testen,
alles was in ersten test war, wird jetzt einfach immer nur wiederholt.

Momentan könnte man fast sagen, man kann sich 2 pc kaufen, einmal läuft es auf intel besser dann wieder amd.
können die da nicht mal irgend wie ne linie rein bringen, oder müssen wir damit leben ?

oder sind es einfach wirklich nur beta test und sagen 0 aus ?

Alles gleich? Eben nicht! Sonst hätte ich mir den Thread sparen können!


Ausriß:

Unsere Messungen wiedersprechen dem Testergebnis von xbitlabs.com auf ganzer Linie: Dhrystone, Whetstone und Whetstone SSE zeigen auch beim fünften Durchlauf Vorteile für den Athlon 64 im Zusammenspiel mit dem 64-Bit Windows! Erstaunlich, denn die Vorsprünge für die 64-Bit Plattform in unserem Messungen entspricht in etwa den Vorsprüngen des 32-Bit Windows XP bei xbitlabs.com. Ein Schlem, wer Böses dabei denkt

Bei xbitlabs.com profitiert der Athlon 64 gewaltig im INT/SSE Testlauf, fällt bei FPU/SSE dann aber wieder zurück. Bei uns ist es genau umgekehrt und auch diesmal entsprechen die prozentualen Unterschiede denen von xbitlabs.com, nur eben umgekehrt. Wenn dort mal nicht die Messungsergebnisse vertauscht wurden sind! Eines steht fest: Unsere Ergebnisse sind richtig und doppelt und fünffach geprüft!

[icemanemp]

@Intel Compiler
Schön das man drüber geredet hat! Aber wer patch den bitte die Abfrage VendorID = Intel raus? Welche Firma macht so was? Wahrscheinlich keine! Intel sagt bestimmt als Grund für die Abfrage, das der Code nunmal auf Intel-CPUs optimiert ist und auf AMD nicht garantiert werden kann das es läuft! Jedem von uns ist klar das das zu 99% schwachsinn ist, aber welche Softwareherstellerfirma interssiert das? Kleine Hobbyprojekte können so was machen, aber Software im grossen Stil hab ganz andere Probleme, als das rauszupatchen! Schön wärs,w enn Intel das generell rausmachen würde, aber ob es so weit kommt? Vielleicht steigt AMD ja auch in das Geschäft ein? Wie sieht es eigentlich m Hyperthreading aus? Optimiert der Compiler da auch was? Nicht das AMD, wenn sie ihre Dualcore bringen auch aussen vor steht? (Abgesehen, davon muss ja der Programmierer das meiste machen um richtig Performance aus Mehrfach-CPUs zu holen... sinnvoll gewählten Programmcode in Threads auslagern...)

@Threadthema
Hatte schon Angst, das würde stimmen, das Microsoft AMD bei der 64bit Version wegen Kompatibilität Performancemässig runterschraubt...

[Ghast]

@Zeckensack:
Nur weil man Gast ist, heisst das nicht dass man komplett bescheuert ist. Logo kann der icl prinzipiell Code erzeugen, der auch auf AMD & Co läuft.

Ja es gibt auch alternative cpu paths. Da wird massiv während der Laufzeit gedispatched. Ist übrigens performancemässig ein Nachteil, nachzulesen in der icl-Doku.

Aber: ab icl 8.1 wird prinzipiell auf Intel-CPUs geprüft. Q(a)xN, Q(a)xP laufen unter keinen Umständen auf AMDs, das verhindert diese Abfrage. Nicht weil, da "geheime" Befehle von Northwood oder Prescott zum Einsatz kommen, die auf AMDs Probleme machen würden, sondern schlicht, weil das von Intel nicht gewünscht wird. Hat zu wahnsinnig viel Diskussion zu dem Thema in den Newsgroups/listen geführt.

Rauspatchen ist übrigens gar kein Problem. Hätte den Quellcode für das entsprechende Programm hier liegen.


Lustig, dass jemand mit icl-Erfahrung hier weniger zu sagen hat, als alle anderen, die den icl gerade mal aus dem c't-Artikel kennen...


PS: der icl kann sogar binaries mit 3(!) Code paths (QaxNP: generic, Northwood, Prescott) erzeugen, aber hochoptimiert sind nur die für die Intel cpus.

[Piffan]

Frage: Seit wann kann der K8 SSE 3? Habe ich was verpennt oder kommt das demnächst?.....Sollte wohl noch mal die c't borgen......

[BlackBirdSR]

Frage: Seit wann kann der K8 SSE 3? Habe ich was verpennt oder kommt das demnächst?.....Sollte wohl noch mal die c't borgen......

kommt mit der neuesten 90nm Revision, der auch die DualCore CPUs zugrunde liegen.

[Coda]

Natürlich wird der ICC seine SSE-Erkennung immer mit der Überprüfung Vendor==GenuineIntel beginnen. Das heißt aber nicht dass die Programme nicht laufen.Macht er das wirklich?
Da würde ich als größerer Entwickler aber entsprechend Druck dagegen machen...

[maximAL]

frage am rande: liesse sich statt synthetischer benchmarks nicht was praxisnäheres zum vergleichen finden? dicke open-source software gibts ja mehr als genug...

[Neon3D]

ich erwarte eine nicht gerade berauschende 64bit win version wie beim wechsel von win3.11 zu win95.

[zeckensack]

Macht er das wirklich?
Da würde ich als größerer Entwickler aber entsprechend Druck dagegen machen...Wenn Intel an die Information in den hauseigenen Manuals glaubt ...
GenuineIntel
While any imitator of the Intel Architecture can provide the CPUID instruction, no imitator can
legitimately claim that its part is a genuine Intel part. So, the presence of the “GenuineIntel” string
is an assurance that the CPUID instruction and the processor signature are implemented as
described in this document. If the “GenuineIntel” string is not returned after execution of the
CPUID instruction, do not rely upon the information described in this document to interpret the
information returned by the CPUID instruction.
Quelle (PDF, 573kB) (http://developer.intel.com/design/xeon/applnots/241618.htm)
Mit anderen Worten: Wenn's kein GenuineIntel ist, dann wird denn Feature-Flags jegliche Bedeutung abgesprochen. Glaubt man daran, dann darf man natürlich auch nicht mehr SSE-Support überprüfen, indem man Bit 25 nach CPUID mit EAX=1 testet. Denn Bit 25 bedeutet garnichts, wenn der Vendor-String nicht passt.
(ist natürlich ausgemachter Blödsinn respektive FUD)

Und was für ein Anrecht hättest du als Entwickler, dagegen vorzugehen, wenn der Intel-Compiler diese "Richtiline" befolgt? Es zwingt dich ja keiner, speziell diesen Compiler einzusetzen.

[Ghast]

Ordentlich Druck gegen sowas täte mich nicht stören. Schliesslich ist das gar nicht witzig, wenn eine dll sich einfach so verabschiedet. Hello world täte auf der Konsole ja noch einen Fehler ausgeben (s.u.).

Das Problem besteht nur darin, dass der icl 8.0 ziemlich arge Fehler hat (liest zB nicht richtig über cin ein!), der 8.1 dafür den cpu-dispatcher.

Ach übrigens, nur um die Experten hier mal auf den neuesten Stand zu bringen, Zitat aus den icl-docs:


Caution
If a program compiled with /Qx{K|W|N|B|P} is executed on a non-compatible processor, it might fail with an illegal instruction exception, or display other unexpected behavior. Executing programs compiled with /QxN, /QxB, or /QxP on unsupported processors (see table) will display the following run-time error:

Fatal Error : This program was not built to run on the processor in your system.


In der Tabelle steht dann u.a. (man achte auf "compatible Intel", da steht nicht "Intel compatible"):


/QxN Intel Pentium 4 and compatible Intel processors.

[Coda]

Und was für ein Anrecht hättest du als Entwickler, dagegen vorzugehen, wenn der Intel-Compiler diese "Richtiline" befolgt? Es zwingt dich ja keiner, speziell diesen Compiler einzusetzen.Eben. Dann nehm ich halt nen anderen und Intel bekommt den Auftrag nicht.

[Ghast]

Naja, der icl hat halt Feedback/Profile-Optimierung. Nett sowas. Bei massiv rechenlastigen Sachen hab ich schon blöd geschaut, was das bringt.

Vom reinen Arbeiten her stehe ich ganz auf den gcc/mingw, aber hochperformant? ehm, nö.

VisualStudio 2005 bringt das Feature aber auch.

[Trap]

Feedback/Profile-Optimierung hat gcc auch.