Futuremark bevorzugt Intel-Prozessoren?

Nero24

Administrator
Teammitglied
Mitglied seit
01.07.2000
Beiträge
24.066
Renomée
10.445
  • BOINC Pentathlon 2019
  • BOINC Pentathlon 2020
  • BOINC Pentathlon 2018
  • BOINC Pentathlon 2021
Das Thema "Benchmarking" ist auf den ersten Blick ebenso simpel, wie bei genauerer Betrachtung kontrovers. Man nehme irgendeine Aufgabe, werfe sie verschiedenen Maschinen zum Fraß vor und messe wie lange sie dafür brauchen. Der mit der kürzesten Zeit oder dem höchsten Durchsatz gewinnt das kleine Rennen. So weit, so gut. Bei der Auswahl des Benchmark-Tools jedoch beginnt bereits die Schwierigkeit. Man schicke einen Audi Q7 und einen Porsche 911 auf eine Wettfahrt um die Nürburgring Nordschleife. Der Porsche gewinnt. Warum? Weil der Q7 nicht dafür gebaut wurde. Kann man daraus schließen, dass der Porsche aufgrund dieses "Benchmarks" das bessere Auto ist? Natürlich nicht! Der Porsche gewinnt hier, da er exakt für diese Aufgabe gebaut wurde und der Q7 nicht.

Das selbe Phänomen haben wir seit jeher im Computer-Bereich. Manche Disziplinen liegen dem einen System oder Prozessor besser, manche dem anderen. Das kann an der Art der Programmierung liegen, am Compiler oder an der Aufgabe an sich. Nehmen wir z.B. den integrierten Benchmark im Archiviertool WinRAR. Der Test ist extrem Latenz empfindlich. <a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=326608&garpg=5#content_start">Ein AMD Phenom mit seinem integrierten Memory-Controller lässt einem Core 2 Quad hier keine Chance</a>, selbst wenn er deutlich höher getaktet ist. Ein Fall von Vorteil durch die Aufgabe an sich. Oder das Tool SuperPI. Das Binary wurde 1995 (!) übersetzt. Damals wurde für 486er, bestenfalls für Pentium-Prozessoren compiliert. Der 486er hatte gar keine, der Pentium lediglich eine Fließkomma-Pipeline. AMD-Prozessoren sehen bei diesem Test verdammt alt aus, da K7, K8 und K10 hier keinerlei Nutzen aus ihren drei FPU-Pipelines mit relativ vielen Stufen und langer Latenz ziehen können. Ein Thema für die Abteilung "Codeoptimierung".

Letzteres ist das Dilemma beim benchmarken mit fertigen Binaries. Man weiß nie mit welchem Compiler und welchen Optimierungsflags der Quellcode übersetzt wurde. Aus diesem Grund ermöglicht die weltgrößte Benchmark-Organisation, die SPEC, ihren Teilnehmern aus dem gleichen Quellcode mit verschiedenen Parametern und freier Wahl an Compilern einen für ihren Schützling optimierten Code zu erzeugen. So ist ausgeschlossen, dass dem Prozessor die Optimierungen nicht schmecken. Ferner liegt der Quellcode vor und man kann sich davon überzeugen, dass der Code keinerlei künstliche Bremsen enthält, die das eigene Produkt benachteiligt.

Beim Testen mit fertigen Programmen, wie es im Consumer-Markt meistens der Fall ist, muss man sich auf die gängigen Praxisanwendungen (WinRAR, VirtualDub + DivX/XviD) oder auf synthetische Benchmarks (Sandra, PCMark, 3DMark) verlassen. Und hier geht es für die Hersteller um viel Geld. Wenn das Ergebnis eines häufig benutzten 3DMarks beispielsweise sagt, dass eine Radeon 4850 doppelt so schnell wäre, wie eine GeForce 280, dann ist das wie ein Lottogewinn für das Unternehmen. So gab es bereits vor etlichen Jahren <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1054628971">Streitigkeiten</a> wegen unerlaubter (oder auch nicht?) Optimierungen für den 3DMark03, um im direkten Konkurrrenzkampf besser dazustehen, Optimierungen, die nur in diesem Benchmark greifen und dem Anwender keinerlei Nutzen für echte Spiele brachten.

Im aktuellen Fall jedoch geht es nicht um Optimierungen für den 3DMark von Futuremark, sondern um den PCMark der selben Firma an sich, der sich zum Ziel gesetzt hat die Gesamtleistung eines Systems zu ermitteln. Vor ein paar Tagen jedoch hat <a href="http://arstechnica.com/reviews/hardware/atom-nano-review.ars/6" target="_blank">Arstechnica einen hochinteressanten Artikel veröffentlicht</a>, der die Glaubwürdigkeit des in der Consumer- und Enthusiasten-Welt allseits beliebten PCMark2005 doch arg unterminiert.

Ausgangspunkt für den Test war ein Vergleich zwischen dem <a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=343607">Intel Atom</a> und dem <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1212048231">VIA Nano</a> Prozessor, beides CPUs für den UMPC-Markt, den der Intel Atom gewann. Allerdings haben die Tester von Arstechnica ihren Testkandidaten etwas genauer auf den Zahn gefühlt und zwar auf eine äußerst clevere Art und Weise. Die Tester schnappten sich das VIA Nano System und gaukelten dem PCMark2005 über Manipulationen an der Vendor CPUID des VIA-Prozessors vor, es handle sich nicht um einen VIA, sondern um einen Intel Prozessor. Und was geschah? Obwohl es sich um den selben Prozessor handelte (lediglich mit der CPUID eines Intel versehen), stieg der Wert des Memory-Benchmarks von 1845 auf satte 2721 und lag damit plötzlich vor dem Intel Atom, der lediglich einen Wert von 2428 erreichte.

Normalerweise prüfen Programme beim Start die Features eines Prozessors. "Kann er MMX, 3DNow!, SSE, SSE2, SSE3?", etc. und aktivieren oder deaktivieren daraufhin die ein oder andere Optimierung - was ganz normal ist, da das Programm sofort abstürzen würde, wenn es einem Prozessor, der nur SSE unterstützt, SSE3-Befehle vorsetzen würde. Legitim wäre auch noch die CPU-Familie abzufragen. Ein Pentium 4 benötigt aufgrund seiner Netburst-Architektur mit langer Pipeline und kleinen Caches andere Optimierungen, als ein Core 2 mit mittellangen Pipelines und riesigen Caches. Aber wie kann allein die Änderung der Hersteller-ID derartige Unterschiede bewirken? Aus Interesse änderten die Tester die Vendor-CPUID auch noch auf <i>AuthenticAMD</i>. Hier ergaben sich auch leichte Vorteile gegenüber der VIA Orginal-ID, mit einem Wert von 2012 jedoch deutlich niedrigere.

Nun könnte man argumentieren, dass Futuremark im Jahr 2005, als der PCMark2005 entwickelt wurde, den nagelneuen VIA Nano noch nicht auf der Liste haben und daher nicht wissen konnte, dass VIA-Prozessoren irgendwann einmal SSE, SSE2 und SSE3 unterstützen würden, was für den Memory-Test durchaus relevant ist. Aber woher stammt der Unterschied zwischen der Vendor-ID <i>AuthenticAMD</i> und <i>GenuineIntel</i>? Die AMD-Prozessoren unterstützten SSE und SSE2 bereits seit 2003, SSE3 kam 2005 dazu. Also wieso sinkt der Durchsatz trotzdem von 2721 auf 2012 auf dem selben (VIA-)Prozessor, sobald man dem PCMark2005 einen AMD- statt eines Intel-Prozessors vorgaukelt?

Bereits seit geraumer Zeit gibt es heftige Diskussionen über die Binaries des Intel-Compilers. Hier ist es bei einigen Versionen ähnlich. Sobald man dem Programm vorgaukelt, es liefe nicht mehr auf einem Intel-, sondern auf einem AMD-Prozessor - unabhängig von den unterstützten Befehlssätzen und Features - sinkt die Performance teils empfindlich. Hier könnte man jedoch noch argumentieren, dass der Intel-Compiler von Intel entwickelt und finanziert wurde und Intel alles Recht der Welt hat dafür zu sorgen (selbst künstlich), dass die hauseigenen Prozessoren besser damit laufen, als die des Konkurrenten. Natürlich gibt es auch dazu andere Meinungen und <a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=336249">hier eine Diskussion dazu</a>. Wieso jedoch der PCMark2005, der nicht von Intel, sondern von Futuremark entwickelt wurde, einer Firma, die nach eigener Aussage auf maximale Neutralität bedacht ist, in dieser Weise auf die Vendor-IDs reagiert, das kann wohl nur Futuremark selbst beantworten...
 
In einer Welt (und in Foren), wo solche Benchmarks als Hauptargumente benannt werden für CPU X statt Y, wird sich dieser Artikel kaum auswirken, leider
 
Tragisch dass man so etwas notwendig hat *noahnung*

lg
__tom
 
Im Fall von SuperPi bin ich wohl der einzigste der es nicht so sieht, weil ein K8 einen Pentium 4 hier schlägt ! , sollte ja nicht so sein, wenn der Code rein auf Intel optimiert wäre, zumal ein AMD Prozessor ja ebenfalls zu den IBM kompatiblen CPUs gehört. Und warum regt man sich darüber auf, verstehe ich nicht. Weil dies bei z.b Spielen nicht bemängelt wird, das manches Spiel auf ATI/AMD Karten schneller läuft als bei Nvidia und umgekehrt. Irgendwie scheint das hier ne verkehrte Welt zu sein. Wenn man sich darüber aufregt, dann bitte auf alles schimpfen, was Hersteller A zu B oder umgekehrt bevorteilt oder sich besser :-X und gut ist. Und wenn wir bei CPUs bleiben, war es auch nicht so das 64 Bit Programme auf einem AMD schneller sind, als bei einem Intel der lediglich im 32-Bit Modus punkten kann, meine dies hier auch schon gelesen zu haben. So wird es sicher auch Teile geben, die bei AMD schneller laufen als bei Intel und umgekerht. Warte jetzt auch den nächsten User der dann noch schreibt, das Intel hier auch mal wieder alle Software Hersteller geschmiert hat, damit es für AMD scheiße aussieht, wollen wir das mal glauben, grad jetzt wo AMD in der Tat wirklich in echt langsamer ist, als ein Intel Core mit seinem FSB. Scheinbar ist man momenten auf Intel Basherei aus, und AMD bekommt ne Tüte Mittleid von mir, und nen Arschtritt hinterher das man allgemein mal was bringt was sich gegen den Nehalem bewähren kann, und kein weiteres Mitleid mehr, ich hasse Firmen und Leute die sich nur durch Selbstmitleid durch andere hevorheben weil man nichts gebacken bekommt, da wären mir fast die Flucherhei auf den lahmen Intel Pentium 4 lieber, wenn ich die Wahl hätte. Da AMD da noch in der Blütezeit war. Drehen wir am besten die Zeit zurück, wenn das gehen würde. :]

Dann wäre die Intel Basherei ja z.t noch akzeptabel, aber diese hängt mir mittlerweile echt zum Hals raus, wenn AMD es nicht schafft, haben sie meiner Meinung nach es verdient übernommen zu werden, von einem Hersteller der mehr gebacken bekommt und nicht zu Intel gehört. Das mal dazu ! :]
 
Zuletzt bearbeitet:
Der Hersteller von dem Benchmark verspricht aber absolute Neutralität, was nun mal nicht gegeben ist...

mfg
Chris
 
jetzt würde mich doch mal interessieren, wie die amd cpu mit intel-id läuft? ;D
 
Davon wollte Zidane glaube ich ablenken...*suspect* danke CK][ dass du uns wieder btt gebracht hast ;)

Wovon wollte ich ablenken ?

das momentan Intel Bashing In ist, oder vielmehr andere Hersteller siehe bei den PC-Spielen, und da scheints ja kein Schwein zu interessieren. Oder sehe ich das falsch. Ich sage nur das aus, was ich darüber denke und das das kein neues Thema in dem Sinne ist, nicht mehr und nicht weniger.
 
@Zidane
Warum man sich darüber aufregt? Weil Intel, gerade auch durch den eigenen Compiler, schon seit vielen Jahren Nicht-Intel CPUs benachteiligt. Und das hat nicht nur auf synthetische Benchmarks Auswirkungen, wie im Beispiel, sondern auch auf Real World Anwendungen. Und natürlich auf viele Benchmark Vergleiche. Es geht dabei auch nicht um konkrete Anwendungen, wie Super Pi, sondern einfach ums Prinzip.
 
