Seite 1 von 7 12345 ... LetzteLetzte
Ergebnis 1 bis 25 von 156
  1. Beitrag #1
    Themenstarter
    Administration Avatar von Nero24.

    Registriert seit
    01.07.2000
    Beiträge
    19.528
    Danke Danke gesagt 
    10
    Danke Danke erhalten 
    8.363
    Blog-Einträge
    24

    Futuremark bevorzugt Intel-Prozessoren?

    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. Ein AMD Phenom mit seinem integrierten Memory-Controller lässt einem Core 2 Quad hier keine Chance, 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 Streitigkeiten 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 Arstechnica einen hochinteressanten Artikel veröffentlicht, 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 Intel Atom und dem VIA Nano 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 AuthenticAMD. 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 AuthenticAMD und GenuineIntel? 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 hier eine Diskussion dazu. 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...

  2. Die folgenden 37 Benutzer sagen Danke zu Nero24. für diesen nützlichen Beitrag:

    -cb- (03.08.2008), Abrissbirne (01.08.2008), birki2k (01.08.2008), boidsen (01.08.2008), brabe (01.08.2008), Bruce-Willes (31.07.2008), Campari (01.08.2008), Cr@zed^ (03.08.2008), CrazyStrump (06.08.2008), Dalai (01.08.2008), Dirty4488 (04.08.2008), Drohne (01.08.2008), efxm (01.08.2008), genervt (01.08.2008), Gruß Thomas! (02.08.2008), kaluschi (01.08.2008), KIDH (01.08.2008), LehmannSaW (01.08.2008), Menace (31.07.2008), Micheck (01.08.2008), Oi!Olli (06.08.2008), otti503 (01.08.2008), Peet007 (31.07.2008), psychocyberdisc (01.08.2008), rkinet (31.07.2008), Scour (31.07.2008), Simsn (01.08.2008), SpitfireXP (01.08.2008), Takato (01.08.2008), tomturbo (31.07.2008), Treverer (01.08.2008), unbekannt verzogen (01.08.2008), uncle_sam (01.08.2008), Undergroundking (01.08.2008), Vor7ex (01.08.2008), Wedge (01.08.2008), yahlov (01.08.2008)

  3. Beitrag #2
    Grand Admiral
    Special
    Grand Admiral
    • Mein System
      Notebook
      Modell: Fujitsu AH530
      Desktopsystem
      Prozessor: Intel i5-3470 (Austausch)
      Mainboard: Asus P8Z77-V LX (RIP MSI Z77A-G45)
      Kühlung: LC-Power Cosmo Cool LC-CC95
      Arbeitsspeicher: 8GB Crucial DDR3-1600
      Grafikkarte: Zotac 260 GTX
      Display: Acer LED S1 S221HQLbid
      SSD(s): Plextor M5S, Crucial M4, Sandisk SSD U100, Sandisk Ultra Plus, Crucial M500
      Festplatte(n): WD 10EALS. ST1500DM003, WD20EARS, HD154UI
      Optische Laufwerke: LG GH-20NS, Pioneer BDR-208
      Soundkarte: Onboard
      Gehäuse: NoName
      Netzteil: Seasonic G450
      Betriebssystem(e): WinXP Pro, W7 HP 64 Bit, W8.1 64 Bit
      Browser: Firefox
      Sonstiges: So, sollte für eine Weile reichen :)

    Registriert seit
    17.03.2002
    Beiträge
    3.987
    Danke Danke gesagt 
    137
    Danke Danke erhalten 
    10
    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

  4. Beitrag #3
    Vice Admiral
    Special
    Vice Admiral
    Avatar von MR2

    Registriert seit
    21.08.2002
    Ort
    Sachsen - Erzgebirge -
    Beiträge
    836
    Danke Danke gesagt 
    9
    Danke Danke erhalten 
    6
    Intel ist die "Achse des Bösen", aber wie man auch hier im Forum sieht begreifen das viele nicht.

  5. Beitrag #4
    Technische Administration
    Dinosaurier

    Avatar von tomturbo
    • Mein System
      Notebook
      Modell: Microsoft Surface Pro 4
      Desktopsystem
      Prozessor: Phenom II X6 1045T
      Mainboard: Gigabyte 970A-UD3
      Kühlung: CoolerMaster Hyper 412S
      Arbeitsspeicher: 2x8GB Crucial Ballistix Tactical DDR3-1866
      Grafikkarte: Sapphire R7 250E ultimate / lüfterlos
      Display: HP ZR2740w (2560x1440)
      SSD(s): 2xSamsung 830 128GB
      Festplatte(n): Seagate ST31500341AS 1500GB
      Optische Laufwerke: Samsung Brenner
      Soundkarte: onboard
      Gehäuse: Fractal Design Define R4
      Netzteil: XFX 550W
      Betriebssystem(e): Arch Linux, Windows VM
      Browser: Firefox + Chromium + Konqueror
    • Mein DC

      tomturbo beim Distributed Computing

      Aktuelle Projekte: SETI@HOME
      Lieblingsprojekt: SETI@HOME
      Rechner: Xeon E3-1245V2; Raspberry Pi 2
      Mitglied der Kavallerie: Nein
      BOINC-Statistiken:

    Registriert seit
    30.11.2005
    Ort
    Österreich
    Beiträge
    6.742
    Danke Danke gesagt 
    205
    Danke Danke erhalten 
    8
    Tragisch dass man so etwas notwendig hat

    lg
    __tom

  6. Beitrag #5
    Grand Admiral
    Special
    Grand Admiral
    Avatar von Zidane
    • Mein System
      Desktopsystem
      Prozessor: Ryzen 1700
      Mainboard: Asus B350 Prime Plus
      Kühlung: AMD Wraith Kühler
      Arbeitsspeicher: 2x 4GB Crucial DDR4-2666 SR ECC
      Grafikkarte: Geforce G210 (Geforce 1050TI) geplant
      Display: Eizo S1932-SH 8ms 19" 1280x1024@75Hz DVI
      SSD(s): Crucial MX-200 500GB
      Optische Laufwerke: LiteOn BR-Combo iHES212
      Soundkarte: Asus Xonar D1 7.1 + Creative FPS 1600
      Gehäuse: Thermaltake Level 10 GTS Snow Edition
      Netzteil: Cougar GX-S 450W
      Betriebssystem(e): Windows 10 Pro 64
      Browser: Edge, Opera
      Sonstiges: HP CP 1525n, Canon Lide 50, MX 1000

    Registriert seit
    11.11.2001
    Beiträge
    11.700
    Danke Danke gesagt 
    110
    Danke Danke erhalten 
    87
    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 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 !
    Geändert von Zidane (01.08.2008 um 00:21 Uhr)

  7. Beitrag #6
    Vice Admiral
    Special
    Vice Admiral
    Avatar von CK][
    • Mein System
      Desktopsystem
      Prozessor: AMD Athlon64 3500+ So.939 Venice
      Mainboard: ASUS A8V Deluxe Rev. 2.0
      Kühlung: AVC Boxed Kühler für Athlon64
      Arbeitsspeicher: 2x 512MB Corsair ValueSelect DDR 400mhz cl 2.5
      Grafikkarte: Xpertvision Radeon X850XT AGP
      Display: 17 Zoll Samtron 75E @ 1280x1024
      Festplatte(n): Maxtor DiamondMax8 40GB(C)
      Optische Laufwerke: LG GSA-H42L (DVD-Brenner)
      Soundkarte: Onboard Realtek AL850
      Gehäuse: OEM-Teil
      Netzteil: Enermax Freiheit 400W
      Betriebssystem(e): Windows XP Professional ; Ubuntu 8.04
      Browser: Mozilla Firefox

    Registriert seit
    17.01.2005
    Ort
    Niedersachsen
    Beiträge
    575
    Danke Danke gesagt 
    14
    Danke Danke erhalten 
    0
    Der Hersteller von dem Benchmark verspricht aber absolute Neutralität, was nun mal nicht gegeben ist...

    mfg
    Chris

  8. Beitrag #7
    Commodore
    Special
    Commodore
    Avatar von unbekannt verzogen

    Registriert seit
    19.10.2007
    Beiträge
    363
    Danke Danke gesagt 
    33
    Danke Danke erhalten 
    5
    Davon wollte Zidane glaube ich ablenken... danke CK][ dass du uns wieder btt gebracht hast

  9. Beitrag #8
    Lieutenant
    Lieutenant
    Avatar von TommiX1980
    • Mein System
      Desktopsystem
      Prozessor: AMD RyZen 5 1600X
      Mainboard: MSI X370 Gaming Plus
      Kühlung: Arctic Freezer 33
      Arbeitsspeicher: 2x 8GB Crucial Ballistix Sport LT DDR4-2666
      Grafikkarte: Sapphire Radeon R9 290 Tri-X OC 4GB
      Display: Philips 274E
      SSD(s): Samsung 850 EVO 250 GB
      Festplatte(n): Toshiba MD04ACA400 4TB
      Optische Laufwerke: LG BH10LS38 interner Blu-ray 10x Brenner
      Soundkarte: ESI Maya44e
      Gehäuse: Cooler Master Masterbox 5 mit Sichtfenster und CONVERSION KIT FOR 5,25"SUPPORT
      Netzteil: Enermax Triathlor ECO 550W
      Betriebssystem(e): Windows 10 64Bit V.1703
      Browser: Opera
      sysProfile: System bei sysProfile

    Registriert seit
    22.11.2007
    Ort
    Wimmelburg
    Beiträge
    64
    Danke Danke gesagt 
    276
    Danke Danke erhalten 
    0
    jetzt würde mich doch mal interessieren, wie die amd cpu mit intel-id läuft?

  10. Beitrag #9
    Grand Admiral
    Special
    Grand Admiral
    Avatar von Zidane
    • Mein System
      Desktopsystem
      Prozessor: Ryzen 1700
      Mainboard: Asus B350 Prime Plus
      Kühlung: AMD Wraith Kühler
      Arbeitsspeicher: 2x 4GB Crucial DDR4-2666 SR ECC
      Grafikkarte: Geforce G210 (Geforce 1050TI) geplant
      Display: Eizo S1932-SH 8ms 19" 1280x1024@75Hz DVI
      SSD(s): Crucial MX-200 500GB
      Optische Laufwerke: LiteOn BR-Combo iHES212
      Soundkarte: Asus Xonar D1 7.1 + Creative FPS 1600
      Gehäuse: Thermaltake Level 10 GTS Snow Edition
      Netzteil: Cougar GX-S 450W
      Betriebssystem(e): Windows 10 Pro 64
      Browser: Edge, Opera
      Sonstiges: HP CP 1525n, Canon Lide 50, MX 1000

    Registriert seit
    11.11.2001
    Beiträge
    11.700
    Danke Danke gesagt 
    110
    Danke Danke erhalten 
    87
    Zitat Zitat von unbekannt verzogen Beitrag anzeigen
    Davon wollte Zidane glaube ich ablenken... 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.

  11. Beitrag #10
    Grand Admiral
    Special
    Grand Admiral
    Avatar von gruffi
    • Mein System
      Desktopsystem
      Prozessor: AMD Ryzen 5 1600
      Mainboard: MSI B350M PRO-VDH
      Kühlung: Wraith Spire
      Arbeitsspeicher: 2x 8 GB DDR4-2400 CL16
      Grafikkarte: XFX Radeon R7 260X
      Display: LG W2361
      SSD(s): Crucial CT250BX100SSD1
      Festplatte(n): Toshiba DT01ACA200
      Optische Laufwerke: LG Blu-Ray-Brenner BH16NS40
      Soundkarte: Realtek HD Audio
      Gehäuse: Sharkoon MA-I1000
      Netzteil: be quiet! Pure Power 9 350W
      Betriebssystem(e): Windows 10 Professional 64-bit
      Browser: Mozilla Firefox
      Sonstiges: https://valid.x86.fr/mb4f0j

    Registriert seit
    08.03.2008
    Ort
    vorhanden
    Beiträge
    3.619
    Danke Danke gesagt 
    96
    Danke Danke erhalten 
    14
    @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.

  12. Beitrag #11
    Themenstarter
    Administration Avatar von Nero24.

    Registriert seit
    01.07.2000
    Beiträge
    19.528
    Danke Danke gesagt 
    10
    Danke Danke erhalten 
    8.363
    Blog-Einträge
    24
    Zitat Zitat von Zidane Beitrag anzeigen
    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.

    Wie Du siehst ist das Problem wesentlich komplexer, als dass es auf die Frage "IBM-kompatibel oder nicht?" reduziert werden könnte.

  13. Beitrag #12
    Grand Admiral
    Special
    Grand Admiral
    Avatar von Zidane
    • Mein System
      Desktopsystem
      Prozessor: Ryzen 1700
      Mainboard: Asus B350 Prime Plus
      Kühlung: AMD Wraith Kühler
      Arbeitsspeicher: 2x 4GB Crucial DDR4-2666 SR ECC
      Grafikkarte: Geforce G210 (Geforce 1050TI) geplant
      Display: Eizo S1932-SH 8ms 19" 1280x1024@75Hz DVI
      SSD(s): Crucial MX-200 500GB
      Optische Laufwerke: LiteOn BR-Combo iHES212
      Soundkarte: Asus Xonar D1 7.1 + Creative FPS 1600
      Gehäuse: Thermaltake Level 10 GTS Snow Edition
      Netzteil: Cougar GX-S 450W
      Betriebssystem(e): Windows 10 Pro 64
      Browser: Edge, Opera
      Sonstiges: HP CP 1525n, Canon Lide 50, MX 1000

    Registriert seit
    11.11.2001
    Beiträge
    11.700
    Danke Danke gesagt 
    110
    Danke Danke erhalten 
    87
    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.
    Geändert von Zidane (01.08.2008 um 00:58 Uhr)

  14. Beitrag #13
    Themenstarter
    Administration Avatar von Nero24.

    Registriert seit
    01.07.2000
    Beiträge
    19.528
    Danke Danke gesagt 
    10
    Danke Danke erhalten 
    8.363
    Blog-Einträge
    24
    Zitat Zitat von Zidane Beitrag anzeigen
    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 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.

  15. Beitrag #14
    Grand Admiral
    Special
    Grand Admiral
    Avatar von Dalai
    • Mein System
      Notebook
      Modell: Thinkpad T43 mit 15" UXGA (1600x1200), 2x 1 GiB RAM, 100GB HD, Bluetooth, GBit LAN, ATi X300
      Desktopsystem
      Prozessor: AMD Athlon X4 880K (Godavari)
      Mainboard: Gigabyte GA-F2A88X-D3HP
      Kühlung: Noctua NH-U9B mit 2x NF-B9 Redux PWM (an NA-YC1)
      Arbeitsspeicher: G.Skill Ares F3-2133C11D-16GAR: 2x 8 GiB DDR3-2133 (3,5 GiB nutzbar mit x86)
      Grafikkarte: Gigabyte GeForce GTX 650 Ti, 1024 MiB, Rev 2.0
      Display: Dell U2410, 24 Zoll, IPS, 16:10
      SSD(s): Samsung 850 Evo 250 GB
      Festplatte(n): WD20EZRZ (WD Blue) 2000GB SATA3, WD20EZRX (WD Green) 2000GB SATA3
      Optische Laufwerke: Pio DVR-212 (DVD-RAM), ASUS E818A6T (DVD-ROM), Pio DVD-106S (Slot-in DVD-ROM)
      Soundkarte: Creative SoundBlaster Audigy 2 ZS PCI
      Gehäuse: Lian Li PC-8NB Midi-Tower
      Netzteil: Enermax EMP400AGT MaxPro 400W
      Betriebssystem(e): Windows 7 Professional x64 und immer mal wieder ein neues Linux :-)
      Browser: Mozilla Firefox mit diversen Erweiterungen
      Sonstiges: 2x 120mm Gehäuselüfter (Front und Rückwand), DVBSky T9580, Sharkoon Frontpanel B (2x USB 3.0)

    Registriert seit
    14.06.2004
    Ort
    Meiningen, Thüringen
    Beiträge
    6.959
    Danke Danke gesagt 
    390
    Danke Danke erhalten 
    47
    Zitat Zitat von tomturbo Beitrag anzeigen
    Tragisch dass man so etwas notwendig hat
    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

  16. Beitrag #15
    Grand Admiral
    Special
    Grand Admiral
    Avatar von Zidane
    • Mein System
      Desktopsystem
      Prozessor: Ryzen 1700
      Mainboard: Asus B350 Prime Plus
      Kühlung: AMD Wraith Kühler
      Arbeitsspeicher: 2x 4GB Crucial DDR4-2666 SR ECC
      Grafikkarte: Geforce G210 (Geforce 1050TI) geplant
      Display: Eizo S1932-SH 8ms 19" 1280x1024@75Hz DVI
      SSD(s): Crucial MX-200 500GB
      Optische Laufwerke: LiteOn BR-Combo iHES212
      Soundkarte: Asus Xonar D1 7.1 + Creative FPS 1600
      Gehäuse: Thermaltake Level 10 GTS Snow Edition
      Netzteil: Cougar GX-S 450W
      Betriebssystem(e): Windows 10 Pro 64
      Browser: Edge, Opera
      Sonstiges: HP CP 1525n, Canon Lide 50, MX 1000

    Registriert seit
    11.11.2001
    Beiträge
    11.700
    Danke Danke gesagt 
    110
    Danke Danke erhalten 
    87
    Zitat Zitat von Nero24 Beitrag anzeigen
    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 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.

  17. Beitrag #16
    Admiral
    Special
    Admiral
    Avatar von mocad_tom

    Registriert seit
    17.06.2004
    Beiträge
    1.212
    Danke Danke gesagt 
    3
    Danke Danke erhalten 
    19
    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/hardw...o-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

  18. Beitrag #17
    Grand Admiral
    Special
    Grand Admiral
    Avatar von gruffi
    • Mein System
      Desktopsystem
      Prozessor: AMD Ryzen 5 1600
      Mainboard: MSI B350M PRO-VDH
      Kühlung: Wraith Spire
      Arbeitsspeicher: 2x 8 GB DDR4-2400 CL16
      Grafikkarte: XFX Radeon R7 260X
      Display: LG W2361
      SSD(s): Crucial CT250BX100SSD1
      Festplatte(n): Toshiba DT01ACA200
      Optische Laufwerke: LG Blu-Ray-Brenner BH16NS40
      Soundkarte: Realtek HD Audio
      Gehäuse: Sharkoon MA-I1000
      Netzteil: be quiet! Pure Power 9 350W
      Betriebssystem(e): Windows 10 Professional 64-bit
      Browser: Mozilla Firefox
      Sonstiges: https://valid.x86.fr/mb4f0j

    Registriert seit
    08.03.2008
    Ort
    vorhanden
    Beiträge
    3.619
    Danke Danke gesagt 
    96
    Danke Danke erhalten 
    14
    @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.

  19. Beitrag #18
    Grand Admiral
    Special
    Grand Admiral
    Avatar von Zidane
    • Mein System
      Desktopsystem
      Prozessor: Ryzen 1700
      Mainboard: Asus B350 Prime Plus
      Kühlung: AMD Wraith Kühler
      Arbeitsspeicher: 2x 4GB Crucial DDR4-2666 SR ECC
      Grafikkarte: Geforce G210 (Geforce 1050TI) geplant
      Display: Eizo S1932-SH 8ms 19" 1280x1024@75Hz DVI
      SSD(s): Crucial MX-200 500GB
      Optische Laufwerke: LiteOn BR-Combo iHES212
      Soundkarte: Asus Xonar D1 7.1 + Creative FPS 1600
      Gehäuse: Thermaltake Level 10 GTS Snow Edition
      Netzteil: Cougar GX-S 450W
      Betriebssystem(e): Windows 10 Pro 64
      Browser: Edge, Opera
      Sonstiges: HP CP 1525n, Canon Lide 50, MX 1000

    Registriert seit
    11.11.2001
    Beiträge
    11.700
    Danke Danke gesagt 
    110
    Danke Danke erhalten 
    87
    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 ?

  20. Beitrag #19
    Moderation MBDB
    Moderation
    Avatar von OBrian
    • Mein System
      Desktopsystem
      Prozessor: Phenom II X4 940 BE, C2-Stepping (undervolted)
      Mainboard: Gigabyte GA-MA69G-S3H (BIOS F7)
      Kühlung: Noctua NH-U12F
      Arbeitsspeicher: 4 GB DDR2-800 ADATA/OCZ
      Grafikkarte: Radeon HD 5850
      Display: NEC MultiSync 24WMGX³
      SSD(s): Samsung 840 Evo 256 GB
      Festplatte(n): WD Caviar Green 2 TB (WD20EARX)
      Optische Laufwerke: Samsung SH-S183L
      Soundkarte: Creative X-Fi EM mit YouP-PAX-Treibern, Headset: Sennheiser PC350
      Gehäuse: Coolermaster Stacker, 120mm-Lüfter ersetzt durch Scythe S-Flex, zusätzliche Staubfilter
      Netzteil: BeQuiet 500W PCGH-Edition
      Betriebssystem(e): Windows 7 x64
      Browser: Firefox
      Sonstiges: Tastatur: Zowie Celeritas Caseking-Mod (weiße Tasten)

    Registriert seit
    16.10.2000
    Ort
    NRW
    Beiträge
    15.184
    Danke Danke gesagt 
    0
    Danke Danke erhalten 
    61
    Zitat Zitat von Zidane Beitrag anzeigen
    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.

  21. Beitrag #20
    Grand Admiral
    Special
    Grand Admiral
    Avatar von Zidane
    • Mein System
      Desktopsystem
      Prozessor: Ryzen 1700
      Mainboard: Asus B350 Prime Plus
      Kühlung: AMD Wraith Kühler
      Arbeitsspeicher: 2x 4GB Crucial DDR4-2666 SR ECC
      Grafikkarte: Geforce G210 (Geforce 1050TI) geplant
      Display: Eizo S1932-SH 8ms 19" 1280x1024@75Hz DVI
      SSD(s): Crucial MX-200 500GB
      Optische Laufwerke: LiteOn BR-Combo iHES212
      Soundkarte: Asus Xonar D1 7.1 + Creative FPS 1600
      Gehäuse: Thermaltake Level 10 GTS Snow Edition
      Netzteil: Cougar GX-S 450W
      Betriebssystem(e): Windows 10 Pro 64
      Browser: Edge, Opera
      Sonstiges: HP CP 1525n, Canon Lide 50, MX 1000

    Registriert seit
    11.11.2001
    Beiträge
    11.700
    Danke Danke gesagt 
    110
    Danke Danke erhalten 
    87
    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.

  22. Beitrag #21
    Themenstarter
    Administration Avatar von Nero24.

    Registriert seit
    01.07.2000
    Beiträge
    19.528
    Danke Danke gesagt 
    10
    Danke Danke erhalten 
    8.363
    Blog-Einträge
    24
    Zitat Zitat von OBrian Beitrag anzeigen
    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" Mit den SPEC-Marks dagegen fällt all das weg, und daher ist er auch keine Alternative für den Consumer- und Enthusiasten-Bereich

  23. Beitrag #22
    Themenstarter
    Administration Avatar von Nero24.

    Registriert seit
    01.07.2000
    Beiträge
    19.528
    Danke Danke gesagt 
    10
    Danke Danke erhalten 
    8.363
    Blog-Einträge
    24
    Zitat Zitat von Zidane Beitrag anzeigen
    ...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

    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.

    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.

  24. Beitrag #23
    Grand Admiral
    Special
    Grand Admiral
    Avatar von gruffi
    • Mein System
      Desktopsystem
      Prozessor: AMD Ryzen 5 1600
      Mainboard: MSI B350M PRO-VDH
      Kühlung: Wraith Spire
      Arbeitsspeicher: 2x 8 GB DDR4-2400 CL16
      Grafikkarte: XFX Radeon R7 260X
      Display: LG W2361
      SSD(s): Crucial CT250BX100SSD1
      Festplatte(n): Toshiba DT01ACA200
      Optische Laufwerke: LG Blu-Ray-Brenner BH16NS40
      Soundkarte: Realtek HD Audio
      Gehäuse: Sharkoon MA-I1000
      Netzteil: be quiet! Pure Power 9 350W
      Betriebssystem(e): Windows 10 Professional 64-bit
      Browser: Mozilla Firefox
      Sonstiges: https://valid.x86.fr/mb4f0j

    Registriert seit
    08.03.2008
    Ort
    vorhanden
    Beiträge
    3.619
    Danke Danke gesagt 
    96
    Danke Danke erhalten 
    14
    Zitat Zitat von Zidane Beitrag anzeigen
    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.

    Zitat Zitat von Zidane Beitrag anzeigen
    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.

    Zitat Zitat von OBrian Beitrag anzeigen
    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.

    Zitat Zitat von OBrian Beitrag anzeigen
    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.

  25. Beitrag #24
    Vice Admiral
    Special
    Vice Admiral
    Avatar von yahlov
    • Mein System
      Desktopsystem
      Prozessor: AM2 X2 5000+ BE
      Mainboard: Asus M2A-VM HDMI
      Kühlung: Alphacool NexXxos X2+
      Arbeitsspeicher: 4x 1GB
      Grafikkarte: ATI x1250 @64MB
      Display: Philips TFT 20"
      Festplatte(n): WD Raptor 150GB, 2x Samsung F1 RAID-1
      Optische Laufwerke: Pioneer Slot-In
      Gehäuse: YY-Cube B0221
      Netzteil: Corsair VX450
      Betriebssystem(e): tweaked XP SP3
      Browser: Firefox 3.0
      Sonstiges: Wak » Aquaduct 360XT MK2

    Registriert seit
    02.04.2007
    Beiträge
    653
    Danke Danke gesagt 
    82
    Danke Danke erhalten 
    1
    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??

  26. Beitrag #25
    Vice Admiral
    Special
    Vice Admiral
    Avatar von genervt
    • Mein System
      Notebook
      Modell: Leonvo E145
      Desktopsystem
      Prozessor: XEON 1230v2
      Mainboard: H61M-K [Ersatz]
      Kühlung: Brocken
      Arbeitsspeicher: 16 GB Corsair
      Grafikkarte: RX480 8GB
      Display: BenQ BL3200PT - 30 Zoll - 1440p
      SSD(s): Crucial MX100, BX200
      Festplatte(n): 1x 750GB 1x 3 TB
      Optische Laufwerke: LG BH10LS30
      Soundkarte: Xonar DX
      Gehäuse: Fractal
      Netzteil: BeQuiet
      Betriebssystem(e): Win7 64bit, Win10
      Browser: Firefox
      Sonstiges: im Umbau
    • Mein DC

      genervt beim Distributed Computing

      Aktuelle Projekte: NumberFields
      Mitglied der Kavallerie: Nein
      BOINC-Statistiken:

    Registriert seit
    27.07.2006
    Ort
    Berlin
    Beiträge
    729
    Danke Danke gesagt 
    52
    Danke Danke erhalten 
    0
    Das ist ein waschechter Skandal. Punkt. Aus. Ende

Seite 1 von 7 12345 ... LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •