Archiv verlassen und diese Seite im Standarddesign anzeigen : Immer noch: Intel Compiler benachteiligt AMD CPUs
Hallo,
sowas gabs ja schon mal vor Jahren:
http://www.swallowtail.org/naughty-intel.html
http://www.swallowtail.org/naughty-intel.shtml
Die alten intel Compiler fragten dort nicht nach den feature Set ab, das die CPU kann ( also MMX, SSE, SSE2, SSE3 ...) sondern er fragt erstmal, ob ne "Genuine Intel" CPU im PC steckt.
Das hatte AMD auch mit in die Klage gegen Intel mitaufgenommen:
http://www.amd.com/us-en/assets/content_type/DownloadableAssets/AMD-Intel_Full_Complaint.pdf
Seite 40
und schwupps, gabs im ICC 10.x eine neues Compiler Flag /QxO. Funktion laut Intel help file: Can generate SSE3, SSE2, and SSE instructions. Generated code might operate on processors not made by Intel that support SSE3, SSE2 and SSE instruction sets.
Can optimize for Intel processors based on Intel® Core™ microarchitecture or Intel NetBurst® microarchitecture.
This value does not enable some optimizations enabled when using the S, T, or P processor values.
Soweit so schön ... allerdings gibts immer noch das alte Intel Flag /QxP, laut Intel hat das die folgende Aufgabe:
Can generate SSE3, SSE2, and SSE instructions and can optimize for Intel processors, like the following:
Intel® Core™ Duo processors
Intel® Core™ Solo processors
Pentium® D processors
Intel Pentium® 4 processors with SSE3
Intel Celeron® M processors
Intel Celeron® D processors
Intel® Xeon® processors with SSE3
Other Intel processors based on Intel® Core™ microarchitecture or Intel NetBurst® microarchitecture
Mac OS X: Supported on IA-32 and Intel® 64 architectures.
Quelle: http://cache-www.intel.com/cd/00/00/34/76/347618_347618.zip
So alles in Butter könnte man meinen ... nein leider nicht. Das für Intel compilierte binary läuft auf AMD CPUs immer noch 50-100% schneller, als die Alibi /QxO Version, aber natürlich erst, nachdem man die Intel Abfrage entfernt hat. Selbige fragt jetzt nichtmehr nach Genuine Intel, sondern die erweiterte Familie ab ... Supi. Um das Ganze jetzt zu umgehen, hat der nette Wissenschaftler von der Universität Kopenhagen, der den Sachverhalt herausgefunden hat, eine sehr gute Anleitung bereitgestellt:
http://www.agner.org/optimize/optimizing_cpp.pdf
Der betreffende Abschnitt ist um S.118
Dabei wird die Intel eigene "suboptimale" Abfragefunktion durch eine neutrale ersetzt, die schlicht und einfach nur die feature flags abfragt und die CPU Familie ignoriert.
Aufgabe für alle interessierten Crunsher:
Fragt mal bei Euren Favoritenprojekten nach, ob Sie Intel Compiler verwenden. Falls ja gebt Ihnen mal den Tipp über obiges Optimierungs PDF, vielleicht gibts dann demnächst mit einer neuen Programmversion bessre AMD Ergebnisse & mehr Credits.
Viele Projekte nützen meines Wissens nach GCC, aber nachdem ich nicht ausschließen kann, dass es auch das ein oder andre ICC Projekte gibt, wollte ich das hier mal melden.
Fortlaufende Diskussion bei aceshardware:
http://aceshardware.freeforums.org/cpuid-family-bits-added-because-of-flaw-in-intel-compiler-t428.html
ciao
Alex
Tja, ein zweischneidiges Schwert würde ich sagen *noahnung* Es ist Intels eigener Compiler, der mit eigenen R&D-Geldern entwickelt wurde. Man könnte die Meinung vertreten, dass Intel alles Recht der Welt hat sicherzustellen, dass nur die hauseigenen Prozessoren von den Optimierungen profitieren. Andererseits ist es natürlich ärgerlich für AMD. Wenn AMD einen eigenen Compiler anbieten würde oder die anderen Compiler besser wären, gäbe es diese Diskussion gar nicht, denn dann könnte man für AMD-Prozessoren einfach zu GCC, PGI, etc. greifen. Aber meistens ist der ICC ja selbst inklusive der künstlichen Bremsen noch besser, als die anderen Compiler in der höchsten Optimierungsstufe.
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1097500346
Tja, ein zweischneidiges Schwert würde ich sagen *noahnung* Es ist Intels eigener Compiler, der mit eigenen R&D-Geldern entwickelt wurde. Man könnte die Meinung vertreten, dass Intel alles Recht der Welt hat sicherzustellen, dass nur die hauseigenen Prozessoren von den Optimierungen profitieren. Andererseits ist es natürlich ärgerlich für AMD. Wenn AMD einen eigenen Compiler anbieten würde oder die anderen Compiler besser wären, gäbe es diese Diskussion gar nicht, denn dann könnte man für AMD-Prozessoren einfach zu GCC, PGI, etc. greifen. Aber meistens ist der ICC ja selbst inklusive der künstlichen Bremsen noch besser, als die anderen Compiler in der höchsten Optimierungsstufe.
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1097500346
Jupp Zweischneidig.
Man muss aber unterscheiden zwischen:
a) Befehlssatzoptimierung (wozu gibts sonst die feature flags ...)
b) CPU Optimierung (nach der CPU Family)
Intel vermischt jetzt beides und optimiert über die CPU family Abfrage gleichzeitig die Befehlssätze. Böse Zungen mögen da von "Mißbrauch" sprechen ...
Ich halts auf alle Fälle kindisch, ja sogar gefährlich für Intel, nachdem zuvor schon die GenuineIntel Abfrage von AMD angeprangert wurde. Das kann ganz schnell als Mißbrauch von Marktmacht interpretiert werden, jetzt sogar im Wiederholungsfall, wenn das die EU Kommission mitbekommt .. die fackelt da nicht lange. Könnte noch sehr teuer für Intel werden...
ciao
Alex
mocad_tom
25.03.2008, 10:30
Ich hätte echt gedacht, das Thema wäre allmählich "entschärfter".
Andreas Stiller hat das in der c't ja früher schonmal angemahnt.
Eine Frage würde mich aber brennend interessieren - sind SpecInt/SpecFP/usw.-Eintragungen mit hand-gepatchtem Code rechtens oder nicht?
Viele Optimierungen sind oft nur dazu da eben diesen Code zu verbessern.
Grüße,
Tom
Das ist eindeutig wettbewerbswidriges Verhalten, CPUs auszuschließen, die mit offiziell lizenzierten Befehlssätzen arbeiten. Dabei spielt es überhaupt keine Rolle, ob man selber den Compiler entwickelt. Das wird sicherlich eine der EU Auflagen werden, diese Abfrage aus dem Compiler zu nehmen.
Das ist eindeutig wettbewerbswidriges Verhalten, CPUs auszuschließen, die mit offiziell lizenzierten Befehlssätzen arbeiten. Dabei spielt es überhaupt keine Rolle, ob man selber den Compiler entwickelt. Das wird sicherlich eine der EU Auflagen werden, diese Abfrage aus dem Compiler zu nehmen.
nun es zwingt dich niemand diesen compiler zu verwenden oder?
warum muss/soll Intel für AMD die Entwicklungsarbeit abnehmen? Wenn das AMD wirklich so wichtig wäre, dann hätten sie schon längst einen EIGENEN kommerziellen Compiler.
nun es zwingt dich niemand diesen compiler zu verwenden oder?
warum muss/soll Intel für AMD die Entwicklungsarbeit abnehmen?So könnte man argumentieren wenn der für Intel-CPUs generierte Code von Haus aus auf AMD-CPUs langsam wäre. Aber es ist ja so, dass der für Intel-CPUs generierte Code zufällig auch auf AMD-CPUs sehr gut läuft. Intel schmeckt das nicht, also bauen sie die Abfrage ein, ob es eine Intel-CPU ist und bremsen AMD-CPUs künstlich aus.
Ein Polemiker würde jetzt behaupten, dass durch die Abfrage Intel sogar mehr Aufwand betreiben muss als wenn sie AMD-CPUs gleichwertig behandeln würden.;)
So könnte man argumentieren wenn der für Intel-CPUs generierte Code von Haus aus auf AMD-CPUs langsam wäre. Aber es ist ja so, dass der für Intel-CPUs generierte Code zufällig auch auf AMD-CPUs sehr gut läuft. Intel schmeckt das nicht, also bauen sie die Abfrage ein, ob es eine Intel-CPU ist und bremsen AMD-CPUs künstlich aus.
Ein Polemiker würde jetzt behaupten, dass durch die Abfrage Intel sogar mehr Aufwand betreiben muss als wenn sie AMD-CPUs gleichwertig behandeln würden.;)
das mag ja alles richtig sein, aber wo ist da das Problem für Intel? ;)
Versteht mich nicht falsch, mir schmeckt das genauso wenig, aber Intel bewegt sich da in einem legitimen Raum. Es ist ihr Produkt, sie haben es entwickelt, sie verkaufen es, sie entscheiden wie es funktioniert, niemand MUSS es verwenden.
Wenn AMD etwas ähnliches im Angebot hätte, würde sie es ja bestimmt auch so machen :]
Versteht mich nicht falsch, mir schmeckt das genauso wenig, aber Intel bewegt sich da in einem legitimen Raum. Es ist ihr Produkt, sie haben es entwickelt, sie verkaufen es, sie entscheiden wie es funktioniert, niemand MUSS es verwenden.Gleiches gilt für Microsoft Windows und trotzdem gibts für Microsoft regelmäßig auf den Deckel.;) Das Problem ist die marktbeherrschende Stellung. Die ist zugegeben bei Intel weniger stark ausgeprägt als bei Microsoft.
Gleiches gilt für Microsoft Windows und trotzdem gibts für Microsoft regelmäßig auf den Deckel.;) Das Problem ist die marktbeherrschende Stellung. Die ist zugegeben bei Intel weniger stark ausgeprägt als bei Microsoft.
das ist richtig. der markt würde auch ganz gut ohne intel compiler funktionieren (klar nicht für alle, der MS compiler tut es auch, auch wenn er zum kotzen ist), bei MS Windows ist das natürlich aufgrund der Markmacht kritischer zu betrachten, das muss von außen reguliert werden.
Intel hat ja wegen der Sache schon einmal eine auf den Deckel bekommen. Gerade wo jetzt die EU und einige andere Kartellbehörden genauer hinschauen, ist so etwas einfach nur dumm.
AMD hatte schon mal in der Richtung Anlauf genommen - nur wird das bei AMD einfach ein Ressourcen-Problem sein. Alles was sich nicht in relativ kurzer Zeit in Euro und Cent auszahlt, ist bei deren Lage im Moment leider nur rausgeschmissen.
Intel hat ja wegen der Sache schon einmal eine auf den Deckel bekommen. Gerade wo jetzt die EU und einige andere Kartellbehörden genauer hinschauen, ist so etwas einfach nur dumm.
AMD hatte schon mal in der Richtung Anlauf genommen - nur wird das bei AMD einfach ein Ressourcen-Problem sein. Alles was sich nicht in relativ kurzer Zeit in Euro und Cent auszahlt, ist bei deren Lage im Moment leider nur rausgeschmissen.
... und seswegen dürfen sie "kostenlos" auf das konkurrenzprodukt verweisen bzw. sich beschweren wenn sie künstlich ausgebremst werden?
... und seswegen dürfen sie "kostenlos" auf das konkurrenzprodukt verweisen bzw. sich beschweren wenn sie künstlich ausgebremst werden?
Ich sag ja nicht, das es richtig ist ;) Intel sollte in dieser Richtung nur einfach mal die Füße stillhalten, sonst fällt was drauf. Wer die Steuerfahnder im Hause hat, wird doch auch nicht nebenbei anfangen auf seinen luxemburger Konten zu traden ;D
Ich sag ja nicht, das es richtig ist ;) Intel sollte in dieser Richtung nur einfach mal die Füße stillhalten, sonst fällt was drauf. Wer die Steuerfahnder im Hause hat, wird doch auch nicht nebenbei anfangen auf seinen luxemburger Konten zu traden ;D
Warum sollten sie, sie machen ja nichts illegales.
Warum sollten sie, sie machen ja nichts illegales.Als ganz astrein würde ich es aber auch nicht bezeichnen.
Als ganz astrein würde ich es aber auch nicht bezeichnen.
Als was würdest du es denn dann bezeichnen?`
Ich würde sagen "fieß" aber "legal" :(
Als was würdest du es denn dann bezeichnen?`
Ich würde sagen "fieß" aber "legal" :(
Bei kleineren Firmen würde kein Hahn nach krähen - da wäre es wohl "clever". Bei eindeutig marktbeherrschenden Firmen gelten nach dem Kartellrecht andere Maßstäbe. Und da nun mal bekannt ist, das der blaue Riese nicht immer nur kartellrechtlich sauber vorgegangen ist, wäre so eine Sache nur eine Provokation an die Kartellbehörden*noahnung* muß man nicht unbedingt haben...
Bei kleineren Firmen würde kein Hahn nach krähen - da wäre es wohl "clever". Bei eindeutig marktbeherrschenden Firmen gelten nach dem Kartellrecht andere Maßstäbe. Und da nun mal bekannt ist, das der blaue Riese nicht immer nur kartellrechtlich sauber vorgegangen ist, wäre so eine Sache nur eine Provokation an die Kartellbehörden*noahnung* muß man nicht unbedingt haben...
Warum soll Intel die Firma AMD kostenlos unterstützen? Ich sehe da kein Kartellrecht, da die Welt auch ohne Intelcompiler funktionieren würde, es gibt ja noch zig andere Compiler.
Das Kartellrecht spielt deshalb da mit rein, weil Intel künstlich dafür sorgt, dass 2 Intel-Produkte besser zusammenspielen als eines der beiden Intel-Produkte mit einem Fremdhersteller-Produkt und Intel bei einem der beiden Produkte eine marktbeherrschende Stellung hat.
Das Kartellrecht spielt deshalb da mit rein, weil Intel künstlich dafür sorgt, dass 2 Intel-Produkte besser zusammenspielen als eines der beiden Intel-Produkte mit einem Fremdhersteller-Produkt und Intel bei einem der beiden Produkte eine marktbeherrschende Stellung hat.
was wäre wenn der code, der vom intelcompiler erzeugt wird, überhaupt nicht mehr auf nicht-intel cpus laufen würde?
warum darf nvidia per treiber unterbinden das sli nur auf teueren nvidia boards funktioniert (abgesheen vom skulldings)? ist doch fast das gleiche oder?
naja sogesehen ist das mit sli bei nvidia ja das gleiche wie wenn microsoft seine schnittstelle nicht offenlegt oder etwa nicht?
Warum soll Intel die Firma AMD kostenlos unterstützen? Ich sehe da kein Kartellrecht, da die Welt auch ohne Intelcompiler funktionieren würde, es gibt ja noch zig andere Compiler.
Es geht nicht um "nicht unterstützen" sondern um explizites Ausschließen von vorhandenen Optimierungsmöglichkeiten. Und das ist schon was anderes als Unterstützung.
Es geht nicht um "nicht unterstützen" sondern um explizites Ausschließen von vorhandenen Optimierungsmöglichkeiten. Und das ist schon was anderes als Unterstützung.
wo ist da jetzt der unterschied aus Intels Sicht?
Sie sagen (lügen :]) einfach, dass deren SSE2/3 etc. optimiert code nicht zu 100% korrekt auf nicht Intel-cpus läuft, somit wird er deaktiviert :] - legal?
Aus Intels sich ist wohl jeglicher Wettbewerb Ursache für eine Minimierung des Gewinnes und deshalb äußerst unerwünscht ....ohne WB könnte sehr viel Geld gespart werden. Vermutlich hätten wir dann alle gaaaanz tolle P4 für genausoviel Kohle wie MHz...
Aus diesem Grunde habe ich stark eingeschränkte Sympathien für Monopolisten aller Art - da macht sich so eine unsympatische Arroganz der Macht breit:[
Aus Intels sich ist wohl jeglicher Wettbewerb Ursache für eine Minimierung des Gewinnes und deshalb äußerst unerwünscht ....ohne WB könnte sehr viel Geld gespart werden. Vermutlich hätten wir dann alle gaaaanz tolle P4 für genausoviel Kohle wie MHz...
Aus diesem Grunde habe ich stark eingeschränkte Sympathien für Monopolisten aller Art - da macht sich so eine unsympatische Arroganz der Macht breit:[
dem stimem ich ja auch zu, nur geht es hier um das "darf Intel es oder darf Intel das nicht" und ich bin der Meinung, das Intel es darf (damit meine ich die Compilersache).
ich denke auch das intel das darf, denn schliesslich haben sie ihren compiler für ihre cpu´s erstellt, das damit auch amd cpu´s funktionieren spielt eine untergeordnete rolle.
vielleicht müsste das problem anders angegangen werden.
software hersteller die den intel compiler nutzen sollten ihre produkte kennzeichnen, um auf die minderleistung bei amd systemen hinzuweisen.
somit wäre amd vielleicht motiviert einen eigenen compiler zu entwickeln oder zumindest neutrale compiler besser zu unterstützen, der eine oder andere software hersteller wäre dann vielleicht auch nicht mehr so intel freundlich.
amd optimierter code könnte auch die absätze ihrer cpu´s auf dauer steigern, denn intel macht das ja nicht ohne grund.
dem stimem ich ja auch zu, nur geht es hier um das "darf Intel es oder darf Intel das nicht" und ich bin der Meinung, das Intel es darf (damit meine ich die Compilersache).
Prinzipiell Deiner Meinung - meinte nur das es nicht besonders clever ist, wenn man schon genau deswegen verwarnt wurde und anderweitige kartellrechtliche Untersuchungen laufen, auch noch mit so was Öl in´s Feuer zu gießen. Die EU-Kommision scheint es ja offenbar etwas anders zu sehen *noahnung*
Prinzipiell Deiner Meinung - meinte nur das es nicht besonders clever ist, wenn man schon genau deswegen verwarnt wurde und anderweitige kartellrechtliche Untersuchungen laufen, auch noch mit so was Öl in´s Feuer zu gießen. Die EU-Kommision scheint es ja offenbar etwas anders zu sehen *noahnung*
ich finde nicht das sie da wirklich öl ins feuer gießen. das kartellamt kann da auch nichts dagegen tun, außer dumm guggn ;D
ich finde nicht das sie da wirklich öl ins feuer gießen. das kartellamt kann da auch nichts dagegen tun, außer dumm guggn ;D
Uhhhh ... sag das mal MS in Sachen EU Kommision (das is ja ne Art EU Kartellamt ^^).
Sobald die feststellen bzw. der Meinung sind, dass jemand ein Monopol hat, bzw. seine Marktmacht mißbraucht, dann gehts los ... dauert zwar lange, aber wie MS zeigt, funktioniert es.
AMD klagt jetzt gegen Intel, u.a. mit der alten genuine intel Abfrage, da kommt das aktuelle Problem jetzt nicht toll rüber.
ciao
Alex
Uhhhh ... sag das mal MS in Sachen EU Kommision (das is ja ne Art EU Kartellamt ^^).
Sobald die feststellen bzw. der Meinung sind, dass jemand ein Monopol hat, bzw. seine Marktmacht mißbraucht, dann gehts los ... dauert zwar lange, aber wie MS zeigt, funktioniert es.
AMD klagt jetzt gegen Intel, u.a. mit der alten genuine intel Abfrage, da kommt das aktuelle Problem jetzt nicht toll rüber.
ciao
Alex
Ähm MSWindows != Intel Compiler, das eine ist ein Monopol, das andere nicht, so what?
Ähm MSWindows != Intel Compiler, das eine ist ein Monopol, das andere nicht, so what?
Das ist Interpretations/Auslegungssache, im x86 / Windows Bereich gibts sonst nur noch PGI und halt den MS Compiler, beide liefern schlechteren Code. V.a. die Auswirkung auf diverse Benchmarks sind da nicht gerade klein.
Die Frage ist jetzt, ob der geschilderte Sachverhalt mit der CPU family Abfrage ein Mißbrauch einer marktbeherrschenden Situation ist, oder nicht.
Um es an Dein Beispiel anzupassen:
Es gibt auch Linux, Solaris etc. pp. MS Windows is doch kein Monopol ... ;D
ciao
Alex
Das ist Interpretations/Auslegungssache, im x86 / Windows Bereich gibts sonst nur noch PGI und halt den MS Compiler, beide liefern schlechteren Code. V.a. die Auswirkung auf diverse Benchmarks sind da nicht gerade klein.
Die Frage ist jetzt, ob der geschilderte Sachverhalt mit der CPU family Abfrage ein Mißbrauch einer marktbeherrschenden Situation ist, oder nicht.
Um es an Dein Beispiel anzupassen:
Es gibt auch Linux, Solaris etc. pp. MS Windows is doch kein Monopol ... ;D
ciao
Alex
*lach* ;D
Lese ich da Ironie? :P
Es ist ja nicht so das der Anwender keine Wahl hätte, er entscheidet welcher Compiler es sein soll. Man kann mit allen gängigen Compilern sein Programm übersetzen und an den Mann bringen. Ich sehe da nicht das man da an Intel gebunden ist, außer man möchte alles aus seinen "Intel" Prozessor rausholen.
Das Beispiel kannst du auf MS-Windows nicht anwenden.
Kater Sylvester
27.03.2008, 13:30
Ich möchte die Sache mal von der anderen Seite angehen.
Was soll Kartellrecht eigentlich bewirken? Meine Interpretation:
Das der Endverbraucher die uneingeschränkte Wahl zwischen verschiedenen Anbietern hat und durch den entstehenden Wettbewerb die Preise durch den Markt reguliert werden (können).
Wie man an diversen Beispielen sehen kann, schränken Monopole den Wettbewerb ein ( wir würden heute noch für 100 EUR im Monat im Internet surfen wenn...).
Warum hätte sonst eigentlich die EU Komission etwas dagegen, wenn MS einen WEB Browser im Betriebssystem integriert, kostenlos wohlgemerkt? Weil ein Mitbewerber, der ein solches Produkt verkauft, dabei zwangsläufig pleite gehen muss.
Damit wird also die marktbeherrschende Position ausgenutzt, um einen Mitbewerber loszuwerden.
AMD hat sicherlich Geld für die Nutzung der Technologien SSE, SSE"... bezahlen müssen oder die Nutzung eigener Patente im Austausch freigegeben. Wieso verhindert dann Intel die Nutzung von Programmen durch AMD CPUs?
Mal ein Beispiel:
Wenn Intel den Compiler verschenken würde, gäbe es über kurz oder lang nur noch dieses Produkt. Genau damit würde aber ein Kunde eine AMD CPU als langsam und damit nicht konkurrenzfähig ansehen.
Genau das ist aber mit der Ausnutzung einer marktbeherschenden Position gemeint und muss verhindert werden.
Ich möchte das Beispiel mal umdrehen:
Was wäre eigentlich, wenn AMD einen Compiler entwickeln würde, der nur auf AMD CPUs schnellen Programmcode generiert und diesen Compiler verschenkt? Firmen, die Software entwickeln, würden diesen Compiler doch gar nicht erst verwenden, weil die Mehrheit ihrer Kunden die damit entwickelten Programme nicht einsetzt würden.
Das ist genau der Unterschied zu marktbeherrschend.
Nun ja, wenn..... Intel verkauft ihn aber teuer (naja teuer ist er ja nicht wirklich, die Compiler für den Embedded Bereich sind deutlich teurer *buck*), wodurch ihn nicht jeder einsetzt, und von einer marktbeherschenden Stellung kann man da auch nicht sprechen.
Amd hat kein Geld zahlen müssen, sie haben ein Lizenztauschabkommen mit Intel (SSE(x) gegen AMD64/NX-Bit).
Es ist ja nicht so das der Anwender keine Wahl hätte, er entscheidet welcher Compiler es sein soll. Man kann mit allen gängigen Compilern sein Programm übersetzen und an den Mann bringen. Ich sehe da nicht das man da an Intel gebunden ist, außer man möchte alles aus seinen "Intel" Prozessor rausholen.
Das Beispiel kannst du auf MS-Windows nicht anwenden. Doch das geht, oder reden wir jetzt aneinander vorbei ?
Mein Punkt ist ja, dass Du sowohl bei den Compilern wie auch bei den Betriebssystemen wählen kannst: Windows , Linux .... oder eben ICC, PGI, ...
Trotzdem hat die EU Kommission M$ ne saftige Strafe aufgebrummt. Also ich sehe da durchaus Parallelen.
ciao
Alex
Doch das geht, oder reden wir jetzt aneinander vorbei ?
Mein Punkt ist ja, dass Du sowohl bei den Compilern wie auch bei den Betriebssystemen wählen kannst: Windows , Linux .... oder eben ICC, PGI, ...
Trotzdem hat die EU Kommission M$ ne saftige Strafe aufgebrummt. Also ich sehe da durchaus Parallelen.
ciao
Alex
Wie groß ist der MS-Betriebsystemanteil Weltweit? Gleiche Frage zum Intelcompiler? ;)
Es ist ja nicht so das der Anwender keine Wahl hätte, er entscheidet welcher Compiler es sein soll.
Mein Punkt ist ja, dass Du sowohl bei den Compilern wie auch bei den Betriebssystemen wählen kannst: Hm, also da möchte ich doch mal gegenhalten. Hat der Windows-User wirklich die Wahl mit welchem Compiler seine Anwendung übersetzt wird? Bis auf ein paar wenige Ausnahmen aus dem OpenSource-Bereich, wo der Quellcode bereit liegt, hat der Windows-User doch das zu nehmen, was einem der Hersteller vorsetzt, oder nicht? Meistens ist das wohl der MS-Compiler, was für AMD nicht schlecht ist. Aber die Wahl hat man doch als Windows-User eher nicht, oder etwa doch? *noahnung*
Hm, also da möchte ich doch mal gegenhalten. Hat der Windows-User wirklich die Wahl mit welchem Compiler seine Anwendung übersetzt wird? Bis auf ein paar wenige Ausnahmen aus dem OpenSource-Bereich, wo der Quellcode bereit liegt, hat der Windows-User doch das zu nehmen, was einem der Hersteller vorsetzt, oder nicht? Meistens ist das wohl der MS-Compiler, was für AMD nicht schlecht ist. Aber die Wahl hat man doch als Windows-User eher nicht, oder etwa doch? *noahnung*
Wie meinst du das?
Ich compiliere überwiegend auf Arbeit nur mit dem MS-Compiler (der mittlerweile auch SSE2 unterstützt). Möchte ich mehr so kaufe ich mir um 1000€ (?) den Intelcompiler und verwende diesen, es gibt ja auch noch andere z.b. den von Borland im (C-Builder), k.a. wie der abgeht, aber die Wahl hat man da schon.
Wie meinst du das? Nun, der typische Windows-User kompiliert doch erst mal gar nichts. Das ist doch seit ich zurückdenken kann (und das ist leider mittlerweile ziemlich lange *suspect*) ein Privileg der Unix- und Linux-User. "Der" Windows-Anwender muss sich doch in der Regel damit zufrieden geben, was der Hersteller an Binaries liefert. Ich kann weder bei MS-Office, noch bei Hauppauge WinTV, noch bei Lexware Buchhaltung, noch bei Mozilla Firefox, noch bei VideoLAN bestimmen, mit welchem Compiler die Anwendung übersetzt wurde. Das definiert aber bereits 95% meines täglichen PC-Einsatzes :o Das meine ich damit.
Nun, der typische Windows-User kompiliert doch erst mal gar nichts. Das ist doch seit ich zurückdenken kann (und das ist leider mittlerweile ziemlich lange *suspect*) ein Privileg der Unix- und Linux-User. "Der" Windows-Anwender muss sich doch in der Regel damit zufrieden geben, was der Hersteller an Binaries liefert. Ich kann weder bei MS-Office, noch bei Hauppauge WinTV, noch bei Lexware Buchhaltung, noch bei Mozilla Firefox, noch bei VideoLAN bestimmen, mit welchem Compiler die Anwendung übersetzt wurde. Das definiert aber bereits 95% meines täglichen PC-Einsatzes :o Das meine ich damit.
ähm. irgendwie hast du das jetzt missverstanden.
es geht hier um compiler für softwareentwickler, nicht um anwender die fertige apps benutzen.
es geht hier um compiler für softwareentwickler, nicht um anwender die fertige apps benutzen. Tut's das wirklich? :)
Tut's das wirklich? :)
ja tut es ;)
der anwender weiß doch gar nicht mit welchem compiler die app compiliert wurde. und falls doch was soll er dagegen tun? wenn sie mit MS compiliert wurde nörgelt er den softwareentwickler an, weil er zu geizig war einen "besseren" compiler einzusetzen, wenn es der intel-compiler war nörgelt er weil intel amd schwächer dastehen läßt, oder er nörgelt amd an, weil es keinen von amd entwickelten compiler gibt? warum soll ausgerehcnet intel den besten compiler für alle bereitstellen, aber dabei selber die entwicklungskosten tragen?
und warum regt sich niemand über MS und deren mitgelieferten compiler in VSS auf? Immerhin produziert er ja auch nicht optimalen code für xyz cpus :]
und warum regt sich niemand über MS und deren mitgelieferten compiler in VSS auf? Immerhin produziert er ja auch nicht optimalen code für xyz cpus :]Weil Microsoft keine Prozessoren herstellt und somit keinen direkten Nutzen aus der Bevorzugung einer bestimmten CPU zieht. Weil der Microsoft-Compiler AFAIK auf allen CPUs ungefähr gleich schlecht ist. Und vor allem weil Microsoft keine künstliche Bremse drin hat.
Weil Microsoft keine Prozessoren herstellt und somit keinen direkten Nutzen aus der Bevorzugung einer bestimmten CPU zieht. Weil der Microsoft-Compiler AFAIK auf allen CPUs ungefähr gleich schlecht ist. Und vor allem weil Microsoft keine künstliche Bremse drin hat.
bist du dir da sicher? :P
Na zumindest keine, die nur für CPUs eines bestimmten Herstellers gilt. ;D
Na zumindest keine, die nur für CPUs eines bestimmten Herstellers gilt. ;D
;) Stimmt aber das ist ja auch nicht das Thema.
Schluss endlich ist es ne unangenehme Sache, aber meiner Meinung nach ist Intel da auf der sicheren Seite. :]
Wie groß ist der MS-Betriebsystemanteil Weltweit? Gleiche Frage zum Intelcompiler? ;)
Jupp das ist nun die Monopolfrage.
Ich seh da nicht den aktuellen Marktanteil, sondern die Tatsache, dass es keine Alternative für Intel gibt, *wenn* man unter Windows ein performantens Binary haben will, *und* der Sourcecode von mathematischen Formeln nur so strotzt.
Wenn man über irgendein GUI Programm redet, das hauptsächlich auf Benutzereingaben wartet, dann kannst Du auch den Watcom Compiler von anno dazumal zum Compilieren nehmen, da merkst Du keinen Unterschied. Z.B. hatte ich mal nen "optimierten" FireFox, angeblich mit allen Finessen compiliert ... naja Unterschied ... öööhhhmmm ... *kopfkratz
Wenn Du aber ein HPC Programm mit Berechnungen ohne Ende hast, die sich auch noch vektorisieren lassen, hast Du keine Wahl, da ist Intel ein Muss, d.h. der Intel Compiler hat meiner Meinung nach ein Windows-Performance Monopol.
Windows ist bekanntermaßen weit verbreitet, Berechnungen unter Windows gibts v.a. bei DC, deswegen hab ichs den thread auch hier auch gepostet (ausserdem machen sich hier die Fanboys rar @TAL9000 ^^) .
Inzwischen hab ich mich auf einigen Projektseiten umgeschaut, so wies ausschaut wird der ICC da aber eh schon wenig eingesetzt. Die einen haben gcc, wegen der OS Portabilität, die andren gehen schon einen Schritt weiter und setzen schon die allerbeste Optimierung überhaupt ein: Handoptimierten SSE Assemblercode.
Also der Einfluß von ICC scheint trotz des hohen Windows Anteils bei DC gering zu sein.
Was übrig bleibt sind die ganzen Windows Benches: 4EMark 2010, xinebench und was weiß ich noch alles ...
Interessant wären auch die Codes der vielen Games, bei denen Intel "gesponsort" hat, wobei das a) wieder ein andres Thema ist, und b) sie das meist machen, indem sie einen Assemblerprogrammierer abstellen. Also da wäre Codeabfrage eigentlich fast ok, wenn sie schon den Coder zahlen ... :)
ciao
Alex
Jupp das ist nun die Monopolfrage.
Ich seh da nicht den aktuellen Marktanteil, sondern die Tatsache, dass es keine Alternative für Intel gibt, *wenn* man unter Windows ein performantens Binary haben will, *und* der Sourcecode von mathematischen Formeln nur so strotzt.
Wenn man über irgendein GUI Programm redet, das hauptsächlich auf Benutzereingaben wartet, dann kannst Du auch den Watcom Compiler von anno dazumal zum Compilieren nehmen, da merkst Du keinen Unterschied. Z.B. hatte ich mal nen "optimierten" FireFox, angeblich mit allen Finessen compiliert ... naja Unterschied ... öööhhhmmm ... *kopfkratz
Wenn Du aber ein HPC Programm mit Berechnungen ohne Ende hast, die sich auch noch vektorisieren lassen, hast Du keine Wahl, da ist Intel ein Muss, d.h. der Intel Compiler hat meiner Meinung nach ein Windows-Performance Monopol.
Windows ist bekanntermaßen weit verbreitet, Berechnungen unter Windows gibts v.a. bei DC, deswegen hab ichs den thread auch hier auch gepostet (ausserdem machen sich hier die Fanboys rar @TAL9000 ^^) .
Inzwischen hab ich mich auf einigen Projektseiten umgeschaut, so wies ausschaut wird der ICC da aber eh schon wenig eingesetzt. Die einen haben gcc, wegen der OS Portabilität, die andren gehen schon einen Schritt weiter und setzen schon die allerbeste Optimierung überhaupt ein: Handoptimierten SSE Assemblercode.
Also der Einfluß von ICC scheint trotz des hohen Windows Anteils bei DC gering zu sein.
Was übrig bleibt sind die ganzen Windows Benches: 4EMark 2010, xinebench und was weiß ich noch alles ...
Interessant wären auch die Codes der vielen Games, bei denen Intel "gesponsort" hat, wobei das a) wieder ein andres Thema ist, und b) sie das meist machen, indem sie einen Assemblerprogrammierer abstellen. Also da wäre Codeabfrage eigentlich fast ok, wenn sie schon den Coder zahlen ... :)
ciao
Alex
Das findest du ok? Coder zahlen oder Compiler zahlen, wo ist da jetzt der Unterschied, der es einem erlaubt die Abfrage zum Aussperren einzubauen *kopfkratz*
Das findest du ok? Coder zahlen oder Compiler zahlen, wo ist da jetzt der Unterschied, der es einem erlaubt die Abfrage zum Aussperren einzubauen *kopfkratz*
Der Coder optimiert nur für speziell genau *ein* Programm, während der Compiler *jedes* Compilat verpfuscht ...
Soll heißen, wenn sich die Gamehersteller den Umsonstcoder von Intel ins Haus holen, dann kann sich der Endkunde maximal beim Spielehersteller beschweren .. Intel "hilft" ja nur.
Aber wie besagt, das ist ein andres Thema.
ciao
Alex
Der Coder optimiert nur für speziell genau *ein* Programm, während der Compiler *jedes* Compilat verpfuscht ...
Soll heißen, wenn sich die Gamehersteller den Umsonstcoder von Intel ins Haus holen, dann kann sich der Endkunde maximal beim Spielehersteller beschweren .. Intel "hilft" ja nur.
Aber wie besagt, das ist ein andres Thema.
ciao
Alex
Aber dieser böse Coder "könnte" auf Wunsch ja überall sein Unwesen treiben ;D
Denken wir mal weiter (weil grad so schön Spaß macht) ;)
Wo ist der Unterschied zwischen: "Ich hole mir einen Coder der optimiert" und "Ich hole mir einen Compiler, der für mich optimiert"
Beides ist kostenpflichtig, beides ist selbst gewählt, und beide Methoden sind durch Alternativen zu ersetzen.
"Der Coder optimiert nur für speziell genau *ein* Programm, während der Compiler *jedes* Compilat verpfuscht ..."
du tust ja gerade so, als hätte jeder Entwickler diesen Intelcompiler auf seinem PC, bzw er MÜSSE ihn verwenden. Doch das ist nicht der Fall.
.
EDIT :
.
Jupp das ist nun die Monopolfrage....
...
Wenn Du aber ein HPC Programm mit Berechnungen ohne Ende hast, die sich auch noch vektorisieren lassen, hast Du keine Wahl, da ist Intel ein Muss, d.h. der Intel Compiler hat meiner Meinung nach ein Windows-Performance Monopol.
Seit Wann ist ein Produkt, nur weil es das beste ist, ein Monopol, obwohl es zig Alternativen gibt und die tatsächliche Verbreitung des "besten" Produkts (wie du selber festgestellt hast) nicht so besonders ist :]
Ich glaube das ist nur Wunschdenken deinerseits :P
@Twodee
Eins muß man Dir absolut lassen - Du bist unheimlich zäh, wenn Du eine Meinung hast *lol* :P
@Twodee
Eins muß man Dir absolut lassen - Du bist unheimlich zäh, wenn Du eine Meinung hast *lol* :P
Ist ja auch in Ordnung so, solange ich sie niemanden aufzwinge ;) falls doch, erinnert mich daran :)
Aber dieser böse Coder "könnte" auf Wunsch ja überall sein Unwesen treiben ;D
Denken wir mal weiter (weil grad so schön Spaß macht) ;)
Wo ist der Unterschied zwischen: "Ich hole mir einen Coder der optimiert" und "Ich hole mir einen Compiler, der für mich optimiert"
Beides ist kostenpflichtig, beides ist selbst gewählt, und beide Methoden sind durch Alternativen zu ersetzen.
Dem Assembler Programmierer traue ich zu schlauer zu sein, der kapiert was der Code machen soll, und kann dann die Befehlsabfolge so optimieren, dass die spezielle xy CPU am wenigstens Takte damit vertrödelt. Dem Compiler gestehe ich zu, hauptsächlich auf Befehlssätze optimieren zu können, Optimierungen der Gesamtlaufzeit sind wohl in Maßen auch möglich, aber nachdem der Opteron so gut mit dem, offiziell für Prescott optimierten, Code läuft [-QxP] kanns da nicht weit mit einer speziellen Prescott Optimierung her sein.
In jedem Fall: Wozu braucht man den Programmierer ? Sicherlich nicht, um die gleiche Arbeit zu machen, die der ICC schon könnte ...
Weiteres Beispiel für nen ähnlichen Fall wären die Performance Libraries, da werden dem Compiler händisch optimierter Code für häufig genützt Funktionen untergejubelt. Da seh ich ne CPU Abfrage auch ein, auch wenn es für den Endkunden natürlich am wünscheswertesten wäre, wenn man die Abfrage wählen könnte.
du tust ja gerade so, als hätte jeder Entwickler diesen Intelcompiler auf seinem PC, bzw er MÜSSE ihn verwenden. Doch das ist nicht der Fall. Lol, ich schreib den Satz mal um, dann sieht man dass er Käse ist "du tust ja gerade so, als hätte jeder PC Nutzer Windows auf seinem PC, bzw er MÜSSE es verwenden. Doch das ist nicht der Fall."
Seit Wann ist ein Produkt, nur weil es das beste ist, ein Monopol, obwohl es zig Alternativen gibt und die tatsächliche Verbreitung des "besten" Produkts (wie du selber festgestellt hast) nicht so besonders ist :]
Ich glaube das ist nur Wunschdenken deinerseits :P Lol, Du Scherzkeks ... Mit dem Intelcompiler bekommt man nen Performancevorsprung, darüber reden wir doch die ganze Zeit ... natürlich kannst Du für Deinen Code auch nen langsamen Compiler nehmen, für GUI Software etc. ist das auch egal (hab ich auch schon geschrieben), aber wenn Du eben viele Berechnungen hast, dann willst Du den schnellsten Code haben, v.a. wenn es auch noch Konkurrenten für Deine Software / Endprodukt geben sollte.
Ich probiers mal mit nem Beispiel (und bin schon gespannt, was Du da dran bemängeln könntest^^) :
Was für einen Apfel würdest Du kaufen ?
a) Den frisch polierten, rotbackigen, in Watte verpackten, aus dem Regal, oder
b) den halbfaulen am Boden ?
Klar, wenn Du kurz vorm Verhungern stehst, dann tuts der halbfaule b) Apfel auch, zum Überleben reichts ^^ Die Wahlmöglichkeit ist aber nicht wirklich doll, und als Spitzensportler nähme man natürlich den a) Apfel; nicht dass man sich mit dem andren Apfel noch den Magen verderben würde :)
Ums kurz und deutlich zu machen:
a) Für printf ("Hello, World"); braucht man nun wirklich keinen ICC einsetzen :)
b) Wenn Du aber komplizierte Berechnungen ausführen willst und die Zielplattform Windows ist, dann wärst Du schön blöd, wenn Du keinen ICC verwenden würdest ... (oder aber verdammt schlau, indem Du alles selbst in Assembler codest und überhaupt keinen Compiler brauchst ^^ ).
ciao
Alex
Dem Assembler Programmierer traue ich zu schlauer zu sein, der kapiert was der Code machen soll, und kann dann die Befehlsabfolge so optimieren, dass die spezielle xy CPU am wenigstens Takte damit vertrödelt. Dem Compiler gestehe ich zu, hauptsächlich auf Befehlssätze optimieren zu können, Optimierungen der Gesamtlaufzeit sind wohl in Maßen auch möglich, aber nachdem der Opteron so gut mit dem, offiziell für Prescott optimierten, Code läuft [-QxP] kanns da nicht weit mit einer speziellen Prescott Optimierung her sein.
In jedem Fall: Wozu braucht man den Programmierer ? Sicherlich nicht, um die gleiche Arbeit zu machen, die der ICC schon könnte ...
Weiteres Beispiel für nen ähnlichen Fall wären die Performance Libraries, da werden dem Compiler händisch optimierter Code für häufig genützt Funktionen untergejubelt. Da seh ich ne CPU Abfrage auch ein, auch wenn es für den Endkunden natürlich am wünscheswertesten wäre, wenn man die Abfrage wählen könnte.
Lol, ich schreib den Satz mal um, dann sieht man dass er Käse ist "du tust ja gerade so, als hätte jeder PC Nutzer Windows auf seinem PC, bzw er MÜSSE es verwenden. Doch das ist nicht der Fall."
Lol, Du Scherzkeks ... Mit dem Intelcompiler bekommt man nen Performancevorsprung, darüber reden wir doch die ganze Zeit ... natürlich kannst Du für Deinen Code auch nen langsamen Compiler nehmen, für GUI Software etc. ist das auch egal (hab ich auch schon geschrieben), aber wenn Du eben viele Berechnungen hast, dann willst Du den schnellsten Code haben, v.a. wenn es auch noch Konkurrenten für Deine Software / Endprodukt geben sollte.
Ich probiers mal mit nem Beispiel (und bin schon gespannt, was Du da dran bemängeln könntest^^) :
Was für einen Apfel würdest Du kaufen ?
a) Den frisch polierten, rotbackigen, in Watte verpackten, aus dem Regal, oder
b) den halbfaulen am Boden ?
Klar, wenn Du kurz vorm Verhungern stehst, dann tuts der halbfaule b) Apfel auch, zum Überleben reichts ^^ Die Wahlmöglichkeit ist aber nicht wirklich doll, und als Spitzensportler nähme man natürlich den a) Apfel; nicht dass man sich mit dem andren Apfel noch den Magen verderben würde :)
Ums kurz und deutlich zu machen:
a) Für printf ("Hello, World"); braucht man nun wirklich keinen ICC einsetzen :)
b) Wenn Du aber komplizierte Berechnungen ausführen willst und die Zielplattform Windows ist, dann wärst Du schön blöd, wenn Du keinen ICC verwenden würdest ... (oder aber verdammt schlau, indem Du alles selbst in Assembler codest und überhaupt keinen Compiler brauchst ^^ ).
ciao
Alex
nun hier steige ich aus, weils mir echt zu blöde wird und weil mein internetfreies WE beginnt ;D
Ps.: Den Scherzkeks schiebe ich nach deinem gelungenen Posting zu dir zurück, du hast ihn mehr verdient ;D
edit.: Ok einen bring ich noch :D
Beispiel:
Firma XYZ baut das schnellste Beförderungsmittel der Welt, dieses kann aber nur mit dem hauseigenen (sauteueren) Treibstoff optimal arbeiten, bei gewöhnlichen billigen Treibstoff (der erkannt wird), schaltet das ding runter und arbeitet nur noch halb so schnell, obwohl es auch schneller könnte.
Dürfen da jetzt die Treibstoffhersteller die Firma XYZ anklagen?
Das gleiche ist ja auch bei Druckerpatronen zu beobachten :]
Das gleiche ist ja auch bei Druckerpatronen zu beobachten :] Achtung ! Bei den Druckerpatronen ist einzigund alleine ein eingebauter Chip geschützt, der den Füllstand oder sonstwas anzeigt. Es kann Dir dort nämlich sonst keiner verbieten die billige ("langsame") Nachfülltinte zu verwenden ...
schönes Wochenend :)
ciao
Alex
Beispiel:
Firma XYZ baut das schnellste Beförderungsmittel der Welt, dieses kann aber nur mit dem hauseigenen (sauteueren) Treibstoff optimal arbeiten, bei gewöhnlichen billigen Treibstoff (der erkannt wird), schaltet das ding runter und arbeitet nur noch halb so schnell, obwohl es auch schneller könnte.
Dürfen da jetzt die Treibstoffhersteller die Firma XYZ anklagen?Bei dem Beispiel fehlt ein Punkt, sonst hinkt es ganz stark: Die Firma hat bei dem Beförderungsmittel ein Quasimonopol.
Wenn der Compiler einen gewissen Verbreitungsgrad hat bzw. größere Firmen nur diesen einen einsetzten darf es durch dieses Produkt zu keiner Wettbewerbsverzerrung kommen... fertig
Mhm. Intel hat doch eigentlich 4 Möglichkeiten:
1. Sie stellen den Intel-compiler ein [ok. blöde Idee, man verdient ja viel Geld damit :D]
2. Sie unterstützen jede CPU [logisch, dann steht mein Kongruent (ohne etwas zu leisten) besser da als ich -> blöde Idee]
3. Sie unterstützen NUR noch eigene CPUs, auf anderen nicht mehr lauffähig. [das schreckt die potenziellen Käufer des Compilers ab, da sie zusätzliche Alternative brauchen -> ungünstig]
4. Sie unterstützen non-Intel-Cpus nur rudimentär, optimales Compilat läuft dann nur auf Intel-CPUs, suboptimales dagegen auf allen anderen CPUs [quasi ein Kompromiss aus 2. und 3.]
Was würdet ihr tun?
Was würdet ihr tun? Mittlerweile die Diskussion ins Prozessor Forum verschieben. 8)
Sehe es wie Twodee, ansonsten bringt es auch nichts sich darüber aufzuregen. Entweder nimmt man was anderes oder optimiert per Hand. Es gibt Alternativen, das sie schlechter sind, ist nicht Intels schuld --> kein Monopol (Quasi ist nur Quasi halt). Soll sich AMD hinsetzten und ihre Hausaufgaben endlich machen. Vielleicht hilft ja da jemand von ATI aus, deren Treiber immer besser werden...
TAL9000
4. Sie unterstützen non-Intel-Cpus nur rudimentär, optimales Compilat läuft dann nur auf Intel-CPUs, suboptimales dagegen auf allen anderen CPUs [quasi ein Kompromiss aus 2. und 3.]
Was würdet ihr tun?
Natürlich 4 ist schon klar, aber das Problem ist, dass Intel offiziell von z.B. SSE spricht und keiner mitbekommt, dass einmal Intel-SSE oder AMD-SSE erzeugt wird. V.a. auch da es keinen tech. Grund dafür gibt ...
Als offizielle Entschuldigung gibt Intel ja immer an, dass sie nicht garantieren könnten, dass der Code fehlerfrei auf AMD CPUs liefe, da sie die AMD erratas nicht berücksichtigen. Aber wo ist dann der Unterschied zum wenig optimierten SSE Code ... *noahnung*, da werden sie das ja schließlich auch nicht prüfen ...
ciao
Alex
Aus aktuellem (VIA NANO Test) Anlass, hier auch noch das hübsche Bildchen:
http://media.arstechnica.com/reviews/hardware/atom-nano-review.media/PCM2K5-2.jpg
http://arstechnica.com/reviews/hardware/atom-nano-review.ars/6
Schade das der Trick mit aktuellen Intel Compilaten nicht mehr geht :(
ciao
Alex
Schöner Artikel, der Schreiber schiebt die Schuld in Richtung Futuremark ;D - weil sie es nicht auf die Reihe kriegen, sämtliche Optimierungspfade richtig zu setzen. Da war wohl einer so nachlässig und hat die App kurzerhand mit dem V8 (?) kompiliert und fertisch ;D
Schöner Artikel, der Schreiber schiebt die Schuld in Richtung Futuremark ;D - weil sie es nicht auf die Reihe kriegen, sämtliche Optimierungspfade richtig zu setzen. Da war wohl einer so nachlässig und hat die App kurzerhand mit dem V8 (?) kompiliert und fertisch ;D
Der Witz kommt noch, stickedy hat rausgefunden, dass sich beim Nano eventuell die Family und Model Bits per MSR Editor setzen lassen:
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=6689822#post6689822
Eventuell deswegen, da er nur ne Doku für den Ezra Vorgänger hat.
Da sollte man mal auf Core2 einstellen und dann die üblichen Benchmarks / games laufen lassen, falls das denn wirklich geht.
Das wäre mal interessant, ob es denn überhaupt nen Unterschied macht, und falls ja, wieviel ;-)
Eventuell kann man schon ein bisschen mit nem C7 testen, falls jemand sowas hat .. Freiwillige vor :)
ciao
Alex
Das kommt davon, wenn man nen K10 mit K8 libraries betreibt:
http://www.digit-life.com/articles3/cpu/phenom-x4-matlab-p1.html
ciao
Alex
K8? Du meinst Intel-libraries.
Da hat Matlab aber ganz schön geschlampt.
K8? Du meinst Intel-libraries.
Da hat Matlab aber ganz schön geschlampt.
Ne die Autoren schrieben ja, dass die AMD Library wahrscheinlich ne alte Version ohne K10 Optimierungen war, ergo K8 only ...
Wenn ich mich recht erninnere hat schon mal ein DC Kollege im Seti Forum gemeint, dass AMDs mit den Intel Libs schneller laufen.
MatLab kann man wohl nicht viel vorwerfen, die neuste AMD Version geht erstmal überhaupt nicht .. sollte man bei sowas nicht ein festes Interface haben ?
ciao
Alex
Mhm da haben wir uns missverstanden.
Wenn du "K10 mit Intel libraries vs AMD (K8 optimiert) libraries" anstatt "K10 mit K8 libraries" geschrieben hättest, wäre es ersichtlicher worauf du hinaus wolltest *buck*
(der von dir verlinkte thread handelt ja von nichts anderem ;))
Hab da gerade etwas ausgegraben ;D
http://yro.slashdot.org/comments.pl?sid=155593&cid=13042922
oldDirty
17.12.2008, 10:47
Zum topic ist mir was interessantes eingefallen;
Du hast ein Auto* und fährst damit zur Arbeit. Nimm doch ein paar Leute von der Bushaltestelle mit die da stehen und warten, du hast doch genug Sitzplätze im Auto frei und das bischen Umweg für Dich, kostet doch fast nix.
Ach wie jetzt, Du hast das Auto bezahlt und willst nur deine Freunde mitnehmen, na dann eben nicht.
*angenommen
@oldDirty:
Blöd nur, dass Dein Auto das einzig im ganzen Land mit TopSpeed > 20km/h ist. Sicherlich stark übertrieben, aber so ähnlich ist die Situation :) Wenigstens wird der M$ Compiler immer besser :)
Hab da gerade etwas ausgegraben ;D
http://yro.slashdot.org/comments.pl?sid=155593&cid=13042922
Tolles Fundstück, v.a. der Workaround mit
__intel_cpu_indicator = -512;
ist simpel :)
Thx
Alex
das problem ist, das dieser Workaround wohl nicht mehr auf dem ICC11 funktioniert, zumindest läuft die App dann nicht mal mehr auf IntelMaschinen. Werde mich aber damit noch etwas spielen, vllt geht was.
das problem ist, das dieser Workaround wohl nicht mehr auf dem ICC11 funktioniert, zumindest läuft die App dann nicht mal mehr auf IntelMaschinen. Werde mich aber damit noch etwas spielen, vllt geht was.
Naja, wenn ich mich recht erinnere, dann muss man den Wert je nach verbauter CPU entsprechend justieren. Das Beispiel geht nur mit P3 /P4. Mit den Core2 CPUs ist jetzt vielleicht auch ein andrer Wert erwünschenswert. Der im Beispiel war ja SSE2 / P4. Welcher das jetzt für SSE3 & Core2 ist .. kA. Genausowenig, mit welchem ursprünglichen Wert ein AMD Chip bedacht wird.
Aber es ist auch gut möglich, dass das jetzt komplizierter abläuft, wir hatten ja schon früher die Geschichte mit den erweiterten Families ...
ciao
Alex
Naja, wenn ich mich recht erinnere, dann muss man den Wert je nach verbauter CPU entsprechend justieren. Das Beispiel geht nur mit P3 /P4. Mit den Core2 CPUs ist jetzt vielleicht auch ein andrer Wert erwünschenswert. Der im Beispiel war ja SSE2 / P4. Welcher das jetzt für SSE3 & Core2 ist .. kA. Genausowenig, mit welchem ursprünglichen Wert ein AMD Chip bedacht wird.
Aber es ist auch gut möglich, dass das jetzt komplizierter abläuft, wir hatten ja schon früher die Geschichte mit den erweiterten Families ...
ciao
Alex
__intel_cpu_indicator = 1024; // 1024 for pentium-m, 512 for xeon...
das lief schon auf meinem P-M nicht. viel mehr hab ich aber nicht getestet. [mir ging es ja um eine SSE-AMD Version]
oldDirty
19.12.2008, 14:29
@oldDirty:
Blöd nur, dass Dein Auto das einzig im ganzen Land mit TopSpeed > 20km/h ist. Sicherlich stark übertrieben, aber so ähnlich ist die Situation :) Wenigstens wird der M$ Compiler immer besser :)
Nicht mit einem Mercedes ( Intel ). :w_grins:
Falls es noch jemanden interessiert, hier hat jemand Skripe für Intels Linux Compiler geschrieben, um die Intel Abfrage herauszupatchen:
http://server01.iiiii.info/patch-AuthenticAMD.html
ciao
Alex
Nightshift
16.06.2009, 15:15
Interessiert mich, aber der Link ist down ...
Bei mir gehts ... hab gerade das gzip Archiv runtergeladen .. bis Du gerade in China oder Iran ? ;-)
ciao
Alex
hoschi_tux
16.06.2009, 17:25
Muss man da eine Lizenz für die ICC haben?
Muss man da eine Lizenz für die ICC haben?
Soviel ich weiss ist der ICC für Linux doch eh umsonst, oder nicht ?
Aber ok, Linzenz kann ja auch nichts kosten.
Wie auch immer ... patchen darfst Du laut Lizenz (wenn Du da irgendwo was anklicken musst, z.B. beim Runterladen) nicht ... da bist Du dann ein ganz Böser wenn Du das tust ;-)
ciao
Alex
P.S:
@Nightshift (http://www.planet3dnow.de/vbulletin/member.php?u=9922)
Link geht immer noch, vielleicht hast Du ja auch ne Intel - IP, die er auf seinem webserver geblockt hat *chatt*
hoschi_tux
16.06.2009, 17:39
Error: A license for CCompL could not be obtained (-1,359,2).
Is your license file in the right location and readable?
The location of your license file should be specified via
the $INTEL_LICENSE_FILE environment variable.
License file(s) used were (in this order):
1. /opt/intel/cce/10.1.018/licenses/*.lic
2. /opt/intel/licenses
3. /home/hoschi/intel/licenses
4. /Users/Shared/Library/Application Support/Intel/Licenses
Please visit http://support.intel.com/support/performancetools/support.htm if you require technical assistance.
icc: error #10052: could not checkout FLEXlm license
Soviel dazu..
Soviel dazu..
Aha .. dann braucht man wohl ein license file ...
You also need to get a license. For the purposes of this guide, we'll get a free non-commercial license. Click 'Free non-commercial Download' on Intel's Linux Compiler page (http://www.intel.com/cd/software/products/asmo-na/eng/compilers/284264.htm). Follow the steps on the site and place your license file in /opt/intel/licenses/.http://www.gentoo-wiki.info/HOWTO_ICC_and_Portage#Uncripple_icc_on_AMD_CPUs
Edit, da kommt man dann hier hin:
https://registrationcenter.intel.com/RegCenter/AutoGen.aspx?ProductID=1166&AccountID=&EmailID=&ProgramID=&RequestDt=&rm=NCOM&lang=
Riddler82
16.06.2009, 21:31
Ich warte gespannt auf Ergebnissse von bösen Buben :P
hoschi_tux
17.06.2009, 00:37
GCC: 0m39.928s
ICC unpatched: 0m22.014s
ICC patched: 0m22.700s
Entweder bringt der Patch nicht viel, oder er funktioniert nicht. Getestet wurde mit benchmark-partial-sums aus dem Paket. Vergleichswerte gibt es auf der Seite.
Hier noch ein Test mit nbench.
GCC:
TEST : Iterations/sec.
------------------------------------------------------------
NUMERIC SORT : 1205
STRING SORT : 201.12
BITFIELD : 4.8345e+08
FP EMULATION : 225.52
FOURIER : 20003
ASSIGNMENT : 25.529
IDEA : 7140
HUFFMAN : 1877
NEURAL NET : 41.134
LU DECOMPOSITION : 1445.5
==============ORIGINAL BYTEMARK RESULTS==============
INTEGER INDEX : 75.326
FLOATING-POINT INDEX: 48.283
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============LINUX DATA BELOW==============
CPU : Dual AuthenticAMD Dual Core AMD Opteron(tm) Processor 285 2600MHz
L2 Cache : 1024 KB
OS : Linux 2.6.28-gentoo-r1
C compiler : x86_64-pc-linux-gnu-gcc
libc :
MEMORY INDEX : 18.242
INTEGER INDEX : 19.224
FLOATING-POINT INDEX: 26.780
ICC:
TEST : Iterations/sec.
---------------------------------------------------------------
NUMERIC SORT : 1442.6
STRING SORT : 217.52
BITFIELD : 4.6496e+08
FP EMULATION : 364.16
FOURIER : 54855
ASSIGNMENT : 19.578
IDEA : 7087.5
HUFFMAN : 2214.7
NEURAL NET : 59.313
LU DECOMPOSITION : 1927.1
==============ORIGINAL BYTEMARK RESULTS==============
INTEGER INDEX : 81.965
FLOATING-POINT INDEX: 84.030
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
================LINUX DATA BELOW================
CPU : Dual AuthenticAMD Dual Core AMD Opteron(tm) Processor 285 2600MHz
L2 Cache : 1024 KB
OS : Linux 2.6.28-gentoo-r1
C compiler : icc
libc :
MEMORY INDEX : 16.919
INTEGER INDEX : 23.581
FLOATING-POINT INDEX: 46.607
ICC patched:
TEST : Iterations/sec.
-----------------------------------------------------------------------
NUMERIC SORT : 1436.6
STRING SORT : 217.44
BITFIELD : 4.807e+08
FP EMULATION : 363.54
FOURIER : 54454
ASSIGNMENT : 19.482
IDEA : 7063.5
HUFFMAN : 2205.4
NEURAL NET : 59.073
LU DECOMPOSITION : 1936.6
==============ORIGINAL BYTEMARK RESULTS==============
INTEGER INDEX : 82.135
FLOATING-POINT INDEX: 83.850
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============LINUX DATA BELOW==============
CPU : Dual AuthenticAMD Dual Core AMD Opteron(tm) Processor 285 2600MHz
L2 Cache : 1024 KB
OS : Linux 2.6.28-gentoo-r1
C compiler : icc
libc :
MEMORY INDEX : 17.077
INTEGER INDEX : 23.502
FLOATING-POINT INDEX: 46.507
Hier wiederholt sich in etwa das bekannte Ergebnis. Der Patch funktioniert wohl also wirklich nicht. Wobei ich jetzt nur die Binary gepatcht habe und nicht die kompletten Libs.
Ungeachtet dessen ist der Zuwachs bei FP Emulation und Fourier recht ordentlich.
Da es schon relativ spät ist, werde ich evtl. morgen noch ein paar Benches durchführen. Evtl. auch mit Spielen, sofern ich welche mit Benchmarkfunktion finde.
Edit:
Es reizt mich eben doch noch und so habe ich die Libs schnell noch gepatcht.
ICC patched libs:
TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 1434.4 : 36.79 : 12.08
STRING SORT : 218 : 97.41 : 15.08
BITFIELD : 4.7478e+08 : 81.44 : 17.01
FP EMULATION : 364.2 : 174.76 : 40.33
FOURIER : 55124 : 62.69 : 35.21
ASSIGNMENT : 19.561 : 74.43 : 19.31
IDEA : 7088 : 108.41 : 32.19
HUFFMAN : 2212 : 61.34 : 19.59
NEURAL NET : 59.281 : 95.23 : 40.06
LU DECOMPOSITION : 1937.6 : 100.38 : 72.48
==============ORIGINAL BYTEMARK RESULTS==============
INTEGER INDEX : 82.147
FLOATING-POINT INDEX: 84.306
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============LINUX DATA BELOW==============
CPU : Dual AuthenticAMD Dual Core AMD Opteron(tm) Processor 285 2600MHz
L2 Cache : 1024 KB
OS : Linux 2.6.28-gentoo-r1
C compiler : icc
libc :
MEMORY INDEX : 17.044
INTEGER INDEX : 23.542
FLOATING-POINT INDEX: 46.759
Und der benchmark-partial-sums: 0m22.064s
Also keine wirkliche Änderung. Alles im Bereich der Unsicherheiten.
Hmmm,
ich hatte beim ersten drüberlesen den Verdacht, das der Kollege da nur das alte CPUID Zeugs patcht, aber nicht die neuren extended Attribute.
Vielleicht liegts daran.
Vielleicht liegts auch an Deiner CPU, Du hast ja noch keine 128bit FPU, eventuell merkst Du den Unterschied deshalb gar nicht, da FPU Code Durchsatz mit 64-80bit nicht rechtviel schneller als SSE1/2 Durchsatz mit 2x64bit ist, egal ob jetzt 64 oder 128bit Befehle.
Wenn Du Lust und Laune hast, kannst Du unter Linux auch gleich den neuen AMD Compiler testen, ob der was reißen kann ^^
http://developer.amd.com/cpu/open64/pages/default.aspx
ciao
Alex
hoschi_tux
17.06.2009, 18:16
I'm on my way..
Edit:
benchmark-partial-sums segfaultet und nbench lässt sich nicht kompilieren aufgrund einer undefined reference.
Mal sehen, ob ich das noch gefixt bekomme.
Ich lach mich schief, da hat ein Intel Mensch nen Vortrag auf ner Spielemesse gehalten:
Multicore-Optimierungen werden immer relevanter, erfordern es aber auch, den Aufbau der verschiedenen CPUs zu berücksichtigen und beispielsweise Cache-Größen im Auge zu behalten, insbesondere wenn sich mehrere Kerne einen Cache teilen. Davies hält es deshalb für wichtig, dass Anwendungen erkennen, auf was für einer CPU sie laufen und wie sie diese optimal ausnutzen können.
Wünschenswert seien verschiedene Code-Pfade, die dann optimal auf die Architekturen angepasst sind.
(...)
Ebenso sollte CPUID richtig genutzt werden, damit die Ermittlung der Kerne, Cachegröße und weiterer Angaben nicht schiefgeht.
Unterstützung für Entwickler
Die nötigen Compiler und Entwicklertools (http://software.intel.com/en-us/) zur Optimierung für verschiedene Architekturen sowie die zu berücksichtigenden Prozessorspezifikationen (http://www.intel.com/products/processor/manuals/) und Infos zur korrekten Ermittlung von CPUs (http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/) bietet Intel auf seiner Website an.
http://www.golem.de/0908/69126.html
Tja alles schön und nett ... nur blöderweise sollte das halt "korrekte Ermittlung von Intel CPUs" heißen, kleiner aber feiner Unterschied ..
ciao
Alex
Ach bei 70-80% Marktanteil vergisst man schnell mal das es noch andere x86er gibt *buck*
Tja alles schön und nett ... nur blöderweise sollte das halt "korrekte Ermittlung von Intel CPUs" heißen, kleiner aber feiner Unterschied ..
Wieso, AMD CPUs werden doch auch korrekt erkannt und ausgebremst... :P
nö, da wird nix gebremst, es wird nur nicht "zusätzlich" beschleunigt. kleiner aber feiner unterschied.
Höchstwahrscheinlich vorläufiges Ende des Threads:
Btw. as far as I remember the AMD was also complaining about the ICC code not running optimized code on AMD chips in the charge against intel. Now, after AMD and Intel setteled and Intel stated that they wont use the old "tricks" again; would it mean that the ICC would be running better code on AMD's CPUs in the future (e.g. AVX) ?
You are correct.
http://www.amdzone.com/phpbb3/viewtopic.php?f=52&t=137095&start=50#p171695
[MTB]JackTheRipper
20.11.2009, 19:12
Da bin ich aber mal gespannt...
Ich will ne Patch-Flut für alle mit dem ICC erstellten Programme! :D
warum sollten sie das tun? compiler optimierungen for free? ne daran glaube ich nicht.
[MTB]JackTheRipper
22.11.2009, 10:04
warum sollten sie das tun? compiler optimierungen for free? ne daran glaube ich nicht.
Ist ja nicht so, dass das einen großen Aufwand darstellen würde. Es geht ja auch nicht darum besondere AMD Features zu implementieren, sondern die Standardbefehlssätze welche Intel sowieso verwendet nicht für AMD zu sperren.
Ach ne, das Optimieren der Standardbefehlssätze ist also ohne Aufwand erledigt worden? Dann frage ich mich, warum AMD dann sowas im gleichem Umfang nicht selber macht *lol*
Ach ne, das Optimieren der Standardbefehlssätze ist also ohne Aufwand erledigt worden? Dann frage ich mich, warum AMD dann sowas im gleichem Umfang nicht selber macht *lol* Ich glaub er meint die Intel Inside Abfrage - die zu beseitigen wäre kein Problem für Intel :)
Das weiß ich doch ;) Meine Aussage bezog sich auf das darauffolgende Szenario :)
Er hat ja nicht gesagt, das die Oprimierungen keinen Großen Aufwand darstellten. Lediglich dass das Abschalten der Verhinderung der Optmimierungen durch AMD-Prozessoren keinen großen Aufwand darstellt. Die Optimierungen sind ja vohanden, sie müssen nur auch den AMD-Prozessoren zugänglich gemacht werden.
Edit: zu langsam.
[MTB]JackTheRipper
22.11.2009, 17:00
Genau so war das gemeint ;)
Vll war dies auch Verhandlungsgrundlage für die außergerichtliche Einigung.
Es geht nicht um den Lock, klar das ist keine "Arbeit" diesen zu enfernen, jedoch hat es Arbeit/Kohle/Zeit/x-Man-Power gekostet, die Optimierungen der "Standarderweiterungen" auf ein ungeschlagenes hohes Niveau zu bringen. Und das bekommt AMD for free? Vllt ist Intel deshalb so milde mit den 1.25 Mil. $ davon gekommen. Hat da AMD bei Intel eingekauft? *buck*
Es geht nicht um den Lock, klar das ist keine "Arbeit" diesen zu enfernen, jedoch hat es Arbeit/Kohle/Zeit/x-Man-Power gekostet, die Optimierungen der "Standarderweiterungen" auf ein ungeschlagenes hohes Niveau zu bringen. Und das bekommt AMD for free? Vllt ist Intel deshalb so milde mit den 1.25 Mil. $ davon gekommen. Hat da AMD bei Intel eingekauft? *buck*
für die Optimierung bezahlen doch die Käufer des Copilers. Was hat das bitte mit AMD zu tun?
AMD muss in diesem Fall nichts in Sachen SoftwareOptimierungen investieren, da es so wie immer im Falle AMDs ein anderer tut.
AMD muss in diesem Fall nichts in Sachen SoftwareOptimierungen investieren, da es so wie immer im Falle AMDs ein anderer tut.
Naja, das muss man im gesamten Überblick mit dem ganzen Patenteaustausch sehen, intel bekommt jetzt auch die ganzen ATi Patente, möglich das man da nen Kuhhandel gemacht hat, was weiss man schon. ;-)
Umsonst wird Intel das auf alle Fälle nicht machen, aber laut Aussage von JF machen sies ... im kleinsten Fall haben sie auch "nur" Angst vor den ganzen Strafzahlungen, bzw., vor den ganzen Anwaltskosten und Gerichtsgebühren. Vielleicht kommts billiger, wenn man nachgibt *noahnung*
Im Endeffekt hilfts doch intel sowieso, ohne AMD würden die eh zerschlagen. Bevor das passiert, können sie doch AMD ein bisschen Compileroptimierung und Marktanteile gönnen ;-)
Aber warten wir erstmal ab, ob wirklich was passiert, vielleicht gibts da im Compilerfall (immer) noch "Meinungsverschiedenheiten" *chatt*
ciao
Alex
AMD muss in diesem Fall nichts in Sachen SoftwareOptimierungen investieren, da es so wie immer im Falle AMDs ein anderer tut.
ich spreche nicht von hardwarespezifischer optimierung.
wenn ich zwei stück hardware habe und beide verstehen den gleichen befehlssatz, dann sollte dieser auch auf beiden funktionieren. dafür bezahle ich als kunde, wenn ich den compiler kaufe.
kein mensch verlangt von intel umsonst den compiler auf AMD CPUs zu otimieren.
ich spreche nicht von hardwarespezifischer optimierung.
ich auch nicht.
wenn ich zwei stück hardware habe und beide verstehen den gleichen befehlssatz, dann sollte dieser auch auf beiden funktionieren. dafür bezahle ich als kunde, wenn ich den compiler kaufe.
Es geht mir hier nicht um den Kunden, verstehst du das nicht? Ich rede von Entwicklungskosten für den Compiler, welcher nur ein Hersteller tragen muss aber dem anderen auch zu gute kommt. [gut man weiß nicht was AMD dafür hergegeben hat ;)]
kein mensch verlangt von intel umsonst den compiler auf AMD CPUs zu otimieren.
kein Mensch hat das hier im Thread verlangt!
Es geht mir hier nicht um den Kunden, verstehst du das nicht? Ich rede von Entwicklungskosten für den Compiler, welcher nur ein Hersteller tragen muss aber dem anderen auch zu gute kommt. [gut man weiß nicht was AMD dafür hergegeben hat ;)]
Ich weiß nicht was du damit immer willst.
Für diesen Aufwand kommt der Kunde auf, also der Käufer des Compiler.
Sonst würde das Produkt unter Wert verkauft, was illegal ist.
Warum vermengst du Intel den Hardwarehersteller und Intel den Compiler Anbieter?
Das ist irgendwie die gleiche Art von Diskussion wie bei Batman.
Ich weiß nicht was du damit immer willst.
Für diesen Aufwand kommt der Kunde auf, also der Käufer des Compiler.
Sonst würde das Produkt unter Wert verkauft, was illegal ist.
Wer sagt denn das sie den "Wert" über die Softwaregebühren rein holen?
Warum vermengst du Intel den Hardwarehersteller und Intel den Compiler Anbieter?
Das ist irgendwie die gleiche Art von Diskussion wie bei Batman.
Nein ist es nicht.
Wer sagt denn das sie den "Wert" über die Softwaregebühren rein holen?
Dann sind wir wieder beim alten Thema Missbrauch von Marktmacht.
(+ Subventionierung der Compiler durch Hardwareverkauf)
Die Diskussion führt zu nichts.
Dann sind wir wieder beim alten Thema Missbrauch von Marktmacht.
(+ Subventionierung der Compiler durch Hardwareverkauf)
Die Diskussion führt zu nichts.
Wer diskutiert hier? Ich oder du? Ich habe nur meine Meinung dazu kundgetan, mehr nicht.
Wer diskutiert hier? Ich oder du? Ich habe nur meine Meinung dazu kundgetan, mehr nicht.
das ist ein für dich absolut typischer Post!
Was ist den bitte eine Diskussion deiner Meinung nach?
Laut Duden ist sie ein Meinungsaustausch. Und genau den betreibt man im allgemeinen in einem Forum.
Ja was willst du eigentlich von mir?
Captn-Future
23.11.2009, 15:18
So ihr zwei, schaltet bitte einfach mal zwei Gänge zurück. Mir ist es relativ egal wer hier mit wem diskutiert oder nur seine Meinung äußert.
Fakt ist jedenfalls, daß Intel und AMD eine Einigung ausgehandelt haben und noch keiner absehen kann wie diese Einigung aussieht. Solange sollte man sich vielleicht noch gedulden. Mal ganz abgesehen davon hat Intel einen Compiler selber programmiert der auf Intel CPUs optimiert wurde. Ich denke schon das Intel das Recht hat ihren eigenen Compiler auf andere eigene Produkte abzustimmen.
Intel hat nicht einen Dritten beauftragt/bestochen/korrumpiert den Compiler so umzuschreiben das er auf AMD schlechter läuft. Darüber sollte man mal nachdenken, nicht nur auf Intel rumhacken. Mal abgesehen davon laufen andere Programme die mit anderen Compilern kompiliert wurden auf AMD noch langsamer als wenn man den Intel Compiler genommen hätte.
Hier nochmal was zu den Compileroptimierungen.
Der Compiler steht nun auch im Blickfeld der FTC:
http://www.gamestar.de/hardware/news/prozessoren/2311347/intel.html
Intel habe seit Jahren unzulässigerweise in seine Compiler eine Abfrage nach dem Herstellernamen des Prozessors eingebaut und danach die verschiedenen Compilerpfade genutzt.
Antwortete eine CPU mit „GenuineIntel“ und ergab die nächste Prüfung die Fähigkeit für „SSE2“, so wurde der hochoptimierte, schnelle SSE2-Pfad verwenden. War die Antwort der CPU jedoch „AuthenticAMD“, wurde der langsamste FPU-Pfad genommen, ganz egal, ob die CPU SSE2 beherrscht oder nicht. SSE2 ist aber oft doppelt so schnell, bei einfacher Genauigkeit ist der Vorteil noch größer. Das ist ein enormer Nachteil für Nicht-Intel-Prozessoren, insbesondere, da viele Programme genau diesen Compiler verwendet, da er auf Intel-Prozessoren so schnell ist.
http://www.gamestar.de/hardware/news/prozessoren/2311347/intel.html
AMD hat meines bescheidenen Wissens für SSE2 an intel bezahlt... Eine einfache Programierung wie beim Aulesen der CPUID..."if CPUID=AutehenticAMD, than go to...bla..Pfad.../end...ist nicht AMD nicht zu untestützen, sondern unlauterer Wettbewerb, um nicht zu sagen: Arglist! und zus. eingefügt, bzw. bewust programiert.
Die Compilerfrage bleibt erstmal bestehen. Soweit mein Senf dazu! Thx @cumec
Aber....es ist Weihnachten,
Von daher: Frohe Weihnachten @alls !
Ich finds lustig, das jetzt alles noch mal durchgekaut wird, was schon seit jahren bekannt ist bzw. seit VIA Nano es bewiesen hat, nur weil jetzt die FTC klagt. Im 3DCenter wurde darüber gestritten das der ICC so gut wie keine Verwendung findet.....aber wer weiß das schon genau?
Muß man halt fairer Weise einfach eingestehen, oder auch nicht*noahnung*
na egal...
schöne Feiertage!
kenny1988
24.12.2009, 16:13
Aber eine Frage wen ihr euch so darüber aufregt wie so Programmiert ihr nicht euren eigennen Compiler?
Aber bitte die diskusion bringt nicht solange intel nicht gewillt ist ihn für AMD CPUs zu frei zu geben auserde Ist ja eh das maximale was intel für AMD zu verfügung stellt SEE 3
Das SEE 4a ist eh unütze und wirt eigentlich von keinen Compiler verwendet oder ausgenutzt.
Es wär auch echt mal schön wen von "die Kleinen CPU" Laibels auch einen eigenen Compiler entwickeln.
Dann gäbs diese Sinvolle und kaum was bringente diskusion nicht.
Ich wünsche euch allen ein Schönes Weihnachtsfest
[MTB]JackTheRipper
24.12.2009, 16:17
Darfst gern mal "kurz" so einen Compiler unentgeltlich schreiben...*suspect*
Die Diskussion ist jetzt eh müßig, der Ball liegt seit der Einigung mit AMD im Intel Feld, erst recht seit der letzten FTC Anklageschrift. Hier mal eine der Forderungen bezüglich des Compilers:
7. Requiring that, with respect to those Intel customers that purchased from Intel a software compiler that had or has the design or effect of impairing the actual or apparent performance of microprocessors not manufactured by Intel (“Defective Compiler”), as described in the Complaint:
a. Intel provide them, at no additional charge, a substitute compiler that is not a Defective Compiler;
b. Intel compensate them for the cost of recompiling the software they had compiled on the Defective Compiler and of substituting, and distributing to their own customers, the recompiled software for software compiled on a Defective Compiler; and
c. Intel give public notice and warning, in a manner likely to be communicated to persons that have purchased software compiled on Defective Compilers purchased from Intel, of the possible need to replace that software.
http://www.ftc.gov/os/adjpro/d9341/091216intelcmpt.pdf
Der aktuelle ICC ist laut FTC also "defekt" *chatt*
Frohes Fest
Alex, der jetzt zum Braten muss ^^
was bringt ein AMD Compiler, wenn alle den Intel Compiler verwenden?
Frohes Fest
@
pollux_9t
25.12.2009, 11:53
Vielleicht sollten die Leute mal einfach eine Alternative bekommen. Das mit der ICC sollte mal an die FTC gemeldet werden. Diese Praktiken gehören eingestellt. Vielleicht hilft ja OpenCL etwas. Da werden die Kernel ja meines Wissens nach in der Runtime kompiliert.
Was hat openCL mit x86/x64 Compiler zu tun?
.
EDIT :
.
was bringt ein AMD Compiler, wenn alle den Intel Compiler ?
@
Wer ist alle?
die 5%, welche nicht den mitgelieferten MS Compiler, welcher AMD unterstützt, benutzen?
Ich finds lustig, das jetzt alles noch mal durchgekaut wird, was schon seit jahren bekannt ist bzw. seit VIA Nano es bewiesen hat, nur weil jetzt die FTC klagt. Im 3DCenter wurde darüber gestritten das der ICC so gut wie keine Verwendung findet.....aber wer weiß das schon genau?
Es könnte sich ja mal was ändern... *suspect*
Dachte gelesen zu haben, daß der ICC in der Windows-Welt ziemlich oft benutzt wird!?
Aber eine Frage wen ihr euch so darüber aufregt wie so Programmiert ihr nicht euren eigennen Compiler?
Genau, ich hab mir schließlich auch mein eigenes Schienennetz + Züge gebaut, als ich die Bahn nur noch sch.... fand...genauso wars auch bei den Autos, da hab ich mir dann auch mein eigenes gebaut! ...und überhaupt...dieser Planet kotzt mich an, ich bau mir gleich nen neuen!
Nightshift
25.12.2009, 14:24
... allüberall auf den Tannenspitzen, sah ich den Sarkasmus blitzen!? ;)
Was mich an dieser Meldung positiv überrascht ist die Tiefe der technischer Details mit dem die FTC an die Sache herangegangen ist. Das ist man ja schon gar nicht mehr gewohnt.
kenny1988
25.12.2009, 16:42
JackTheRipper;4105951']Darfst gern mal "kurz" so einen Compiler unentgeltlich schreiben...*suspect*
Es geht ja nciht darum es ging darum das andere unzufrieden sind damit.
Es rechnet selbst mit intel Compiler AMD CPUs ja wesentlich schneller als normal mit den von windows.
Genau, ich hab mir schließlich auch mein eigenes Schienennetz + Züge gebaut, als ich die Bahn nur noch sch.... fand...genauso wars auch bei den Autos, da hab ich mir dann auch mein eigenes gebaut! ...und überhaupt...dieser Planet kotzt mich an, ich bau mir gleich nen neuen!
Hey mal nicht so sakastisch ;D.
Aber Jungs nicht so hitzig wir sind doch alle "Freunde" ne aber Die diskusion bringt halt leider ncihts das ist halt schade.
Aber ein eigener Compiler wääre echt net schlecht schlimer als der von AMD kan er nciht sein*buck*
*duck und wech*
Hey mal nicht so sakastisch ;D.
Aber du verstehst was ich meine? Wäre ich ein so fähiger Programmierer, würde ich sicher sofort damit anfangen...
...aber dann würde ich auch nur noch in Assembler mit euch reden! ;D
Die Zeiten sind vorbei, heutzutage werden solche Monsterprojekte nur noch in Hochsprachen entwickelt. ASM wird nur für sehr sehr kleine performance-kritische Routinen verwendet, ein Compiler muss nicht auf Teufel kom raus in einer gewissen Zeit übersetzen *chatt*
errr... wobei die ausgabe ins asm erfolgt, ok :)
Ja stimmt...hatten wir damals auch so gemacht mit diesem Pseudo-Compiler, dafür hatten wir Haskell genommen.
Wir durften im 2. Semster Compilerbau "händisch" nach ASM übersetzen :(
Nachtschicht
25.12.2009, 18:25
wobei die ausgabe ins asm erfolgt, ok :)
Nö, die Ausgabe erfolgt in Maschinencode. ASM ist die Programmiersprache dafür. Etwas Klugscheisserei muss sein. ;D
Aber mich würde mal interessieren, welche Marktanteile der ICC hat. Die meisten Firmen werden sich den zusätzlichen Schmerz (unter Windows) wohl nicht antun. Der ICC ist beim Compilieren arschlahm, was während der Programmentwicklung nur hinderlich ist.
Am ehesten könnte ich mir den Einsatz noch in rechenintensiven Applikationen, wie Video-Encoding, vorstellen. Bei Games wäre der Einsatz wohl eher kontraproduktiv, da hier oft AMD das bessere P/L-Verhältnis hat.
Nö, die Ausgabe erfolgt in Maschinencode. ASM ist die Programmiersprache dafür. Etwas Klugscheisserei muss sein. ;D
Gibts da nicht eine Zwischenschicht im ASM?
Aber mich würde mal interessieren, welche Marktanteile der ICC hat. Die meisten Firmen werden sich den zusätzlichen Schmerz (unter Windows) wohl nicht antun. Der ICC ist beim Compilieren arschlahm, was während der Programmentwicklung nur hinderlich ist.
Kommt drauf an mit welchen Opts man kompiliert, ansonsten einfach mit dem MS-kompiler kompilieren und wenn es fertig entwickelt ist per ICC kompilieren. Wobei ich jetzt keine spürbaren zeitlichen unterschiede festegestellt hatte, als ich die milkyway-app optimiert habe.
Erfolgt die Ausgabe nicht grundsätzlich in Maschinencode, wenn man ne Binärdatei erstellt? *suspect*
Nachtschicht
25.12.2009, 18:46
Erfolgt die Ausgabe nicht grundsätzlich in Maschinencode, wenn man ne Binärdatei erstellt? *suspect*
Genau das wollte ich sagen. Der Prozessor versteht nur Zahlen ...
Man kann bei vielen Compilern aus C/C++-Code auch ASM generieren, aber das ist eher eine Spielerei, um zu sehen, wie effizient die Anweisungen sind.
Hatte auch schon nach den Marktanteilen des ICC gegoogelt, aber nichts gefunden. Wenn die relevant wären, würde die Intel wahrscheinlich hinausposaunen.
Man kann bei vielen Compilern aus C/C++-Code auch ASM generieren, aber das ist eher eine Spielerei, um zu sehen, wie effizient die Anweisungen sind.
Nein. Compiler geben grundsätzlich erst mal ASM Code aus. Der wird nur normalerweise direkt in den Assembler gepiped. Wenn du dir den ASM Code ausgeben lässt stoppst du den Kompiliervorgang nur bevor der Assembler aufgerufen wird.
Genauso wird danach noch gelinkt, was auch nicht direkt mit dem Compiler zusammenhängt. Das sind alles einzelne Programme, welche nur in Zusammenarbeit am ende den Maschinencode erzeugen.
Genau das wollte ich sagen. Der Prozessor versteht nur Zahlen ...
Eben...ansonsten müßte man ja den Compiler mitliefern. ...wie bei Java...und erhält dementsprechende Performance.
pollux_9t
25.12.2009, 18:55
Wie siehts eigentlich mit GCC aus? Der dürfte ja einigermaßen neutral sein. Warum wird der nicht öfter in großen Projekten genutzt?
Wie siehts eigentlich mit GCC aus? Der dürfte ja einigermaßen neutral sein. Warum wird der nicht öfter in großen Projekten genutzt?
Hab mal gelesen, der erzeugt im Vergleich zum ICC teils grottenlahmen Code.
pollux_9t
25.12.2009, 19:10
Irgendwie schreit das ganze nach einem einheitlichen Standardcompiler. Einer unabhängigen Institution die einen Compiler schreibt, der für jede Architektur hochoptimierte Codepaths bereitstellt. Deswegen wundert es mich, dass GCC wirklich so lahm ist. Es kann doch jeder seine Verbesserungen einbringen oder? Dort sollte AMD ansetzen und ähnlich wie bei den freien Radeon Treibern Unterstützung bieten. (Wobei das wieder mal den guten Steve Ballmer verärgern könnte ) ...
Nachtschicht
25.12.2009, 19:15
Wie siehts eigentlich mit GCC aus? Der dürfte ja einigermaßen neutral sein. Warum wird der nicht öfter in großen Projekten genutzt?
Der wird in sehr großen Linux- und oft auch in UNIX-Projekten genutzt. Windows steht da nicht im Focus.
Linux/Unix spielen eine große Rolle in wichtigen oder gar sicherheitskritischen Bereichen, z.B. in der Telekommunikation oder der Bahntechnik.
Da ist der Marktanteil von MS nahe Null, der vom ICC unter *x ist wahrscheinlich noch überschaubarer als unter Windows.
Nein. Compiler geben grundsätzlich erst mal ASM Code aus.
Naja, da habe ich meine erheblichen Zweifel. Ich behaupte, wenn ich mir ein *.obj-File ansehe, finde ich darin keinen Assembler. Das ist verschiebbarrer Maschinencode, der sicherlich irgendeinem Standard gehorcht, aber kaum menschenlesbar ist.
Bin aber kein Experte auf dem Gebiet. Aber wenn es ASM wäre, müsste man den einfach aus den Objectfiles (Windows, Unix, Linux, ..) ausdrucken können. Also, wie geht das? ;)
Meinst du etwa das in den obj-files der asm im klartext stehen muss damit DU es als asm verstehst? *chatt*
Nachtschicht
25.12.2009, 19:54
Meinst du etwa das in den obj-files der asm im klartext stehen muss damit DU es als asm verstehst? *chatt*
Ja, klar. Ansonsten ist es kein Assembler. Ich gehe einfach von der Bedeutung des Begriffes aus und da gibt es einen Unterschied zwischen Assembler und Maschinencode.;)
http://de.wikipedia.org/wiki/Assemblersprache
http://de.wikipedia.org/wiki/Maschinensprache
Der GCC ist sehr gut bei C-Code, aber ziemlich schlecht bei C++-Code.
Ja, klar. Ansonsten ist es kein Assembler. Ich gehe einfach von der Bedeutung des Begriffes aus und da gibt es einen Unterschied zwischen Assembler und Maschinencode.;)
http://de.wikipedia.org/wiki/Assemblersprache
http://de.wikipedia.org/wiki/Maschinensprache
der asm welcher in hex-form und nicht als klartext gespeichert ist, ist trotzdem asm.
http://en.wikipedia.org/wiki/Assembly_language
Nachtschicht
25.12.2009, 21:01
der asm welcher in hex-form und nicht als klartext gespeichert ist, ist trotzdem asm.
http://en.wikipedia.org/wiki/Assembly_language
Nö, die englische Variante ändert nichts. Da steht u.a.:
"They implement a symbolic representation of the numeric machine codes and other constants needed to program a particular CPU architecture."
"Typically a modern assembler creates object code by translating assembly instruction mnemonics into opcodes, and by resolving symbolic names for memory locations and other entities."
Kurz: Assembler(sprache) ist eine Programmiersprache, die durch die Compilierung in Maschinencode (OpCode) übersetzt wird. Insofern ist da kein prinzipieller Unterschied zu C, man ist nur ganz dicht dran am Prozessor (und damit prozessorabhängig).
Sicherlich wird im Sprachgebrauch Assembler gern mit Binärcode (Maschinencode, Opcode, ...) gleich gesetzt, korrekt ist es trotzdem nicht.
.
EDIT :
.
Der GCC ist sehr gut bei C-Code, aber ziemlich schlecht bei C++-Code.
Quelle? Angelesen oder eigene Erfahrungen?
Quelle? Angelesen oder eigene Erfahrungen?Das ist das, was man von den ReactOS-Entwicklern seit Jahren immer wieder auf der Mailing-Liste und im IRC "hört". Kann allerdings auch sein, dass das nur für den Mingw-Port von GCC gilt (würde mich aber wundern).
Die ReactOS-Jungs beziehen sich da auch gar nicht mal so sehr auf die Geschwindigkeit des erzeugten Codes, sondern mehr auf Bugs und Inkompatibilitäten zwischen den einzelnen Versionen.
Nachtschicht
25.12.2009, 21:36
Das ist das, was man von den ReactOS-Entwicklern seit Jahren immer wieder auf der Mailing-Liste und im IRC "hört".
Naja, das sind vielleicht auch subjektive Befindlichkeiten. Irgend jemand meckert immer.
Wie bereits gesagt, sind Windows(-like) OS nicht im Scope des g++, unter Linux gibt es zum g++ sowieso keine Alternative.
Ob nun unter Solaris (CC) oder hpux (acc) die nativen Compiler oder der g++ genommen werden, wird eher durch die Finanzlage bestimmt, als durch Performanceunterschiede im niedrigen Prozentbereich.
Wie auch immer, kennt jemand denn nun Applikationen, die mit dem ICC compiliert wurden? Kann man das abtesten?
Nö, die englische Variante ändert nichts. Da steht u.a.:
"They implement a symbolic representation of the numeric machine codes and other constants needed to program a particular CPU architecture."
"Typically a modern assembler creates object code by translating assembly instruction mnemonics into opcodes, and by resolving symbolic names for memory locations and other entities."
Habe ich das in Frage gestellt? :]
Kurz: Assembler(sprache) ist eine Programmiersprache, die durch die Compilierung in Maschinencode (OpCode) übersetzt wird. Insofern ist da kein prinzipieller Unterschied zu C, man ist nur ganz dicht dran am Prozessor (und damit prozessorabhängig).
Sicherlich wird im Sprachgebrauch Assembler gern mit Binärcode (Maschinencode, Opcode, ...) gleich gesetzt, korrekt ist es trotzdem nicht.
Du glaubs mir immer noch nicht das ams-dateien NICHT immer im klartext ASM-Code enthalten müssen, sondern auch im Hex-format gespeichert werden kann?!
[nicht nur den 1. absastz im wiki lesen]
Nachtschicht
30.12.2009, 15:57
Habe ich das in Frage gestellt? :]
Du glaubs mir immer noch nicht das ams-dateien NICHT immer im klartext ASM-Code enthalten müssen, sondern auch im Hex-format gespeichert werden kann?!
Nein, natürlich nicht. Bisher hast du auch nichts angebracht, was meine Meinung ändern könnte. Wo ist denn jetzt wenigstens ein knackiges Zitat? ;)
Der Begriff Assembler wird in zwei Bedeutungen benutzt: als Programmiersprache und als "Compiler". Etwas verwirrend, aber völlig korrekt ist z.B.: Ich habe Assembler mit dem Assembler assembliert und Maschinencode erhalten.
Agnern hat eine Zusammenfassung geschrieben:
(http://www.agner.org/optimize/blog/read.php?i=25)http://www.agner.org/optimize/blog/read.php?i=25
http://www.agner.org/optimize/blog/read.php?i=49
Guten Rutsch
Alex
Agnern hat eine Zusammenfassung geschrieben:
http://www.agner.org/optimize/blog/read.php?i=25
Guten Rutsch
Alex
Obs diese es Wert ist?
Wenn ich schon lese was er im 2. Block, 2. Absatz schreibt:1998, AMD was the first to introduce Single-Instruction-Multiple-Data (SIMD) instructions in their so-called 3DNow instruction set. Intel never supported the 3DNow instructions. Instead, they introduced the SSE instruction set a few years later.
Das ist Käse! Intel hatte als erster SIMD mittels MMX realisiert (http://en.wikipedia.org/wiki/SIMD) und zwar 1996 (http://en.wikipedia.org/wiki/MMX_%28instruction_set%29).
Obs diese es Wert ist?
Wenn ich schon lese was er im 2. Block, 2. Absatz schreibt:
Das ist Käse! Intel hatte als erster SIMD mittels MMX realisiert (http://en.wikipedia.org/wiki/SIMD) und zwar 1996 (http://en.wikipedia.org/wiki/MMX_%28instruction_set%29).
Richtig, aber da Du das gerade zitierst, fällt mir auf, dass ich den falschen Link gepostet habe :]
Das ist der Link zum alten Blog Eintrag, der schon früher genannt wurde, aktuell - und den ich eigentlich meinte - ist das hier:
http://www.agner.org/optimize/blog/read.php?i=49
Hat also anscheinend keinen interessiert, dass er MMX unterschlagen hat :(
ciao
Alex
Es liest sich ja auch besser, wenn es AMD ist, wer als erster etwas einführt und Intel es kopiert, als umgekehrt.
Es liest sich ja auch besser, wenn es AMD ist, wer als erster etwas einführt und Intel es kopiert, als umgekehrt. Hm, achso Du meinst er hats absichtlich getan ... Möglich - aber da gäbs sicherlich auch noch effektivere Sachen.
Abgesehen davon, die Kommentare sind interessant, iXBT patch ein paar Programme für einen kommenden Artikel:
We're at iXBT.com are doing this right now and will publish test results soon (Intel & AMD CPU's, „Intel“—>„AMD“ & „AMD“—>„Intel“ string change, 4-6 runs per app, 50-100 app's). If it is OK to use your findings (with all the copyrights), we will :)
Bin mir zwar nicht sicher ob das reicht, die (extended) familiy bits gibts ja auch noch, aber warten wirs mal ab, was kommt :)
ciao
Alex
kann es sein, dass er 3dnow bzw. sse als erste richtige Befehlssatzerweiterung ansieht, weil sie im Gegensatz zu mmx nicht auf Integer beschränkt sind, sondern auch Gleitkommazahlenberechnungen beschleunigen?
Wird mmx heute überhaupt noch genutzt?
MfG @
Wo steht geschrieben das SIMD sich (Single Instruction Multiple Data) auf Fließkommazahlen beschränkt? MMX wird heute deshlab nicht mehr verwendet, weil es durch SSE "ersetzt" wurde bzw. über die SSE-Unit abgewickelt wird. Macht also keinen Sinn eine Anwendung per MMX zu beschleunigen, wenn man das gleiche auch mit SSE könnte.
.
EDIT :
.
Hm, achso Du meinst er hats absichtlich getan ... Möglich - aber da gäbs sicherlich auch noch effektivere Sachen.
Abgesehen davon, die Kommentare sind interessant, iXBT patch ein paar Programme für einen kommenden Artikel:
Bin mir zwar nicht sicher ob das reicht, die (extended) familiy bits gibts ja auch noch, aber warten wirs mal ab, was kommt :)
ciao
Alex
Absicht möchte ich ihm jetzt nicht unterstellen, war nur eine Feststellung meinerseits. Wer außer AMDler liest so einen Blog schon? (und diese stört es bestimmt nicht) *buck*
Interessant wäre es zu wissen um welche Apps es sich da handelt. (und nein ich habe den blog [noch] nicht weiter gelesen)
Absicht möchte ich ihm jetzt nicht unterstellen, war nur eine Feststellung meinerseits. Wer außer AMDler liest so einen Blog schon? (und diese stört es bestimmt nicht) *buck*
Haha, ja da mag in der Tat was dran sein :)
Interessant wäre es zu wissen um welche Apps es sich da handelt. (und nein ich habe den blog [noch] nicht weiter gelesen)
Na das müssen die xbt Leute noch festlegen, aber ich denke schon, dass sie eine gute Badbreite haben werden.
ciao
Alex
Da bin ich gespannt darauf, weil je nach Wahl und Ergebnisse, lassen sich Rückschlüssen auf die Verbreitung des ICC schließen. (das interessanteste mMn)
Wo steht geschrieben das SIMD sich (Single Instruction Multiple Data) auf Fließkommazahlen beschränkt? MMX wird heute deshlab nicht mehr verwendet, weil es durch SSE "ersetzt" wurde bzw. über die SSE-Unit abgewickelt wird. Macht also keinen Sinn eine Anwendung per MMX zu beschleunigen, wenn man das gleiche auch mit SSE könnte.
Wo schreibe ich was anderes?
Willst du mich immer absichtlich falsch verstehen, oder wie muss man das verstehen?
SSE deckt Integer und Gleitkommazahlen ab und hebt einige Beschränkungen von MMX die die Register (Größe, Umschalten) betrafen auf. MMX und mmx2 waren doch mehr ne fummelei die nie wirklich Bedeutung erlangt hat. Deswegen die Frage, ob Experten vielleicht wirklich erst 3dnow und SSE als die ersten wirklichen Befehlssatzerweiterung ansehen.
Aber darauf werde ich von dir sowieso entweder keine oder nur ne blöde Antwort bekommen.
MfG @
Wo schreibe ich was anderes? SIMD != SIMD = Käse
Willst du mich immer absichtlich falsch verstehen, oder wie muss man das verstehen?
Tue ich das wirklich? Oder täuschst du dich nur?
SSE deckt Integer und Gleitkommazahlen ab und hebt einige Beschränkungen von MMX die die Register (Größe, Umschalten) betrafen auf. MMX und mmx2 waren doch mehr ne fummelei die nie wirklich Bedeutung erlangt hat. Deswegen die Frage, ob Experten vielleicht wirklich erst 3dnow und SSE als die ersten wirklichen Befehlssatzerweiterung ansehen.
Reden wir von Befehlssatzerweiterungen, welche Fließkomma beherrschen oder reden wir von SIMD wie im Blog erwähnt?
Aber darauf werde ich von dir sowieso entweder keine oder nur ne blöde Antwort bekommen.
MfG @
Warum müssen wir persönlich/beleidigend werden? :(
Ich kann mir aber auch vorstellen, dass es dem Schreiberling um Float-SIMDs ging.
MMX hat damals sicher was gebracht...zu Zeiten als auch noch jede Aufruestung selbst fuer Office was gebracht hat...aber heute?
Ich kann mir aber auch vorstellen, dass es dem Schreiberling um Float-SIMDs ging.
Möglich, aber solange er es nicht hinschreibt, bleibt es falsch. Keiner kann hier Gedanken lesen ;-)
Ist aber jetzt auch egal, die kleine Stelle sollte man nicht überbewerten. Fehler passieren.
Wer mag kann dem guten Agner im relevanten Blog Post am Ende eine Mitteilung reinschreiben, keine Registrierung benötigt.
Er wird es dann sicherlich ändern oder einfach komplett löschen.
ciao
Alex
Wer einen VIA Nano hat, kann jetzt mit den CPU IDs spielen, Agner hat ein kleines Utility geschrieben:
I have made a program that can manipulate the CPUID vendor string, family and model number on VIA Nano processors. You can download it from http://www.agner.org/optimize/cpuidfake.zip. It works only on VIA, not on AMD or Intel processors. Unfortunately, it is much more difficult to do this on AMD and Intel processors because it requires virtualization.
You can use my manipulation tool to test if a program runs faster if you cange the CPUID. All you need is a computer with a VIA processor (The VIA Mini-ITX board costs less than 200$ and fits into a standard desktop cabinet).
If you find any benchmarks or other commonly used programs with evidently unfair CPU dispatching then please let me know.
http://www.amdzone.com/phpbb3/viewtopic.php?f=52&t=137269&sid=592713ad573aa2b9f6143fa1788648f7&start=50#p176208
http://www.agner.org/optimize/cpuidfake.zip
ciao
Alex
Ich glaube im Notebook-Forum hättest du da mehr Glück in Sachen Response ;D
Ich glaube im Notebook-Forum hättest du da mehr Glück in Sachen Response ;D
Agner hat jetzt ein wenig rumgespielt, und Trommelwirbel, AMD ist der Bösewicht !
Die haben notgedrungen ihre Math Bibliothek mit Intels Fortran Compiler compiliert und sich somit das Problemchen ins Huas geholt *lol*
This issue is getting more and more absurd the more I dig into it. AMD makes a function library called AMD Core Math Library (ACML) to match Intel's Math Kernel Library (MKL). I have tested a Windows version of ACML and found that some of the functions run faster when the CPU vendor ID is artificially changed to "GenuineIntel". Maybe this is not so surprising after all, since this version of ACML is compiled with Intel's Fortran compiler.
(...)
The proposed settlement with FTC requires that Intel shall reimburse its compiler customers for the cost of recompiling their code with a different compiler. While this reimbursement program probably has little more than symbolic significance, it would be funny to see Intel compensating AMD for relying on their compiler. Unfortunately, it will be difficult for AMD to find a better Fortran compiler.http://agner.org/optimize/blog/read.php?i=115#115
Jetzt noch einfacher testbar mit VM Ware:
Author: Agner Fog Date: 2010-08-16 12:24 Andrew Lofthouse wrote: If VMWare is using hardware virtualization, all cpuid instructions are intercepted and hence can be spoofed. Thanks a lot for the tip. Now everybody can test if their software has vendor-specific performance. You can get a 60 days evaluation from VMWare (https://www.vmware.com/tryvmware/). By analogy to Andrew's code, I assume that you can make an AMD processor spoof to be "GenuineIntel" with these lines:
cpuid.0.ebx="0111:0101:0110:1110:0110:0101:0100:0111"
cpuid.0.edx="0100:1001:0110:0101:0110:1110:0110:1001"
cpuid.0.ecx="0110:1100:0110:0101:0111:0100:0110:1110"
The Intel software also checks the family number, which should be set to 6:
cpuid.1.eax="0000:0000:0000:0001:0000:0110:0111:0001"
You can verify this with CPUID (http://www.cpuid.com/softwares/cpu-z/versions-history.html). Anybody who finds software with a strong performance effect of the vendor string are welcome to post the details here of mail them to me.
I am currently testing this effect in various math programs. I will post the findings here soon.http://www.agner.org/optimize/blog/read.php?i=49#118
Die Änderungen muss man in seinem .vmx File einfügen.
ciao
Aelx
hoschi_tux
19.08.2010, 12:15
Wenn AMD bei den Tests genauso aufholen kann wie der Nano dazumal gegen den Atom, dann Hallejulia ;D
Probier es gerade mal aus, sobald ich jedoch die CPU-IDs in die vmx Config File reinschreibe, gibt beim Starten der virtuellen Maschine einen BlueScreen. Entweder ich mach was falsch oder es funzt dann wohl doch nicht so einfach.
Also mit XP als VMWare bootet es schonmal, allerding haut die CPUID noch nicht so richtig hin
http://www.abload.de/img/testg4ew.jpg
Hab momentan nur ein AMD-Intel Hybrid :D. Ich probier mal weiter.
Hmm,
der Name ist aus 3 Bit Feldern zusammengebastelt, das sollten eben die 3 Teile:
cpuid.0.ebx="0111:0101:0110:1110:0110:0101:0100:0111"
cpuid.0.edx="0100:1001:0110:0101:0110:1110:0110:1001"
epuid.0.ecx="0110:1100:0110:0101:0111:0100:0110:1110"sein.
Sieht jetzt so aus, als ob das bei Dir nur für 1 Feld hinhaut. Hab einen Tippfehler in der letzten Reihe gesehen, anstatt epuid, muss das dort natürlich auch cpuid heißen ... hast Du den Tippfehler vielleicht per copy / past mitübernommen ?
Änder vielleicht auch noch die Reihenfolge, vielleicht ist das auch noch wichtig, wer weiss.
Kurz gesagt, versuchs mal so:
cpuid.0.ebx="0111:0101:0110:1110:0110:0101:0100:0111"
cpuid.0.ecx="0110:1100:0110:0101:0111:0100:0110:1110"
cpuid.0.edx="0100:1001:0110:0101:0110:1110:0110:1001"Viel Erfolg !
Edit:
Aja, setzt mal die Family number vorsichtshalber auf "F", nicht auf 6. "F" sind die P4, dass passt eh ganz gut, da die P4 auch nur maximal SSE3 hatten. Passend dazu wäre noch Model Number 4 oder 6. Da - wenn ich mich recht erinnere - auch noch Abfragen danach, die die Modelnummer nehmen, anstatt die SSE Feature Flags abzufragen .. :(
Also anstatt:
The Intel software also checks the family number, which should be set to 6:
cpuid.1.eax="0000:0000:0000:0001:0000:0110:0111:0001"
Das:
cpuid.1.eax="0000:0000:0000:0001:0000:1111:0110:0010"
Sollte dann wie bei nem Pentium4-D 9x0 aussehen:
http://xtreview.com/images/Intel%20%20D930%20Review-Intel%20D920%20Review-cpu-3010.png
Viel Erfolg
Alex
Danke Opteron. Leider startet mit diesen Zeilen XP nicht mehr ......
...
...
aber Windows 7 VMWare
http://www.abload.de/img/test2z19b.jpg
Tests mach ich später
.
EDIT :
.
Wenn Ihr einen speziellen Benchmark wollt, sagt Bescheid.
Hmm, komische Sache, wieso läuft das eine OS, aber das andere nicht .. strange.
Eventuell müßte man noch die ganzen anderen CPUID Register setzen ... wenn mir langweilig ist, schreib ich Dir morgen noch ein paar zusammen.
In der Zwischenzeit könntest Du mal den üblichen 08/15 Krams laufen lassen.
Cinebench
3dmark CPU
Sandra CPU/MEM Benches
und Itunes (das Umwandeln) würde mich auch noch interessieren, gibts da nen Bench ?
Aja und noch ne Frage, hat die VM wirklich nur einen Kern ?
ciao
Alex
Nein läuft auf 2 Kernen, CPU-Z zeigt aber nur 1 Kern / Thread an, kann jedoch den 2. Kern auswählen. Keine Ahnung warum XP nicht bootet. Schon kurios..
Hab mal fix Cinebench jeweils 3 mal als AuthenticAMD und 3 mal als GenuineIntel durchlaufen lassen. Der Unterschied ist zwar marginal aber auf jedenfall messbar.
GenuineIntel : ~5800 Punkte
AuthenticAMD : ~5400 Punkte
Weiß nicht wie es sich verhält wenn er die FamilyID von einem C2D bekommt. Teste ich dann mal. Die anderen folgen später.
EDIT:
3dMark06 CPU Bench = kein Unterschied
Nein läuft auf 2 Kernen, CPU-Z zeigt aber nur 1 Kern / Thread an, kann jedoch den 2. Kern auswählen. Keine Ahnung warum XP nicht bootet. Schon kurios..
Hab mal fix Cinebench jeweils 3 mal als AuthenticAMD und 3 mal als GenuineIntel durchlaufen lassen. Der Unterschied ist zwar marginal aber auf jedenfall messbar.
GenuineIntel : ~5800 Punkte
AuthenticAMD : ~5400 Punkte
Weiß nicht wie es sich verhält wenn er die FamilyID von einem C2D bekommt. Teste ich dann mal. Die anderen folgen später.
Könnte mit der C2D ID in die Hose gehen, falls das Programm schlecht gecoded ist und dann meint es gäb da jetzt SSSE3. Aber probiers mal aus, mehr als abstürzen kanns nicht ;)
400 Punkte Unterschied sind aber schon nicht wenig, sind ja fast 10%.
Welcher Cinebench wars genau ? 10 oder 11.5, 32 oder 64bit ?
Edit:
Ach war wohl noch das 10er, da gabs noch Punkte, aktuell ist 11.5, kannst Du auch mal gegentesten:
Downloadlink bei Maxon (http://www.maxon.net/de/downloads/downloads/cinebench/cinebench-115.html)
Thread:
http://www.planet3dnow.de/vbulletin/showthread.php?t=375939&highlight=cinebench
Beim 10er fehlte noch die K10 Optimierung, einen Unterschied hatte ich da schon fast erwartet. Jetzt bin ich mal gespannt, wies bei 11.5 ausschaut :)
Aja und was war das ? War das nun single thread, oder hat cinebench auch 2 Threads "gefunden" ?
In dem Fall könntest Du noch die single Thread Leistung testen.
Schon mal vielen Dank
Alex
.
EDIT :
.
So, hab mal noch ein bisschen gebastelt:
Versuchs erstmal damit:
cpuid.0.ebx="0111:0101:0110:1110:0110:0101:0100:0111"
cpuid.0.ecx="0110:1100:0110:0101:0111:0100:0110:1110"
cpuid.0.edx="0100:1001:0110:0101:0110:1110:0110:1001"
cpuid.1.eax="0000:0000:0000:0001:0000:1111:0110:0101"
cpuid.2.eax="0110:0111:0101:1011:0101:0000:0000:0001"
cpuid.2.ebx="0000:0000:0000:0000:0000:0000:0000:0000"
cpuid.2.ecx="0000:0000:0000:0000:0000:0000:0000:0000"
cpuid.2.edx="0000:0000:0111:1101:0111:0000:0000:0000"
Das sollten die P4 Cache Infos sein. 16kB L1 / 2MB L2 und 12kµOps
Wenn das genausogut mit Win7 klappt, dann füg noch das hinzu:
cpuid.80000002.eax="0010:0000:0010:0000:0010:0000:0010:0000"
cpuid.80000002.ebx="0000:0000:0000:0000:0000:0000:0000:0010"
cpuid.80000002.ecx="0000:0000:0000:0000:0000:0000:0000:0010"
cpuid.80000002.edx="0110:1110:0010:1001:0010:0000:0010:0010"
cpuid.80000003.eax="0010:1000:0110:1100:0110:0101:0111:0100"
cpuid.80000003.ebx="0101:0000:0010:0000:0010:1001:0101:0010"
cpuid.80000003.ecx="0110:1001:0111:0100:0110:1110:0110:0101"
cpuid.80000003.edx="0101:0010:0010:1000:0110:1101:0111:0101"
cpuid.80000004.eax="0010:0000:0011:0100:0010:0000:0010:1001"
cpuid.80000004.ebx="0010:0000:0101:0101:0101:0000:0100:0011"
cpuid.80000004.ecx="0011:0000:0011:0000:0011:0101:0011:0001"
cpuid.80000004.edx="0000:0000:0111:1010:0100:1000:0100:1101"
Das ist der Vendor String. Anstatt Phenom X6 sollte dann da stehen P4 mit 1,5 GHz.
Vielleicht verschluckt sich das XP dann auch nicht mehr so arg am Intel X6 ;-)
Bin mir aber nicht sicher ob das auch wirklich funktioniert. Versuchs einfach einmal.
Viel Erfolg und merci
Alex
Danke, werde ich dann gleich ausprobieren. Hier erstmal einen kurzen Überblick über Cinebench 10 .
Cinebench R10
Pentium 4 - Genuine Intel
32 BIt
1 CPU 3051
x CPU 5801
Speedup 1.91
64 Bit
1 CPU 3632
x CPU 6911
Speedup 1.91
Intel Core - Genuine Intel
32 Bit
1 CPU 3080
x CPU 5896
Speedup 1.92
64 Bit
1 CPU 3727
x CPU 7032
Speedup 1.89
Authentic AMD
32 Bit
1 CPU 2888
x CPU 5418
Speedup 1.88x
64 Bit
1 CPU 3641
x CPU 7055
Speedup 1.92
--------------------------------------------------------------------------
Interessant, dass bei 32 Bit der Pentium 4 Fake 7% gut macht aber bei 64 Bit sogar leicht verliert.
Cinebench R11.5
Pentium 4 - Genuine Intel
32 Bit - 1.82
64 Bit - 1.95
Intel Core - Genuine Intel
32 Bit - 1.83
64 Bit - 1.97
Authentic AMD
32 Bit - 1.78
64 Bit - 1.95
----------------------------------------------------------------------------------
PCMark05
Intel Core - GenuineIntel
9003
K10 - Authentic AMD
8116
xbitlabs haben jetzt Ihren Artikel zum VIA Nano @Intel Inside auch auf englisch online:
http://ixbtlabs.com/articles3/cpu/via-nano-cpuid-fake-p1.html
Das Problem scheint endlich mit der neuen ICC Version 12.0 behoben zu sein:
Mit den neuen Compiler-Versionen 12.0 sind laut Reinders auch unter Windows die Intel-Compiler klar performanter als der beste verfügbare Compiler-Mix, als da sind Microsoft Visual Studio 2010 und PGI 10.6. Lag der ältere 11.1-Compiler bei SPECint_base2006 noch mit 7 Prozent knapp hinter MSVC und PGI zurück, so zog Version 12.0 mit 10 Prozent Vorsprung vorbei. Noch prägnanter sieht es bei dem Gleitkomma-Benchmark SPECfp_base2006 aus: Version 11.1 hängt mit 24 Prozent und Version 12.0 gar mit 42 Prozent die anderen Windows-Compiler klar ab.
AVX wird auch unterstützt werden:
Sobald die Spezifikationen veröffentlicht und Testsysteme verfügbar sind, will Intel AVX für Bulldozer einpflegen, wobei sich die Intel-Compiler vermutlich auf die kompatiblen Befehle beschränken werden. http://www.heise.de/ct/artikel/Prozessorgefluester-1229930.html
Edit:
Verdammt, zu früh gefreut:
A new Intel C++ compiler version 12 has now been released as part of the new "Intel Parallel Composer 2011". The CPU dispatching methods are unchanged from version 11. Apparently, all that has come out of the legal battles over CPU dispatching is a notice on Intel's website that the compiler does not optimize equally for non-Intel microprocessors (see link).
The main difference between version 11 and version 12 of the compiler is that the latter has more features for splitting the code into parallel threads in order to take advantage of multi-core processors. I have not tested how these features work on non-Intel processors.
http://www.agner.org/optimize/blog/read.php?i=49#127
Da scheint jetzt also "nur" die Autoparallelisierung zu laufen.
ciao
Alex
vBulletin® v3.8.7, Copyright ©2000-2012, vBulletin Solutions, Inc.