AMD wird benachteiligt! Manipulierte Intel-Compiler & gefälschte Benchmarks

[Opteron]

Dann soll er halt zwei Versionen beifügen, einmal für Intel mit dem Intel Compiler und einmal für AMD mit nem freien Compiler inkl. Optimierungen für die CPU.

Siehe oben, sowas kostet Zeit, Aufwand, Geld, Arbeitsstunden, extra Support, das leistet sich freiwillig keine Softwarefirma.

Was kann Intel dafür, das sich keiner gefunden hat nen Compiler zu entwickeln, der sowohl das beste aus AMD und Intel CPUs raus holt...

Nichts, aber künstliches Ausbremsen ist halt als Monopolist nicht gerade ungefährlich ... das werden sie allerspätestens bemerkt haben, nachdem sie die FTC Forderung gelesen haben ^^

 

[KlausW]

Wie gesgt normal können sie fats gar nix dabei normal würde sich das FTC auch gar nit drumm kümmern aber da Intel nunmal ein quasi Monopolist ist gelten für ihn egsonderte regeln und das nicht nur bei CPUs so.
Auch Oligopole wie zb Strom und Benzin haben extra Regeln, und da funtzt es ähnlich gut wie bisher bei CPUs ^^^*duck*

 

[fdsonne]

Siehe oben, sowas kostet Zeit, Aufwand, Geld, Arbeitsstunden, extra Support, das leistet sich freiwillig keine Softwarefirma.

Aber Intel muss es leisten? Bzw. Intel muss diese Zeit/Geld/Arbeit in Sachen stecken, die andere CPUs können?

Im Grunde könnte Intel doch sogar ihren Compiler gänzlich von der Konkurenz abkabseln, sprich only Intel Support bieten.


Aber mal was anderes, wie sieht es mit dem MS Compiler aus?
Ich denke mal im Linux/Unix Bereich brauchen wir nicht groß suchen, da kommt ja überdurchschnittlich häufig die freie Version zum Einsatz.
Aber wie schauts mit MS aus? Fabriziert MS ähnliche Unterscheidungen bei den CPUs?

 

[KlausW]

Nein können sie nicht wie schon x mal gesgat wegen ihrem quasi monopol


gleich wie Microsoft Windoof nit mit Mediaplayer und ie koppeln darf apple und linux aber schon

 

[HardlineAMD]

Da gabs doch diesen Streit zwischen Intel und MS:
http://www.gamestar.de/hardware/news/prozessoren/2310922/microsoft.html

 

[[TLR]Snoopy]

1999 hat es angefangen. Auf Druck von Intel haben Asus, Gigabyte und MSI die Slot A Boards für den Athlon zurückgehalten. Seit 1999 hat AMD Probleme seine Produkte auf dem Markt zu bringen, weil unter anderem Madia/Saturn/Dell keine AMD Produkte verkaufen. Dell zwar jetzt schon in ganz kleinen Dosen aber... lächerlich.

Intel wurde schon mehrfach verurteilt und wird gerade wieder angeklagt von der FTC.
Natürlich denkt man sofort das bei einer so unschuldigen Firma wie Intel das mit dem Compiler absolut nichts damit zu tun um andere zu benachteiligen.

 

[fdsonne]

Nichts, aber künstliches Ausbremsen ist halt als Monopolist nicht gerade ungefährlich ... das werden sie allerspätestens bemerkt haben, nachdem sie die FTC Forderung gelesen haben ^^

Das mit dem künstlich ausbremsen ist aber wie oben schon erwähnt ne Ermessensfrage. Vor allem, da Intel ja nicht garantiert, das nicht Intel CPUs auch vollen Featureumfang genießen können. Man bremst also nicht künstlich, sondern gibt nicht den vollen Speed frei.

Aber ich denke mal bei dem Punkt scheiden sich die Geister...

Bei Monopolstellungen zeigten sich für mich aber oft auch Dinge, die eigenltich total unverständlich aus Verbrauchersicht sind. Auch jüngst erst MS mit der Browser Geschichte. So ein Schwachsinn das MS in ihren Betriebssystemen alternative Browser einbauen muss oder anbieten muss. Da es jedem frei steht sich einen alternativen Browser zu installieren. Wenn er das nicht macht, ist er doch selbst schuld.
Aber gut, vllt hab ich hier eine etwas zu eingeschränkte Sicht.

 

[KlausW]

interesant höre ich von das erste mal

aber wird halt gleich totgeschwigeen von fast allen seiten wie der TLB bug beim I7 obwohl der gleich Schwer bzw nichs chwer wie bei AMD ist bzw war

 

[fdsonne]

aber wird halt gleich totgeschwigeen von fast allen seiten wie der TLB bug beim I7 obwohl der gleich Schwer bzw nichs chwer wie bei AMD ist bzw war

Das mit dem Bug ist doch auch so ne Geschichte. Im nachhinein betrachtet zeigt sich zwar, das AMD durchaus extrem Federn lassen musste durch diesen Bug. Aber andererseits betrachtet kann man auch durchaus annehmen, das der Bug ja nachweislich in extrem seltenen Fällen oder nur in bestimmten Konstellationen auftritt. Als das also die Runde gemacht ist, sprich die AMD CPUs dennoch funkten und Intel ebenso mit dem Bug ankam wussten alle Bescheid und waren vorbereitet bzw. konnten sich denken, das derartiges ebenso weniger schlimm ist.

Der AMD Anhänger sieht natürlich gleich wieder ein Totschweigen bei Intel bzw. deutlich zu hohes Rumrühren bei AMD. Andererseits könnte es aber auch einfach nur damit zusammen hängen, das mittlerweile jeder der, sich darüber informiert hat, weis dass der Bug einfach mal sogut wie gar nicht auftritt und die Geschichte bei Intel deshalb nicht die große Welle machte...

Das zeigte sich aber auch in anderen Bereichen, der der als erstes ankommt, muss erstmal einstecken. Siehe Nebelbug in Source Games mit dem R600 und dann ne ganze Zeit später auch bei NV Karten. Ersteres war extrem in den Medien, letzteres eher selten bis gar nicht.

 

[DerGoldeneMesia]

Dann soll er halt zwei Versionen beifügen, einmal für Intel mit dem Intel Compiler und einmal für AMD mit nem freien Compiler inkl. Optimierungen für die CPU.

Was kann Intel dafür, das sich keiner gefunden hat nen Compiler zu entwickeln, der sowohl das beste aus AMD und Intel CPUs raus holt...

mit fake technologie sollte/kann man den markt nicht erhalten, daher ok, intel zahlt strafe..

 

[KlausW]

? extrem seltenen fällen? bis heute ist meines wissens nur 1 mal der versuch geglückt denf all bug ausserhlab der AMD labore nachzuweisen. AMD war damals schon zu nem grossen Teil selber Schuld, haben es ja selber gebauscht, wärend es Intel total totgeschwiegen hat. Worauf ich eigentlich eher hinauswollte war das der Intel TLB BUg damals einfach so von nem Mod geclost wurde mit dem Post nix neues. das hat sich mir halt in den Kopf gebrannt.

Und das mit dem zuerst gilt beim neuen Bug von Intel ja nicht.

 

[fdsonne]

? extrem seltenen fällen? bis heute ist meines wissens nur 1 mal der versuch geglückt denf all bug ausserhlab der AMD labore nachzuweisen. AMD war damals schon zu nem grossen Teil selber Schuld, haben es ja selber gebauscht, wärend es Intel total totgeschwiegen hat. Worauf ich eigentlich eher hinauswollte war das der Intel TLB BUg damals einfach so von nem Mod geclost wurde mit dem Post nix neues. das hat sich mir halt in den Kopf gebrannt.

Und das mit dem zuerst gilt beim neuen Bug von Intel ja nicht.

Waren da nicht auch mehr Fälle in den Medien?
Ich meine da was gelesen zu haben das in bestimmten Situationen bzw. bei bestimmten Rechenoperationen die CPU genau zu diesem Bug kam. Da gabs soweit ich mich erinnern kann auch ne Erklärung zu bzw. wie man was machen musste um den Bug hervorzurufen...

Zu der Moderationssache, da kann ich nicht viel zu sagen solche Dinge gehören hier auch nicht öffentlich besprochen.

Und zum letzten. Der User ließt doch nur TLB Bug Intel und erinnert sich, TLB Bug gabs doch bei AMD auch schon, und wurde als unbedenklich eingestuft bzw. durch Bios Updates/neue CPUs ausgemerzt. So schlimm kanns also nicht sein...

 

[Phantomias88]

Und zum letzten. Der User ließt doch nur TLB Bug Intel und erinnert sich, TLB Bug gabs doch bei AMD auch schon, und wurde als unbedenklich eingestuft bzw. durch Bios Updates/neue CPUs ausgemerzt. So schlimm kanns also nicht sein...

FYI:

TLB = Translation Lokalside Buffer = L2 cache.
War nicht unbedenklich sondern wurd von AMD ordentlich dokumentiert und durch ein neues Stepping ala B3 gefixt!

Bei sowas kann Intel sich noch eine Scheibe abschneiden bei AMD, Stichwort Errata!

Quelle

MfG & Frohe Weihnachten @ all

 

[mr.dude]

Wenn man sich mal anschaut, der Compiler bietet dennoch die Möglichkeit den Programmcode auch auf nicht Intel CPUs ausführbar zu machen. Sprich Intel hat ja im Grunde seine Pflicht (selbst das ist es ja nichtmal richtig) getan.
Man gibt dem Compiler Programmcode zu fressen und er spuckt für die CPU verständlichen Code aus.
Bei erkannter Intel CPU werden erhebliche Optimierungen eingeschaltet.

Hier greift Punkt c. Dies hat Intel bisher weder für Entwickler noch Printmedien ausreichend ersichtlich gemacht. Und diese Pflicht haben sie. Schliesslich verdienen sie an ihrem Compiler Geld. Ein Reifenhersteller in der Formel 1 kann einem Team auch nicht einfach nur Trockenreifen fürs Wochenende mitgeben und sich dann jeglicher Verantwortung entziehen, wenn es regnet und das Team, was Geld für die Reifen bezahlt hat, keinen Fuss auf den Boden bekommt bzw gleich einparken kann.

 

[Mondrial]

Waren da nicht auch mehr Fälle in den Medien?
Ich meine da was gelesen zu haben das in bestimmten Situationen bzw. bei bestimmten Rechenoperationen die CPU genau zu diesem Bug kam. Da gabs soweit ich mich erinnern kann auch ne Erklärung zu bzw. wie man was machen musste um den Bug hervorzurufen...

Es gab weder mehrere Fälle in den Medien, noch eine Erklärung wie man diesen Bug hervorrufen kann......Der Bug wurde von AMD ordnungsgemäß dokumentiert und beseitigt. Aufgebauscht wurde er von den Medien, was bei Intels Bugs aktuell nicht passiert(z.B. Sockelburn...).

 

[Opteron]

Das mit dem künstlich ausbremsen ist aber wie oben schon erwähnt ne Ermessensfrage. Vor allem, da Intel ja nicht garantiert, das nicht Intel CPUs auch vollen Featureumfang genießen können. Man bremst also nicht künstlich, sondern gibt nicht den vollen Speed frei.

Aber ich denke mal bei dem Punkt scheiden sich die Geister...

Naja ist doch egal wies heißt, Ausbremsen, "nicht volle Speed", nennen wirs einfach Benachteiligung. Sowas darf sich halt ein Monopolist nicht erlauben.

Bei Monopolstellungen zeigten sich für mich aber oft auch Dinge, die eigenltich total unverständlich aus Verbrauchersicht sind. Auch jüngst erst MS mit der Browser Geschichte. So ein Schwachsinn das MS in ihren Betriebssystemen alternative Browser einbauen muss oder anbieten muss. Da es jedem frei steht sich einen alternativen Browser zu installieren. Wenn er das nicht macht, ist er doch selbst schuld.
Aber gut, vllt hab ich hier eine etwas zu eingeschränkte Sicht.

Jo auf den ersten Blick erscheint es widersinnig, aber langfristig hat der Kunde nichts von nem Monopol. So musst Du das sehen. Gäbe es z.B. keine anderen Browser / Mediaplayer, käme MS sicherlich plötzlich auf die Idee dafür Geld zu verlangen - nachdem die billig Konkurrenzen erledigt sind.

Schau Dir z.B: Transmeta an, was hat intel die Firma fertig gemacht, "viel zu langsam", "lächerliche Rechenleistung", "die Leute wollen keine Stromsparchips" irgendwo stand auch mal, das hinter den Kulissen Einiges ablief ... jetzt, ein paar Jahre später, gibts dann plötzlich sowas wie den Atom ...

Intel hat von der Rest Transmeta Firma letztes Jahr die Stromspartechniken lizensiert - nachdem ein Gericht die Transmeta Patente anerkannte - blöderweise war Transmeta in der Zwischenzeit durch die quasi illegalen intel Konkurrenzprodukte insolvent --- doll ...

ciao

Alex

 

[Chemiker494]

Von Intel zu verlangen, den eigens entwickelten Compiler auch für Konkurrenzprodukte zu optimieren, dünkt mich etwas vermessen. Auch die Entwickler von Anwendungssoftware dürften - selbst ohne Bestechungsgelder von Intel - kaum so programmieren, dass Core2 Prozessoren möglichst durch den Flaschenhals FSB gebremst werden, nur damit AMD Prozzis besser dastehen.

Das ist natürlich Pech für AMD, aber wenn sie jetzt aber auch noch mir einem eigenen Compiler antreten würden, wäre das Chaos wohl noch perfekter. Die Verschwörungstheorien würde es ebenfalls keinen Abbruch erleben.

Allerdings habe ich ein Problem, wenn solche Programme in Reviews als "unabhängige Benchmarks" präsentiert werden. Nach Möglichkeit sollte man in einem CPU Review auf einseitig optimierte Software verzichten, oder wenigstens einen Disclaimer anbringen.

 

[fdsonne]

Jo auf den ersten Blick erscheint es widersinnig, aber langfristig hat der Kunde nichts von nem Monopol. So musst Du das sehen. Gäbe es z.B. keine anderen Browser / Mediaplayer, käme MS sicherlich plötzlich auf die Idee dafür Geld zu verlangen - nachdem die billig Konkurrenzen erledigt sind.

Neja aus Verbrauchersicht sehe ich das eher so, das der jenige, der vor der Entscheidung steht und keine Ahnung hat, einfach irgendwas installiert.
Im Grunde ists ihm egal, wenn er wirklich nen anderen Browser will, kann er auch zusetzlich was anderes installieren. Die Auflage, das man den IE gänzlich aus dem System schmeißen kann, finde ich aber ganz OK.

Auch als Firmenkunden Sicht, speziell bei Microsoft Umgebungen ist es idR so, das Microsoft gehostete Internet/Intranetseiten nur vollen Funktionsumfang mit Microsoft Produkten bieten.
Versuch mal ne Sharepoint Seite mit OpenOffice und dem Firefox oder anderen Browsern zu kombinieren. Das sieht erstens idR mieß aus und zweitens geht die hälfte der nützlichen Funktionen nicht.
Oder ne Outlook Web Access Seite usw.

Gerade im Firmenumfeld wo MS als Clientbetriebssystem eingesetzt wird, kommt idR auch ne Serverlösung von MS zum Einsatz. (vllt auch kombiniert mit Linux/Unix)
Aber dennoch, dort wird idR immer der IE genommen... Mal ganz abgesehen von so ganz hübschen Sachen wie Einstellungsänderungen über Gruppenrichtlinien usw.

Ich halte das Urteil einfach mal als viel zu übertrieben. Einfach aus dem Grund, weil jeder selbst entscheiden kann ob er den IE nutzt oder nicht. Da kommt es auch nie dazu, das andere Browser vom Markt verschwinden, einfach weil der der was anderes nutzen will, nutzt auch was anderes, und der der keine Ahnung davon hat, bekommt zusätzclih noch das Problem der Entscheidungsfindung bei der Installation...

Zumahl ich mit Sicherheit davon ausgehe, das bei nem vorinstallierten Rechner sowieso der IE mit drauf ist

@Mondrial
ich meine mich wie gesagt daran zu erinnern eine Seite gefunden zu haben, die aufgezeigt hat, in welcher Warscheinlichkeit der TLB Bug auftaucht bzw. welchen Operationen der Bug zwingend folgt...


Zum Compiler nochmal, wie schauts da denn mit dem MS Compiler aus, greift dort SSE auch für andere CPUs außer Intel?

 

[HardlineAMD]

Von Intel zu verlangen, den eigens entwickelten Compiler auch für Konkurrenzprodukte zu optimieren, dünkt mich etwas vermessen.

Bevor du solche Aussagen einwirfst, solltest du vorher das Thema genauer behandeln.
Es geht nicht um Optimierungen, sondern um Deaktivierung.

 

[Opteron]

Ich halte das Urteil einfach mal als viel zu übertrieben. Einfach aus dem Grund, weil jeder selbst entscheiden kann ob er den IE nutzt oder nicht. Da kommt es auch nie dazu, das andere Browser vom Markt verschwinden, einfach weil der der was anderes nutzen will, nutzt auch was anderes, und der der keine Ahnung davon hat, bekommt zusätzclih noch das Problem der Entscheidungsfindung bei der Installation...

Alles richtig, aber münze das Argument mal auf Hardware um.
"Jeder kann selbst entscheiden, ob er sich nen Intel oder Transmeta kauft ... "
Tja Transmeta ist nicht mehr -> schlecht.

Da wollen die FTCler halt jetzt vermeiden, dass das mit AMD jetzt genauso läuft. Wenn man bedenkt das Sysmark auch so ein intel Compilat war, und das Teil bei den Behörden als Referenz für die Leistungsfähigkeit herhalten muss

Frohes Fest

Alex

 

[fdsonne]

gut da hast du natürlich recht...

 

[mr.dude]

Auch die Entwickler von Anwendungssoftware dürften - selbst ohne Bestechungsgelder von Intel - kaum so programmieren, dass Core2 Prozessoren möglichst durch den Flaschenhals FSB gebremst werden, nur damit AMD Prozzis besser dastehen.

Dass Intel gewisse Nachteile durch den FSB hat, kommt ganz automatisch. Dafür braucht kein Entwickler "optimieren".

Das ist natürlich Pech für AMD, aber wenn sie jetzt aber auch noch mir einem eigenen Compiler antreten würden

Was heisst würde? AMD hat schon länger eine eigene Compiler Suite. Nur was hat das mit dem Thema zu tun?

Zum Compiler nochmal, wie schauts da denn mit dem MS Compiler aus, greift dort SSE auch für andere CPUs außer Intel?

Zumindest ist mir nichts bekannt, dass dort Befehlssatzerweiterungen Nicht-Intel CPUs vorenthalten werden. Ob für diese CPUs dann aber auch die Macro-Ops optimiert werden, ist wieder eine andere Frage und eher zweifelhaft.

 

[fdsonne]

Zumindest ist mir nichts bekannt, dass dort Befehlssatzerweiterungen Nicht-Intel CPUs vorenthalten werden. Ob für diese CPUs dann aber auch die Macro-Ops optimiert werden, ist wieder eine andere Frage und eher zweifelhaft.

Dann verstehe ich die Aufregung ansich aber auch wieder nicht mehr so ganz... Denn es ist doch so, das der MS Compiler in der deutlichen Mehrheit aller Windows Programme zum Einsatz kommt... Und nicht der Intel Compiler...

 

[mr.dude]

Dann verstehe ich die Aufregung ansich aber auch wieder nicht mehr so ganz... Denn es ist doch so, das der MS Compiler in der deutlichen Mehrheit aller Windows Programme zum Einsatz kommt... Und nicht der Intel Compiler...

Ja, sehr wahrscheinlich ist der Microsoft Compiler der am häufigsten genutzte Compiler unter Windows. Aber das spielt doch keine Rolle. Nur weil du einen Menschen umbringst und nicht 1000, wird aus Unrecht nicht plötzlich Recht. Und gerade was Benchmarks betrifft, wird der Intel Compiler ebenfalls recht häufig eingesetzt.

 

[snoopyx]

Dann verstehe ich die Aufregung ansich aber auch wieder nicht mehr so ganz... Denn es ist doch so, das der MS Compiler in der deutlichen Mehrheit aller Windows Programme zum Einsatz kommt... Und nicht der Intel Compiler...

Aber war bzw. ist denn nicht das Problem das der Intel-Compiler in Benchmarks verwendet wird, auf deren Ergebnisse Kaufentscheidungen getroffen/Ausschreibungen erstellt werden?

 

[fdsonne]

Ja, sehr wahrscheinlich ist der Microsoft Compiler der am häufigsten genutzte Compiler unter Windows. Aber das spielt doch keine Rolle. Nur weil du einen Menschen umbringst und nicht 1000, wird aus Unrecht nicht plötzlich Recht. Und gerade was Benchmarks betrifft, wird der Intel Compiler ebenfalls recht häufig eingesetzt.

Ob Recht unter Unrecht ist doch so ne Sache...

Intel hat ja in ihrer quasi Monopolstellung einiges an Federn zu lassen, was man im normalen Firmenumfeld wohl überhaupt nicht fordern kann.

Wie gesagt, niemand würde wohl seine eigene Software auch nur ansatzweise auf Konkurenzprodukte erweitern. Das wäre wie, NV muss als Physikengine Monopolist (vorsicht, soweit ist es derzeit nicht) ihre Engine auch auf AMD Karten zugänglich machen. Oder NV muss als Monopolist im Physikbereich auch auf nicht NV GPU basierten Rechnern PhysX in vollem Umfang (unabhängig von der erzielten Leistung) freimachen...

Zum Thema Benches, bei dehnen die rein synthetischer Natur sind, stimme ich dir ganz klar zu, Dinge ala Cinebench, wo der Bench quasi 1:1 die Anwendung wiederspiegelt, sind da wieder was anderes...
Aus Programmierersicht holft man damit ja nur alles aus der mit Abstand am häufigsten vertretenen Marke herraus. Andererseits könnte man mit ner Alternative zwar mehr Kunden bedienen. Aber die Masse hätte das Nachsehen.

 

[mr.dude]

Wie gesagt, niemand würde wohl seine eigene Software auch nur ansatzweise auf Konkurenzprodukte erweitern. Das wäre wie, NV muss als Physikengine Monopolist (vorsicht, soweit ist es derzeit nicht) ihre Engine auch auf AMD Karten zugänglich machen. Oder NV muss als Monopolist im Physikbereich auch auf nicht NV GPU basierten Rechnern PhysX in vollem Umfang (unabhängig von der erzielten Leistung) freimachen...

Nein, darum geht es nicht. Um die Analogie zu nVidia herzustellen, das wäre so, als würde nVidia einen Benchmark mit PhysX beschleunigen, der die eigenen Produkte bevorteilt, aber ansonsten keine Repräsentativität für den gesamten Markt hat. Sowas ist wettbewerbswidrig. Oder zumindest die erwähnte unzureichende Informationspolitik.

Zum Thema Benches, bei dehnen die rein synthetischer Natur sind, stimme ich dir ganz klar zu, Dinge ala Cinebench, wo der Bench quasi 1:1 die Anwendung wiederspiegelt, sind da wieder was anderes...
Aus Programmierersicht holft man damit ja nur alles aus der mit Abstand am häufigsten vertretenen Marke herraus. Andererseits könnte man mit ner Alternative zwar mehr Kunden bedienen. Aber die Masse hätte das Nachsehen.

Wieso soll die Masse das Nachsehen haben? Nur weil der Compiler Befehlssatzerweiterungen oder Optimierungen auch für Nicht-Intel CPUs freischaltet, ändert sich doch am Code für Intel CPUs nichts. Niemand verlangt, dass der Intel Compiler perfekt optimierten Code für Nicht-Intel CPUs erzeugt und dabei womöglich Abstriche für die eigenen CPUs in Kauf nehmen soll. Das Nachsehen hat man nur so wie es bisher war.

Es geht einfach darum, Nicht-Intel CPUs nicht unnötigerweise auszubremsen oder falls doch, dies dann nicht totzuschweigen, um die eigene Hardware wettbewerbswidrig in ein besseres Licht zu rücken.

 

[stefanRTR]

Seit dem Intel C++ Compiler 10.1 gib es zumindest diese Flag

/QxO
Specifies that the compiler is to generate SSE3, SSE2 and SSE instructions and to optimize for the Intel® Pentium® 4 processor and Intel® Xeon® processor with SSE3. Generated code should operate on processors not made by Intel that support SSE3, SSE2 and SSE instruction sets, such as some AMD* processors. This value does not enable some optimizations enabled in the S, T, and P processor values. (IA-32 and Intel® 64 architecture only, default: off)

 

[Mondrial]

@Mondrial
ich meine mich wie gesagt daran zu erinnern eine Seite gefunden zu haben, die aufgezeigt hat, in welcher Warscheinlichkeit der TLB Bug auftaucht bzw. welchen Operationen der Bug zwingend folgt...

Du hast auch behauptet es gäbe AMD-Notebooks beim Media Markt in Dresden, der versprochene Beweis ist bis heute ausgeblieben.

Es bleibt dabei, eine solche Seite gab es nicht und unter realen Bedingungen ist dieser Bug nie aufgetreten...

 

[buyman]

Ich werfe mal folgendes in den Raum: Ein Compiler wird idr. nicht für einen Prozessortyp gemacht sondern für eine ganze Archichtektur. AMD und Intel haben ja ihr Lizenzabkommen - dh. AMD darf auch SSE usw. (ebenso wie Intel die 64bit Erweiterung nutzen durfte) in die Prozessoren einbauen.

Wenn dann Intel trotz einer möglichen Abfrage was der Prozessor kann (ebenfalls standardisiert) unterschiedlicher ("schlechterer") Code für nicht Intel-CPUs geniert wird dann kann man da von Manipulation sprechen. Das /QxO Flag ist nämlich prinzipiell unnötig wenn der Compiler gleich alles richtig machen würde. Ein Compilerhersteller der sowas machen würde wäre weg vom Fenster und hätte einige Klagen am Hals - Intel konnte sich bisher sowas erlauben