Wird AMD permanent gegenüber Intel in Reviews benachteiligt? [4] neue Regeln beachten

[Devil Ag]

Die Aussage zeigt das du keinerlei Ahnung vom Wettbewerbsrecht hast.

Du solltest vielleicht mal ein klein wenig über dich nachdenken und mit dem Gedanken spielen, vielleicht doch nicht zu wissen wovon du sprichst und dich mal anfangen zu informieren bevor du weiter mitdiskutierst.

Solange du das nicht machst, hat es keinen Sinn weiter auf deine Posts einzugehen. Ich finde es immer wieder belustigend wie gerade im Internet viele Leute meinen mitreden zu können obwohl ihnen jegliches Hintergrundwissen fehlt.

Und wenn man dann nicht weiter weiß startet man eben mit den persönlichen Angriffen oder wie haben wir's denn hier?

Es gelten für alle die gleichen Gesetze!
Und was jetzt die Sache mit dem Compiler (der wohl gemerkt auch auf AMD CPUs meistens der bessere ist) zu tun haben soll frag ich mich schon.
Ist mir schon klar das bei Intel nicht alles Wettbewerbsrechtlich korrekt gelaufen ist (wofür sie auch verurteilt worden sind) aber das ist eine vollkommen andere Geschichte.

 

[HardlineAMD]

Es gelten für alle die gleichen Gesetze!
Und was jetzt die Sache mit dem Compiler (der wohl gemerkt auch auf AMD CPUs meistens der bessere ist) zu tun haben soll frag ich mich schon.
Ist mir schon klar das bei Intel nicht alles Wettbewerbsrechtlich korrekt gelaufen ist (wofür sie auch verurteilt worden sind) aber das ist eine vollkommen andere Geschichte.

Eine CPU ID Abfrage (mit verbundener Abschaltung der Optimierungen bei Non Intel CPUs) in den Compiler wissentlich einzubauen, damit die Konkurrenz alt ausschaut, findest du also voll in Ordnung?!

Und das Urteil der EU spielst du hier herunter, als ob ein Schuljunge im Laden einen Lutscher geklaut hat.

Wie redfirediablo schon empfohlen hat, schau dir mal das EU-Wettbewerbsrecht an.

 

[[TLR]Snoopy]

@Devil Ag

User redfirediablo hat recht, wenn er schreibt, dass

für Unternehmen der Größe von Intel, mit einer Marktbeherrschenden Stellung, nun einmal schärfere Gesetze gelten als für "normale" Unternehmen

Insofern ist alles was du schreibst sinnfrei, weil du anscheinend diesen Umstand nicht kennst, verstehst und diesen auch noch leugnest.

 

[Devil Ag]

Eine CPU ID Abfrage in den Compiler wissentlich einzubauen, damit die Konkurrenz alt ausschaut, findest du also voll in Ordnung?!

Und das Urteil der EU spielst du hier herunter, als ob ein Schuljunge im Laden einen Lutscher geklaut hat.

Wie redfirediablo schon empfohlen hat, schau dir mal das EU-Wettbewerbsrecht an.

Ich spiel nix runter -> ist nur schon ein alter Hut und wurde millionenfach durchgekaut.
Und die Jungs von Intel können in den eigenen Compiler einbauen was sie wollen. Ist immerhin IHR Werk und nicht das von jemand anderem.
Es wird niemand gezwungen diesen Compiler zu verwenden also was wollt ihr da mit dem Wettbewerbsrecht?

 

[Undertaker 1]

So siehts aus, korrekt. Noch viel extremer: Intel könnte die Unterstützung von AMD-CPUs auch komplett aus dem Compiler werfen - wäre nur ziemlich blöd, da ihn dann keiner mehr nutzen würde.

 

[mr.dude]

Ich schrieb von der Performance auf AMD UND (dicker gehts leider nicht) Intel-CPUs.

Womit wir wieder beim Thema Wunschdenken wären. Auch Intel hat keinen solchen Compiler. Ganz zu schweigen davon, dass ein und derselbe Build sowieso nicht die optimale Performance auf verschiedenen Mikroarchitekturen bieten kann.