Im Fall von SuperPi bin ich wohl der einzigste der es nicht so sieht, weil ein K8 einen Pentium 4 hier schlägt ! , sollte ja nicht so sein, wenn der Code rein auf Intel optimiert wäre
Im Falle von SuperPI geht's nicht um Intel oder AMD. Der Pentium 4 ist von der internen Architektur her noch deutlich weiter vom 486er oder Pentium weg, als der K8. Die Pipeline des Pentium 4 ist elendig lang. Wenn der 1995er Compiler den Maschinencode von SuperPI so angeordnet hat, dass nach längstens 10 Takten das Ergebnis einer Instruktion fertig zu sein hat und Nachfolge-Instruktionen darauf zurückgreifen können (sollten), dann ist der Pentium 4 bei SuperPI die längste Zeit damit beschäftigt auf das Ergebnis zu warten, das noch irgendwo in der Pipeline feststeckt oder seine andere Pipeline zu flushen, weil die Speculative Execution mal wieder falsch war. Beim K8 ist dieses Problem aufgrund seiner kürzeren Pipeline nicht ganz so schlimm, daher schlägt er den P4. Dafür hat er ein anderes: wenn die Codeabfolge auf eine FPU-Pipeline optimiert wurde, kann der Dekoder die Instruktionen nicht auf die 3 FPU-Pipelines des K8/K10 verteilen, weil sie aufgrund von Dependences im Code nicht unabgängig voneinander arbeiten können.
zumal ein AMD Prozessor ja ebenfalls zu den IBM kompatiblen CPUs gehört.
Das hat mit IBM kompatibel oder nicht nichts zu tun, sondern mit dem internen Aufbau der CPU. IBM kompatibel heißt ja nur, dass die CPU nach außen hin in Richtung Software den x86-Befehlssatz "vorgaukelt". Was intern in der CPU, hinter dem Dekoder passiert, ist ja wieder eine ganz andere Geschichte. Wie Du sicherlich weißt sind alle x86-Prozessoren seit dem Pentium Pro keine CISC-Prozessoren mehr, sondern arbeiten intern mit RISC-ähnlichen Befehlen und Strukturen. Um trotzdem x86-Kompatibilität zu gewährleisten, ist ein Dekoder vorgeschaltet, der die CISC-Befehle in RISC-Befehle übersetzt. Zum Thema Code-Optimierung empfehle ich dazu mal ein paar frei zugängliche Software Optimierungs Dokumente von AMD und Intel zu lesen. Da sieht man schnell wie weit die Schere der Optimierungsvorschläge durch die Hersteller auseinander geht.

Selbst die Empfehlungen für unterschiedliche Produkte eines Herstellers können sich dramatisch voneinander unterschieden. Beim AMD K6 z.B. hat AMD in seinem Code Optimizing Guide empfohlen für Schleifen den LOOP-Befehl zu verwenden, da LOOP beim K6 ein Short Decode Befehl war und schneller abgearbeitet werden konnte. Ab dem K7 ist genau das Gegenteil der Fall. Hier ist LOOP ein Vector Path Befehl und AMD empfiehlt den Compilerbauern LOOP nicht mehr zu benutzen, sondern stattdessen DEC/JNZ. *noahnung*

Wie Du siehst ist das Problem wesentlich komplexer, als dass es auf die Frage "IBM-kompatibel oder nicht?" reduziert werden könnte.
 
Und warum machen sich die Softwarehersteller nicht die Mühe beide CPUs dahingehend zu optimieren, oder ist der Intel Code leichter zu integrieren als der Code von AMD. Dafür müßte es ja auch einen Grund geben ? - außer den üblichen Verschwörungstheorien. Und des letzteren kann man wohl über Programme die lange Date out sind, sich heute über die mögl. Optimierung kaum beschweren, lediglich über die die zu Zeiten der neuen CPUs weiter entwickelt wurden, ohne eine Optimierung für AMD bekommen zu haben. Ist halt die Frage wie schnell man eine Software für verschiedene Architekturen zugleich optimieren kann. Oder ob man einfach den generellen Intel Code als Std nutzt und alles was davon abweicht, halt nicht optimal läuft. Da dürfte sicher Programmiertechnisch nicht ebend ne Sache von wenigen Minuten sein.

Was den obigen Artikel angeht, verwendet doch VIA sicher andere Codes als der Intel Atom, von daher scheint es bei dem Beispiel nicht am Code sondern lediglich daran zu liegen, das das Programm eine "Intel CPU" erwartet ?

AMD hätte nur das Problem das man hier der CPUs kein Microcodeupdate verpassen kann, geht soweit ich weiß nur bei Intel, sonst könnte man als Gegenprobe sicher mal versuchen den AMD als "Intel" CPU vorzugaukeln.
 
Zuletzt bearbeitet:
Und warum machen sich die Softwarehersteller nicht die Mühe beide CPUs dahingehend zu optimieren, oder ist der Intel Code leichter zu integrieren als der Code von AMD. Dafür müßte es ja auch einen Grund geben ?
Den gibt es! AMD hat keinen eigenen Compiler! Wenn ein Software-Hersteller für AMD optimieren will, muss er den entsprechend optimierten Codeteil manuell per Assembler schreiben :o oder zumindest die AMD Math Libraries verwenden (was ebenfalls ein Umschreiben des Codes per Hand erfordert) was sich natürlich kaum ein kommerziell arbeitendes Unternehmen antut (Zeit ist Geld). Die meisten Software-Häuser verwenden im Windows-Bereich ja sowieso den Microsoft-Compiler. Wer aber unbedingt auf die Architektur eines Intel-Prozessors optimieren möchte, dem macht es Intel leicht, denn Intel hat einen eigenen Compiler. Einfach einbinden in die Microsoft Visual Studio Entwicklungsumgebung und statt der zaghaften Microsoft-Optimierungen (i386, i586 oder i686, MMX/SSE ja/nein) die heftigen Optimierungen des Intel-Compilers auf ganz spezielle CPUs auswählen vor dem bauen der Binaries. Da muss nichts zeitaufwändig per Hand umprogrammiert werden. Einfach Haken setzen und fertig. Das ist der Unterschied bei der Optimierung auf AMD und/oder Intel CPUs. Ich denke das beantwortet, wieso die Software-Häuser es sich kaum antun auf AMD-CPUs zu optimieren. ;)

Aber beim Fall SuperPI hat das gar nichts damit zu tun, ob der Programmierer auf eine Intel-CPU optimieren wollte oder nicht. Im Jahr 1995 gab es schlichtweg keine anderen Architekturen als die von Intel. Der K5, AMDs erste eigene CPU-Architektur, war noch gar nicht auf dem Markt und die AMD-CPUs davor waren Clones von Intel-Prozessoren. Damals stellte sich die Frage also noch gar nicht, auf welchen CPU-Hersteller man optimieren soll. Dass heute, 13 Jahre nachdem SuperPI compiliert wurde, die ein oder andere aktuelle CPU aufgrund ihrer Architektur besser mit dem Uralt-Compilat zurecht kommt, konnte damals gewiss noch niemand beabsichtigt oder gar beeinflusst haben. Das ist heute eben aus verschiedenen Gründen so, aber man kann zumindest anhand des internen Aufbaus der CPUs erklären wieso das so ist (siehe mein letztes Posting).

Aber darum geht's in dem Artikel ja eigentlich gar nicht, oder? ;) Hier geht's um den Futuremark PCMark2005 und dessen merkwürdigem Verhalten beim Ändern der Hersteller-ID auf einem VIA-System.
 
Tragisch dass man so etwas notwendig hat *noahnung*
Full ACK. Tja, haben wohl ein paar Leute zu viele Zuwendungen bekommen bei Futuremark... Nuja, is nur ne Mutmaßung. Aber eine Erklärung für dieses Phänomen wär schon schick (seitens Futuremark).

Was mich aber noch interessiert: Wie kann man die Vendor ID einer CPU ändern? Im BIOS? Per Software?

MfG Dalai
 
Den gibt es! AMD hat keinen eigenen Compiler! Wenn ein Software-Hersteller für AMD optimieren will, muss er den entsprechend optimierten Codeteil manuell per Assembler schreiben :o oder zumindest die AMD Math Libraries verwenden (was ebenfalls ein Umschreiben des Codes per Hand erfordert) was sich natürlich kaum ein kommerziell arbeitendes Unternehmen antut (Zeit ist Geld). Die meisten Software-Häuser verwenden im Windows-Bereich ja sowieso den Microsoft-Compiler. Wer aber unbedingt auf die Architektur eines Intel-Prozessors optimieren möchte, dem macht es Intel leicht, denn Intel hat einen eigenen Compiler. Einfach einbinden in die Microsoft Visual Studio Entwicklungsumgebung und statt der zaghaften Microsoft-Optimierungen (i386, i586 oder i686, MMX/SSE ja/nein) die heftigen Optimierungen des Intel-Compilers auf ganz spezielle CPUs auswählen vor dem bauen der Binaries. Da muss nichts zeitaufwändig per Hand umprogrammiert werden. Einfach Haken setzen und fertig. Das ist der Unterschied bei der Optimierung auf AMD und/oder Intel CPUs. Ich denke das beantwortet, wieso die Software-Häuser es sich kaum antun auf AMD-CPUs zu optimieren. ;)

Aber beim Fall SuperPI hat das gar nichts damit zu tun, ob der Programmierer auf eine Intel-CPU optimieren wollte oder nicht. Im Jahr 1995 gab es schlichtweg keine anderen Architekturen als die von Intel. Der K5, AMDs erste eigene CPU-Architektur, war noch gar nicht auf dem Markt und die AMD-CPUs davor waren Clones von Intel-Prozessoren. Damals stellte sich die Frage also noch gar nicht, auf welchen CPU-Hersteller man optimieren soll. Dass heute, 13 Jahre nachdem SuperPI compiliert wurde, die ein oder andere aktuelle CPU aufgrund ihrer Architektur besser mit dem Uralt-Compilat zurecht kommt, konnte damals gewiss noch niemand beabsichtigt oder gar beeinflusst haben. Das ist heute eben aus verschiedenen Gründen so, aber man kann zumindest anhand des internen Aufbaus der CPUs erklären wieso das so ist (siehe mein letztes Posting).

Aber darum geht's in dem Artikel ja eigentlich gar nicht, oder? ;) Hier geht's um den Futuremark PCMark2005 und dessen merkwürdigem Verhalten beim Ändern der Hersteller-ID auf einem VIA-System.

Sorry, will AMD das nicht ändern oder können sie es nicht ? - nochmal ne Runde Mitleid für AMD, das man den Programmierern kein One Klick Compiler zu Verfügung stellt. :]
 
Ich wäre dafür das AMD bei ihren Black-Edition-CPUs in Zukunft auch die CPUID änderbar macht. Damit lässt sich scheinbar deutlich mehr tunen als mit der besten KoKü.

http://arstechnica.com/reviews/hardware/atom-nano-review.ars/6
>Intel and AMD both lock their CPUIDs to prevent them being changed by a third
>party, but VIA doesn't—and that gives us an opportunity to explore a question that
>normally can't be explored.

Es würde ein für allemal diese Compilerdiskussion beenden, da sich die Öffentlichkeit ohne großartiges Binary-Patchen ein Bild über die tatsächlichen Optimierungsunterschiede machen kann.

Grüße,
Tom
 
@Zidane
Das hat eher geschichtliche Gründe. Lange Zeit gab es praktisch nichts anderes als Intel. Dementsprechend war auch die Erzeugung des µCode auf Intel CPUs zugeschnitten. Erst seit einigen Jahren werden auch Optimierungen für AMD CPUs forciert, siehe GCC oder PGI.
Und die Frage, warum Softwareentwickler sich nicht die Mühe machen, beide CPUs zu unterstützen, ist auch nicht mit 2-3 Sätzen zu beantworten. Erstmal musst du zwischen Compiler Entwicklern und Entwicklern von Anwendungssoftware unterscheiden. Letztere optimieren in dem Sinne sowieso nicht. Die schreiben idR Code in einer Hochsprache und jagen diesen dann durch den Compiler ihrer Wahl. Zwei der am häufigsten benutzten unter Windows sind sicherlich der Microsoft und Intel Compiler. Und Compilerbau wiederum ist eines der komplexesten Themengebiete in der Informatik überhaupt. Hier liegt die Priorität zudem immer noch bei der ISA selbst, nicht bei der jeweiligen Mikroarchitektur. Schliesslich müssen alle x86 CPUs mit dem jeweiligen x86 Code zurechtkommen, egal von welchem Hersteller. Optimierungen auf verschiedene Architekturen verlangen dann wiederum Kompromisse. Hier kommen diverse Compiler Flags zum Einsatz. Usw.usf.
Im Beispiel hier kommt noch eine andere Art von Optimierung als µCode Optimierung zum tragen, nämlich Codepfade. In erster Linie ein Tribut an den Legacy Support. Was allerdings, wie zB im Fall des ICC, auch missbraucht werden kann. Und darum geht es hier.
 
Also braucht AMD für die künftigen CPUs erstmal 2 Sachen ermöglichen.

1. Microcode Update der CPU ermöglichen !
2. 1 Klick Compiler entwerfen, gleiche Vorraussetzungen schaffen !

Was bei VIA klappte, sollte doch mit Intel auch möglich sein, so das die CPU als AMD CPU erkannt wird, damit könnte man perfekt die Gegenprobe machen, Oder ?
 
Sorry, will AMD das nicht ändern oder können sie es nicht?
Erstens können sie nicht, weil die Ressourcen dafür fehlen. Sie versuchen es natürlich, aber auf Intelniveau kämen sie nur mit auch ähnlichem Aufwand, und dafür fehlt eben das Geld.

Ein anderer Punkt ist, daß, obwohl AMD-CPUs durch den Intel-Compiler benachteiligt werden, sie trotzdem oft schneller sind als mit dem Microsoft-Compiler (z.B. Intel +30%, AMD +10% ggü. MS-Compiler). Vom Standpunkt des Softwareentwicklers also eindeutig gut, weil seine Software auf allen Plattformen schneller wird.


Also ich denke, man bräuchte OpenSource-Benchmarks, in denen einerseits die Rechenaufgabe transparent ist, so daß man die Übertragbarkeit auf andere Software einschätzen kann, und die man andererseits mit verschiedenen Compilern und Compilerflags testen kann, so daß auch die Compilerleistung isoliert betrachtet werden kann.
 
Gut, aber in dem Fall hat AMD leider die Arschkarte gezogen, da es heute nunmal so ist das viele Firmen gewinnbringend investieren und dies mit geringsten Arbeitsaufwand. Das die Hersteller dann den leichteren Weg gehen, da kann man keinem die Schuld geben, weder Intel oder Microsoft noch sonst wem, auch wenn es sehr leicht ist die Schuld auf andere zu schieben, wenn was mißlingt. Selbst einzugestehen, das man technologisch hinterher hinkt, für AMD offiziell nicht zu verkaften ist.

Anders sehe es aus, wenn sich Futurmark offiziell dazu äußert den schweren Weg genommen zu haben, und sich hinterher rausstellt das sie den leichteren Weg genommen haben, und dafür dann auch zur Verantwortung gezogen werden sollten. Was ja hier scheinbar auch der Fall ist.

Ansonsten kann ich AMD nur raten, ein paar Kravattenträger zu suspendieren, und sich mit dieser Thematik zu beschäftigen, da Hector dahingehend nichts mehr zu melden hat, sollte man die Prioritäten ändern, das könnte für AMD der Schlag gegen den Nehalem sein, man hätte seit dem Erfolg mit dem K8 damit anfangen sollen. Man wäre dann vielleicht heute soweit gewesen, und mit Intel dahingehen gleichziehen zu können.
 
Also ich denke, man bräuchte OpenSource-Benchmarks, in denen einerseits die Rechenaufgabe transparent ist, so daß man die Übertragbarkeit auf andere Software einschätzen kann, und die man andererseits mit verschiedenen Compilern und Compilerflags testen kann, so daß auch die Compilerleistung isoliert betrachtet werden kann.
Die gibt es ja: die SPEC-Marks. Heise glaube ich testet gelegentlich damit. Aber SPEC CPU 2006 und Co. kosten ebenso ein schweine Geld, wie die Compiler die man dafür benötigt. Für die meisten Magazine und Webseiten, die sich mit Hardware befassen, zu teuer und zu aufwändig. Zudem kommt noch dazu, dass der normale Anwender überhaupt keine Möglichkeit hat, sein System mit anderen Systemen zu vergleichen, daher interessiert den Normaluser der SPEC idR auch nicht. Bei den Populär-Benchmarks wie 3DMark oder PCMark dagegen ist das einfach. Kostenlos runterladen, starten und man bekommt einen Wert. Perfekt für den Anwender, sich in Foren darüber zu unterhalten, zu diskutieren und zu streiten. Und perfekt für den virtuellen "Schw*nzvergleich" :P Mit den SPEC-Marks dagegen fällt all das weg, und daher ist er auch keine Alternative für den Consumer- und Enthusiasten-Bereich *noahnung*
 
...man hätte seit dem Erfolg mit dem K8 damit anfangen sollen. Man wäre dann vielleicht heute soweit gewesen, und mit Intel dahingehen gleichziehen zu können.
OBrian hat es ja eigentlich schon super erläutert wieso AMD das nicht so ohne weiteres kann *noahnung*

Außerdem hatte es AMD in der Vergangenheit oft auch aus verschiedenen Gründen nicht nötig sich einen eigenen Compiler zu leisten. Der AMD K5 und K6 war weitestgehend unabhängig von Software-Optimierungen (FPU mal ausgenommen). Der aufwändige Branch-Predictor, die TLBs und die OoO-Execution, die der direkte Gegenspieler Intel Pentium noch nicht beherrschte, erledigten einen Großteil der Optimierungen in Hardware. Hinzu kam die extrem kurze Pipeline. Selbst wenn mal eine Branch-Prediction daneben ging, war der Penalty dafür nicht groß. Abgesehen davon hätte sich AMD damals nicht einmal ansatzweise ein Projekt wie die Entwicklung eines eigenen Compilers leisten können.

Dann kam der K7 und AMD hatte erst einmal mindestens aufgeschlossen - auch ohne eigenen Compiler.

Zum ersten Mal wurde ein eigener Compiler schmerzlich vermisst, als AMD mit dem Athlon XP in der Sackgasse steckte, der K8 einfach nicht fertig werden wollte und der Pentium 4 nach Anfangsschwierigkeiten a.) endlich auf Takt kam und b.) Intel dank seines Compilers einige Hersteller von häufig verwendeten Programmen zur Leistungsmessung dazu animieren konnte Optimierungen für die ungewöhnliche Architektur des P4 vorzunehmen. Plötzlich legte der Pentium 4 bei Tests so richtig los, wo er bei der Vorgängerversion des Programms noch deutlich unterlegen war. :o

Dann kam der K8 und AMD hatte beinahe 3 Jahre lang die Oberhand. Auch hier stellte sich für AMD die Frage, warum sich einen eigenen Compiler leisten, wenn es auch so geht?

Traditionell legt AMD seit dem K5 großen Wert auf Code-Optimierung auf Hardware-Basis, eben um den fehlenden Compiler zu kompensieren. Bei Intel ist es tendenziell genau anders herum gewesen. Der Extremfall ist hier der erste Itanium, der in Hardware überhaupt keine Optimierungs-Mechanismen besaß, nicht einmal Out-of-Order-Execution und Intel offen sagte, dass Code-Optimierung Aufgabe des Compilers sei, nicht des Prozessors. Auch der P4 war auf guten Code angewiesen wie gesehen und der neue Atom verzichtet ebenfalls auf OoO. Nur der Core 2 bildet hier eine Ausnahme. Der hat mehr Optimierungsmechanismen in Hardware als alle anderen Intel-Prozessoren davor zusammen genommen und kann sich auf einen eigenen Compiler stützen. Insofern der Idealfall und sicherlich mit ein Grund, wieso der C2D/Q derzeit so gut läuft.
 
Also braucht AMD für die künftigen CPUs erstmal 2 Sachen ermöglichen.

1. Microcode Update der CPU ermöglichen !
2. 1 Klick Compiler entwerfen, gleiche Vorraussetzungen schaffen !
Nein und nein. Falls du mit 1. den cpuid Hersteller String meinst, das ist ja mehr oder weniger eine Spielerei und für den Markt nicht praktikabel. Und bzgl. 2., "1 Klick Compiler" gibt es nicht. Du hast hier eine scheinbar etwas zu "blumige" Vorstellung. Welcher Compiler verwendet wird, hängt erstmal von diversen Faktoren ab. Und sind diese geklärt, ist der Aufwand dann auch immer gleich. Nur das Resultat uU nicht.

Was bei VIA klappte, sollte doch mit Intel auch möglich sein, so das die CPU als AMD CPU erkannt wird, damit könnte man perfekt die Gegenprobe machen, Oder ?
Nochmal, AMD und Intel ermöglichen keine Änderung des cpuid Hersteller Strings. Daher ist eine Gegenprobe nicht möglich.

Erstens können sie nicht, weil die Ressourcen dafür fehlen. Sie versuchen es natürlich, aber auf Intelniveau kämen sie nur mit auch ähnlichem Aufwand, und dafür fehlt eben das Geld.
Was momentan auch eher sinnfrei wäre. In Verbindung mit dem PGI Compiler hat man doch gesehen, dass hier eine sehr gute Lösung vorhanden ist, die selbst den ICC hinter sich lässt. Und ob AMD einen eigenen Compiler braucht, ist wohl auch eher eine philosophische Frage. Da könnte man genauso gut fragen, ob Microsoft eine eigene CPU braucht. Wichtiger ist erstmal, dass man verschiedene Compilerhersteller gewinnt und diese unterstützt. Und da sind zumindest positive Trends zu erkennen, siehe MSC oder GCC.

Ein anderer Punkt ist, daß, obwohl AMD-CPUs durch den Intel-Compiler benachteiligt werden, sie trotzdem oft schneller sind als mit dem Microsoft-Compiler (z.B. Intel +30%, AMD +10% ggü. MS-Compiler). Vom Standpunkt des Softwareentwicklers also eindeutig gut, weil seine Software auf allen Plattformen schneller wird.
Naja, der Vergleich hinkt aber etwas. :) Der ICC muss lizenziert werden, kostet also richtig Kohle. Wie andere hochentwickelte Compiler auch (PGI, COMEAU, ...). Der Microsoft Compiler ist mittlerweile kostenfrei, gerade die Optimizing Version. Das war nicht immer so. Früher gab es zB noch eine Basic Version, welche ausschliesslich kostenfrei war. Vom Standpunkt des Softwareentwicklers also eher eine Kosten-Nutzen-Frage.
 
Kann AMD nicht selbst einen Compiler rausbringen?
Vielleicht sogar einen AMD64 basierenden..

Vor einigen Jahren hat unser EDV-Lehrer in der Schule gemeint, dass es bald 128bit CPUs geben wird. Ist nun schon lange her... ist das Überhaupt notwendig? Wäre diese Technikentwicklung nicht schon überfällig und sogar schon 256 od 512 ausständig?? Würde das überhaupt was bringen??
 
Das ist ein waschechter Skandal. Punkt. Aus. Ende
 
Zurück
Oben Unten