Und bei dem Marktanteil von Windows auf AMD-CPUs (90%? 95%? 98%?) brauchst du hier mit Linux ebenfalls nicht zu kommen.

Tja, dann würde ich mal einen Blick auf professionelle Bereiche werfen. Dort ist Windows weit weniger präsent. Und ich wiederhole mich gerne nochmal, es gibt auch für Windows bessere Compiler für AMD als den von Microsoft, teilweise eben auch besser als der ICC.

Und was hindert AMD daran, derartiges samt einem eigenen Compiler anzubieten?

Zeit und Ressourcen? Hast du überhaupt eine Ahnung davon, was Microsofts Entwicklungssuite alles beinhaltet und wie lange diese mittlerweile entwickelt wird? Auch hier wieder, selbst Intel hat nicht mal ansatzweise etwas vergleichbares. Ich komme gerne wieder auf mein anfängliches Statement zurück, informiere dich doch bitte erst. Und nein, das ist wieder keine Beleidigung, sondern ein ernst gemeinter Ratschlag.

Und was jetzt die Sache mit dem Compiler (der wohl gemerkt auch auf AMD CPUs meistens der bessere ist)

Nein, ist er nicht! Glaub doch nicht auch noch den Unsinn, den andere schreiben, die keinerlei Ahnung davon haben.

Noch viel extremer: Intel könnte die Unterstützung von AMD-CPUs auch komplett aus dem Compiler werfen

Ja genau. Frei nach dem Motto, wir erzeugen keinen x86 µCode mehr. Intel hat keine explizite Unterstützung von Nicht-Intel CPUs in ihrem Compiler. Sämtliche Erzeugung des Codes ist für Intel Mikroarchitekturen ausgelegt. Insofern ist diese Aussage wieder mal unsinnig.

Und die Jungs von Intel können in den eigenen Compiler einbauen was sie wollen. Ist immerhin IHR Werk und nicht das von jemand anderem.
Es wird niemand gezwungen diesen Compiler zu verwenden also was wollt ihr da mit dem Wettbewerbsrecht?

Das habe ich doch schon geschrieben. Bitte lesen und nicht einfach ignorieren. Wenn Intel die Entwickler nicht darüber aufklärt, was der Compiler genau macht, zB dass eben für Nicht-Intel Prozessoren keine erweiterten Befehlssätze trotz vorhandener Unterstützung freigeschaltet werden, dann ist das definitiv wettbewerbswidrig.

 

[Undertaker 1]

Womit wir wieder beim Thema Wunschdenken wären. Auch Intel hat keinen solchen Compiler. Ganz zu schweigen davon, dass ein und derselbe Build sowieso nicht die optimale Performance auf verschiedenen Mikroarchitekturen bieten kann.

Wer hat behauptet, dass Intel einen solchen Compiler hat? Es ging darum, wie ein möglicher Compiler aussehen müsste der die Chance haben soll, mit dem ICC zu konkurrieren. Neben allem drumherum müsste ein solcher sowohl die AMD- als auch die Intelperformance des ICC erreichen bzw. übertreffen.

Tja, dann würde ich mal einen Blick auf professionelle Bereiche werfen. Dort ist Windows weit weniger präsent. Und ich wiederhole mich gerne nochmal, es gibt auch für Windows bessere Compiler für AMD als den von Microsoft, teilweise eben auch besser als der ICC.

Da kann ich meinen Satz ja gleich wieder kopieren und einfügen: Ich schrieb von der Performance auf AMD UND (dicker gehts leider nicht) Intel-CPUs.

Warum sollte sich ein Compiler durchsetzen, der zwar die AMD-Performance des ICC übertrifft, dafür aber bei der Leistung auf Intel-CPUs zurückliegt?

Zeit und Ressourcen? Hast du überhaupt eine Ahnung davon, was Microsofts Entwicklungssuite alles beinhaltet und wie lange diese mittlerweile entwickelt wird?

Liest du mit? Hab ich schon mehrfach vor dir geschrieben.

Und was hindert AMD daran, derartiges samt einem eigenen Compiler anzubieten? Exakt, die finanziellen Ressourcen, das habe ich schon vor dutzenden Postings geschrieben. Warum muss man dir alles 5-Mal erklären?

Ja genau. Frei nach dem Motto, wir erzeugen keinen x86 µCode mehr. Intel hat keine explizite Unterstützung von Nicht-Intel CPUs in ihrem Compiler. Sämtliche Erzeugung des Codes ist für Intel Mikroarchitekturen ausgelegt. Insofern ist diese Aussage wieder mal unsinnig.

Du hast sie nur leider nicht verstanden. Es gäbe technisch keine Hinderungsgründe, eine entsprechende Sperre einzubauen. Z.B. über einen Zwang zu SSE4 (AMD: SSE4a, inkompatibel zueinander).

 

[Opteron]

(...) Ja genau. Frei nach dem Motto, wir erzeugen keinen x86 µCode mehr. Intel hat keine explizite Unterstützung von Nicht-Intel CPUs in ihrem Compiler. Sämtliche Erzeugung des Codes ist für Intel Mikroarchitekturen ausgelegt. Insofern ist diese Aussage wieder mal unsinnig.


Das habe ich doch schon geschrieben. Bitte lesen und nicht einfach ignorieren. Wenn Intel die Entwickler nicht darüber aufklärt, was der Compiler genau macht, zB dass eben für Nicht-Intel Prozessoren keine erweiterten Befehlssätze trotz vorhandener Unterstützung freigeschaltet werden, dann ist das definitiv wettbewerbswidrig.

Doch da gibts ne explizite Erwähnung, seit der 10.1 Version gibts QxO:

/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)

http://www.intel.com/software/products/compilers/docs/cwin/release_notes.htm

Aber das alte Prescott Compilat per QxP läuft trotzdem schneller, wenn man es patcht und auf AMD lauffähig macht. Das Compiler Thema hatten wir auch schon gefühlte 5x im Thread, siehe unten.

Der Grund für QxO ist vermutlich Dein zweiter Absatz (Stichwort: Wettbewerbswidrig), AMD klagt u.a. gegen die Compiler Behandlung. Vermutlich hat Intel nun QxO als Feigenblatt eingeführt, mittlerweile nennen sie - im Gegensatz zum alten Thread - sogar AMD explizit, lustig ;-).

Weiteres im alten Thread:
http://www.hardwareluxx.de/community/showpost.php?p=11189207&postcount=133

ciao

Alex

 

[[TLR]Snoopy]

Ich sehe auch in dieser News eine Benachteiligung gegenüber AMD.
DDR3-SDRAM: Mühsam zum Mainstream
http://www.computerbase.de/news/hardware/arbeitsspeicher/2009/oktober/ddr3-sdram_muehsam_mainstream/

Meiner Meinung nach wird hier im ersten Satz ganz klar suggeriert, dass bei AMD erst 2010 DDR3 kommt.

 

[Opteron]

Na, poste den ersten Satz doch gleich:

Von Intel wird der neue Arbeitsspeicher seit geraumer Zeit bereits eingesetzt, AMD erwartet den Durchbruch hingegen erst im kommenden Jahr: die Rede ist von DDR3-SDRAM.

Ist in der Tat etwas" komisch" formuliert ... steht und fällt mit der Interpretation von "Durchbruch".

ciao

Alex

 

[Undertaker 1]

"AMD erwartet" klingt nicht danach, dass sich das ein Redakteuer selbst ausgedacht hat. Mitdenken.

 

[Stryke707]

Hat CB das geändert?
Zitat von cb:
Von Intel wird der neue Arbeitsspeicher seit geraumer Zeit bereits eingesetzt, AMD setzt seit diesem Jahr darauf, erwartet den Durchbruch aber erst im kommenden Jahr: die Rede ist von DDR3-SDRAM.

Also so finde ich klingt das völlig in Ordnung

 

[Mondrial]

Wurde nach Hinweis geändert. Da hebt sich CB in letzter Zeit von anderen Magazinen relativ deutlich ab...

 

[mr.dude]

Warum sollte sich ein Compiler durchsetzen, der zwar die AMD-Performance des ICC übertrifft, dafür aber bei der Leistung auf Intel-CPUs zurückliegt?

Und weshalb sollte das dann die Schuld von AMD sein? Hier wird argumentiert, dass man von Intel nicht verlangen kann, ihren Compiler optimal auf andere Hersteller anzupassen. Von AMD wird aber genau das verlangt? Wieder mal Doppelmoral ohne Ende. Übrigens, falls du es immer noch nicht mitbekommen hast, diese Compiler GIBT ES. PGI erzeugt zB exzellenten Code, der auch für Intel Prozessoren nicht hinter dem ICC zurückliegt.

Hab ich schon mehrfach vor dir geschrieben.

Und warum stellst du dann solche sinnfreien Fragen, wenn sie nichts zum Thema beitragen?

Es gäbe technisch keine Hinderungsgründe, eine entsprechende Sperre einzubauen. Z.B. über einen Zwang zu SSE4 (AMD: SSE4a, inkompatibel zueinander).

Die Nichtbeachtung erweiterter Befehlssätze war ja nun schon thematisiert. Und SSE4a ist nichts anderes. Wie soll man also "die Unterstützung von AMD-CPUs komplett aus dem Compiler werfen"? x86 ISA bleibt immer noch x86 ISA. Und der Basisbefehlssatz gilt für beide Hersteller gleichermassen. Klar kann man auf "AuthenticAMD" von der Runtime prüfen lassen und dann die Anwendung beenden. Aber das wäre eben genau solcher Unsinn wie deine Behauptung.

Der Grund für QxO ist vermutlich Dein zweiter Absatz (Stichwort: Wettbewerbswidrig), AMD klagt u.a. gegen die Compiler Behandlung. Vermutlich hat Intel nun QxO als Feigenblatt eingeführt, mittlerweile nennen sie - im Gegensatz zum alten Thread - sogar AMD explizit, lustig ;-).

In meiner Referenz, direkt vom Compiler, nicht mal das. Bin mir aber nicht sicher, ob das nicht schon Version 11 ist.

/Qx<codes>  generate specialized code to run exclusively on processors
    [...]
    O  Intel(R) Core(TM) processor family.  Code is expected to run properly
       on any processor that supports SSE3, SSE2 and SSE instruction sets

Ansonsten sehe ich das aber ähnlich. Mehr als ein Alibi Flag scheint das nicht zu sein.

 

[Undertaker 1]

Und weshalb sollte das dann die Schuld von AMD sein? Hier wird argumentiert, dass man von Intel nicht verlangen kann, ihren Compiler optimal auf andere Hersteller anzupassen. Von AMD wird aber genau das verlangt? Wieder mal Doppelmoral ohne Ende. Übrigens, falls du es immer noch nicht mitbekommen hast, diese Compiler GIBT ES. PGI erzeugt zB exzellenten Code, der auch für Intel Prozessoren nicht hinter dem ICC zurückliegt.

Du verstehst es leider immernoch nicht... Es geht darum, weshalb sich andere Compiler nicht durchsetzen. Solange sie nur bessere AMD-Speeds, gleichzeitig aber schlechteren Intel-Code produzieren, kann das nuneinmal nichts werden. Das wir nebenbei auch noch von brauchbarem Support und Windows als Haupteinsatzgebiet reden, werde ich jetzt nicht nocheinmal wiederholen.

Und warum stellst du dann solche sinnfreien Fragen, wenn sie nichts zum Thema beitragen?

Ich frage mich viel mehr, warum du Fakten, nachdem ich sie gebracht habe, noch 10x wiederholst und als deine Aussage verkaufen willst...

Die Nichtbeachtung erweiterter Befehlssätze war ja nun schon thematisiert. Und SSE4a ist nichts anderes. Wie soll man also "die Unterstützung von AMD-CPUs komplett aus dem Compiler werfen"? x86 ISA bleibt immer noch x86 ISA. Und der Basisbefehlssatz gilt für beide Hersteller gleichermassen. Klar kann man auf "AuthenticAMD" von der Runtime prüfen lassen und dann die Anwendung beenden.

Auch das habe ich bereits geschrieben. Eine Herstellerabfrage einzusetzen, oder wie von mir allgemeiner vorgeschlagen eine Befehlssatzerweiterung
vorausszusetzen, die keiner außer Intel selbst bietet, würde nur die Verbreitung des Compilers verhindern - daran hat man logischerweise kein Interesse. Erneut wiederholst du nur das, was ich bereits gesagt habe.


Edit: Und da ich hier offensichtlich gegen eine Betonwand rede, darfst du jetzt allein weiterspielen.

 

[mr.dude]

Du verstehst es leider immernoch nicht... Es geht darum, weshalb sich andere Compiler nicht durchsetzen. Solange sie nur bessere AMD-Speeds, gleichzeitig aber schlechteren Intel-Code produzieren, kann das nuneinmal nichts werden. Das wir nebenbei auch noch von brauchbarem Support und Windows als Haupteinsatzgebiet reden, werde ich jetzt nicht nocheinmal wiederholen.

Sry, aber du beweist leider mal wieder, dass du Null Ahnung von der Materie hast. GCC wird dir in nahezu jeder Anwendung schnelleren Code erzeugen als der Microsoft Compiler, für AMD UND Intel. Trotzdem verwenden Entwickler meistens den Microsoft Compiler. Der Performance des erzeugten Codes, bezogen auf den Compiler, wird leider immer noch relativ wenig Beachtung geschenkt. Deine Vermutungen sind einfach nichts anderes als Unwissenheit und Naivität. Ich habe damit fast täglich zu tun und bekomme ziemlich gut mit, was Leute für Probleme mit Compilern haben. Da gibt es noch ganz andere Schwerpunkte.

Ich frage mich viel mehr, warum du Fakten, nachdem ich sie gebracht habe, noch 10x wiederholst und als deine Aussage verkaufen willst...

Du warst doch derjenige, der vehement einen AMD Compiler gefordert hat. Ich habe lediglich darauf geantwortet. Wenn du selbst einsiehst, dass diese Forderung Unsinn war, warum stellst du dann überhaupt solche Fragen?

Auch das habe ich bereits geschrieben. Eine Herstellerabfrage einzusetzen, oder wie von mir allgemeiner vorgeschlagen eine Befehlssatzerweiterung
vorausszusetzen, die keiner außer Intel selbst bietet, würde nur die Verbreitung des Compilers verhindern - daran hat man logischerweise kein Interesse. Erneut wiederholst du nur das, was ich bereits gesagt habe.

Auch das beweist wieder mal nur, dass du nicht wirklich weisst, wovon du sprichst. Ich frage mich echt, wann du das endlich mal einsiehst. Schon mal daran gedacht, dass selbst Intel Prozessoren untereinander unterschiedliche Befehlssatzerweiterungen unterstützen? Damit würde sich Intel selbst ein Bein stellen. Was du hier kolportierst, ist kompletter Unsinn und absolut weltfremd.
Es gibt übrigens durchaus Anwendungen, die einen bestimmten erweiterten Befehlssatz voraussetzen. Aber das macht niemand, um die Unterstützung von AMD Prozessoren zu unterbinden.

 

[fdsonne]

Sry, aber du beweist leider mal wieder, dass du Null Ahnung von der Materie hast. GCC wird dir in nahezu jeder Anwendung schnelleren Code erzeugen als der Microsoft Compiler, für AMD UND Intel. Trotzdem verwenden Entwickler meistens den Microsoft Compiler. Der Performance des erzeugten Codes, bezogen auf den Compiler, wird leider immer noch relativ wenig Beachtung geschenkt. Deine Vermutungen sind einfach nichts anderes als Unwissenheit und Naivität. Ich habe damit fast täglich zu tun und bekomme ziemlich gut mit, was Leute für Probleme mit Compilern haben. Da gibt es noch ganz andere Schwerpunkte.

Mit dem Posting triffst du doch den Nagel auf den Kopf...

Viel wichtiger als die Diskusion, welchen Compiler wo was besser macht sollte doch die Frage sein, warum eben überwiegend der Intel/MS Compiler eingesetzt wird?

Mir als Endanwender ist es doch schnupps egal, welchen Compiler der Hersteller nimmt um die Software zu compilieren... Mich interessiert, was hinten bei rum kommt. Und wenn AMD da schlecherte Performance bringt, dann kauft man halt Intel.
Der Endanwender hat auch gar nicht die Möglichkeit (schon alleine wegen der bezahlmich-Software) hier durch einen besseren/anderen Compiler die Performance zu steigern.

 

[redfirediablo]

ich weiß, ich bin nicht ganz unschuldig dran das das Thema etwas aufgekocht ist aber:

Bitte das Thema Compiler sofort beenden da off topic!

Ihr kennt das Threadthema, also ab sofort bitte wieder NUR Reviews.

 

[mr.dude]

Mir als Endanwender ist es doch schnupps egal, welchen Compiler der Hersteller nimmt um die Software zu compilieren... Mich interessiert, was hinten bei rum kommt. Und wenn AMD da schlecherte Performance bringt, dann kauft man halt Intel.

Ja, nur wird hier von einigen impliziert, dass AMD selbst daran Schuld sei und sie ja einfach nur einen eigenen super tollen Compiler bräuchten, um das zu ändern. Aber so einfach ist das nun mal nicht. Hier gibt es ganz andere Hürden, auf die AMD wenig bis keinen Einfluss hat.

Sry, für offtopic. Also zurück zum Thema ...

 

[redfirediablo]

Betrügt Intel beim 3DMark Vantage und verstößt gegen Futuremark Richtlinien?

http://techreport.com/articles.x/17732

Letztlich erreicht die Intel IGP mit Optimierungen 2900 Punkte während ein AMD 785G nur 2160 Punkte im 3DMark Vantage erreicht.

Im Gegensatz dazu schafft Intel bei Crysis Warhead mit niedriger Auflösung 10fps ohne Optimierung und mit Optimierung 15fps, jedoch erreicht ein 785G in diesem Fall 30fps.

Somit wird auf Teufel komm raus bei Intel auf den 3DMark Vantage optimiert um in Benchmarkvergleichen sogar die IGP Konkurrenz auszustechen (auch wenn man dazu die CPU zur Hilfe nehmen muss)

Wenn es dann aber an die Anwendungen geht die durch den 3DMark Vantage abgebildet werden sollen, liegt die Intel Lösung trotz CPU Unterstützung meilenweit zurück.

In diesem Zusammenhang ist es als sehr kritisch zu sehen das gerade bei Notebooks mit IGP sehr gerne ausschließlich ein 3DMark Benchmark durchgeführt wird um die IGP Leistung zu prüfen. Effektiv führt das zu einer massiven Täuschung des Kunden über die wahre Leistung einer Intel IGP im Vergleich zu einer NV oder ATI Lösung.

 

[[TLR]Snoopy]

Ist ja krank. Betrügen lügen, anscheinend hat es Intel nötig. Haben wohl selber kein Vertrauen in ihre Produkte.

 

[HardlineAMD]

Intel versucht mal wieder, ohne das sie es nötig haben, ihre alten Schrott-IGPs besser darzustellen.


Insgesamt betrachtet wäre es doch mal ganz nett, einen Vergleich anzustellen, wie sich eine Umbenennung der .EXE Datei auf die Leistung auswirkt (nicht nur bei Intel). Ich beziehe mich vor allem auf IGPs und nicht auf MultiGPU-Systeme.

 

[DrSeltsam]

Soweit ich es verstanden habe, hat techreport.com den gleichen Test bei AMD gemacht(Seite 2 beim Test) ohne eine Abweichung festzustellen.

Ich bin ehrlich gesagt etwas sprachlos über die Dreistheit von Intel, die Berechnungen der GPU teilweise auf die CPU zu verlagern. Aber irgendwie wundern tut es mich nicht.
Ich will nicht wissen, was Intel für Tricks rauspackt, wenn sie ihre GPU veröffentlichen.

 

[y33H@]

In dem Fall ganz klar: So nicht, Intel! GPU ist GPU. Da wird nichts auf die CPU gepackt ...

 

[Opteron]

Ich bin ehrlich gesagt etwas sprachlos über die Dreistheit von Intel, die Berechnungen der GPU teilweise auf die CPU zu verlagern. Aber irgendwie wundern tut es mich nicht.
Ich will nicht wissen, was Intel für Tricks rauspackt, wenn sie ihre GPU veröffentlichen.

Also mir wärs ja egal - wenn das auch abseits von xyz MArk bei Spielen klappen würde

ciao

Alex

 

[che new]

Also mir wärs ja egal - wenn das auch abseits von xyz MArk bei Spielen klappen würde

ciao

Alex

http://www.hardwareluxx.de/index.php?option=com_content&view=article&id=13312 &catid=38&Itemid=101

Eine solche "Optimierung" verstösst gegen die von Futuremark aufgestellten Regularien. Auf Anfrage der Kollegen räumte Intel ein, dass die IGP-Treiber entsprechend programmiert wurden. Das wäre auch für mehrere Spiele (Call of Juarez, Crysis, Lost Planet: Extreme Conditions und Company of Heroes) der Fall.

So wie ich das verstehe, funktioniert das nicht nur auch bei Spielen, sondern wird bereits praktiziert.

 

[Opteron]

So wie ich das verstehe, funktioniert das nicht nur auch bei Spielen, sondern wird bereits praktiziert.

Aber läuft das Spiel dann auch wirklich schneller ? Die Game Benches sind dann doch wieder meilenweit von einem 785G entfernt.
Ausserdem wärs mir neu, dass eine CPU irgendetwas schneller könnte als eine GPU. Ok .. wenn letzere ziemlich grottig ist vielleicht, aber beim Quervergleich mit dem 785G, sollte auf alle Fälle nichts besseres herauskommen ;-)

Edit: Ah auf Seite 2 stehts ja:
http://techreport.com/articles.x/17732/2

ciao

Alex

 

[mr.dude]

Wobei da noch deutlich mehr im Argen liegt. Selbst ohne CPU Unterstützung liegt die Intel IGP in Vantage fast gleich auf mit der AMD IGP. Was jedoch in keinster Weise tatsächliche Spiele Performance widerspiegelt. Irgendwie habe ich den Verdacht, dass an Vantage generell etwas faul zu sein scheint.

 

[Phantomias88]

Moin,

wenn ihr möchtet könnte ich eine GF8200 IGP mal durch den Vantage Bench jagen!?
Mal sehen was dabei raus kommt...

Die GPU Punkte sind doch relative unabhängig von den CPU Punkten!?
(Das wurde im Vergleich zu 3DM06 endlich verbessert!)

Interessant was Intel da so macht, einmal real auf die Finger gekloppt machen sie virtuell weiter oder wie?

 

[Undertaker 1]

Wobei da noch deutlich mehr im Argen liegt. Selbst ohne CPU Unterstützung liegt die Intel IGP in Vantage fast gleich auf mit der AMD IGP. Was jedoch in keinster Weise tatsächliche Spiele Performance widerspiegelt. Irgendwie habe ich den Verdacht, dass an Vantage generell etwas faul zu sein scheint.

Das spiegelt eher die Treiberschwäche in Spielen wieder, als die grundsätzliche Schwäche der Hardware - so unbrauchbar ist die, nach theoretischen Messungen von Füllrate oder Shaderleistung, nämlich gar nicht, es hakt nur an den Treibern bei allem abseits des Mainstream. Übrigens nicht nur die Schuld des Treiberteams, auch die Spieleentwickler nehmen da recht wenig Rücksicht auf Lösungen abseits von ATI und Nvidia.

Für Spiele find ich den Ansatz übrigens sehr gut, er bringt nennenswert Leistung - in einem Bereich, wo man jedes fsp braucht - und die Gefahr, durch die zusätzliche Last ins CPU-Limit zu rutschen, ist bei einer Intel-IGP eh nicht real gegeben. Im 3DM sieht das anders aus, klarer Cheat dort... Da wird Futuremark wohl den Treiber für den ORB sperren.