Wird AMD permanent gegenüber Intel in Reviews benachteiligt? Bitte Anfang lesen [2|1]

Status
Für weitere Antworten geschlossen.
Super Pi ist noch viel mehr sinnfrei in der heutigen Zeit.
x87 Code ist obsolet.
Super Pi nutzt nur einen Kern.
Der ausgegebene Super Pi Wert hat soviel Aussagekraft als die Frage nach welches Auto hast du und man dann die Farbe des Autos gesagt bekommt.

Deswegen gehört Super Pi einfach verbannt.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
superpi ist 1. schwachsinn, weil es x87 nutzt anstatt SSE und 2. x87 zufällig intels paradepisziplin ist.
Die x87 Einheit von Intel sieht kein Land gegen die von AMD, bei SuperPi schlägt aber Intels "loop detector" zu. Das Ding ist schon cool, im i7 noch weiter verbessert.

Nichtsdestoweniger ist die Aussagekraft von SuperPi natürlich nicht besonders hoch.

ciao

Alex
 
Zuletzt bearbeitet:
kommt drauf an, welche fp-einheit man nimmt.
bei AMD ist die SSE-fp einheit um einiges schneller als die alte x87.
beim core2 etc. ist das genau umgekehrt.
 
cinebench ist von intel mitarbeitern programmiert worden, also alles andere als unabhängig.

Cinebench wurde von der Firma Maxon geschrieben und besitzt den Cinema4D Renderer, bitte stoppt doch endlich mal solch sinnbefreite Parolen :rolleyes:

Genausowenig hat die Compilerdiskussion eine Grundlage wenn man bedenkt, wie oft der Intel-Compiler auch auf AMD-CPUs der schnellste verfügbare ist. In solchen Fällen ist die betreffende Diskussion vollständig obsolet.
 
Genausowenig hat die Compilerdiskussion eine Grundlage wenn man bedenkt, wie oft der Intel-Compiler auch auf AMD-CPUs der schnellste verfügbare ist. In solchen Fällen ist die betreffende Diskussion vollständig obsolet.
Jo, aber mit gepatchen Intel Binaries sind die AMDs halt dann noch schneller ...

Sollte langsam doch auch jedem bekannt sein ...
 
Und wer weiß jetzt, mit welchen Binaries der Compiler gefüttert wurde...?

Edit: Auch unter Anbetracht der überdurchschnittlichen Performance des PII in Cinebench - dort liegt er CB bei CB deutlich besser als im Gesammtrating. Das die AMDs hier mit non SSE-Code gefüttert werden, bezweifle ich doch sehr...
 
Zuletzt bearbeitet:
Und wer weiß jetzt, mit welchen Binaries der Compiler gefüttert wurde...?
Compiler der mit Binaries gefüttert wird ? Ähh .. gibts nicht ^^
Binaries = Binärcode = unter Win z.B. eine .exe Datei Deiner Wahl :)
Der SourceCode, mit dem der Compiler gefüttert wird ist natürlich der Gleiche :)
Edit: Auch unter Anbetracht der überdurchschnittlichen Performance des PII in Cinebench - dort liegt er CB bei CB deutlich besser als im Gesammtrating. Das die AMDs hier mit non SSE-Code gefüttert werden, bezweifle ich doch sehr...
Mag sein, aber in der CPU Support Liste steht er auf alle Fälle nicht, da steht er erst ab R11 -> Phenom bekommen keinen optimalen Code, ob das jetzt schlechter x87 oder schlechter SSE Code ist -> egal.

ciao

Alex
 
Zuletzt bearbeitet:
Nach meiner Google-Recherche spuckt der ICC ohne Bearbeitung keinerlei SSE-unterstützten Code für AMD-CPUs aus. Ohne jeglichen SSE-Support wäre aber keinerlei konkurrenzfähige Performance möglich - ganz im Gegenteil steht der PII im Cinebench sogar recht gut da...

Compiler der mit Binaräs gefüttert wird ? Ähh .. gibts nicht ^^

Argh, ich nehm mal an es ist klar worauf ich hinaus wollte ;) Wie gesagt, mir gehts vor allem darum das die CPU dort recht gut dasteht - die notwendigen Patches für die SSE-Unterstützung also wohl vorhanden waren.
 
Zuletzt bearbeitet:
Und mit optimalen Code könnte der Phenom II durchaus noch besser dastehen oder willst du diese Option ausschließen?
 
Und mit optimalen Code könnte der Phenom II durchaus noch besser dastehen oder willst du diese Option ausschließen?

Nein, dass schließe ich nicht aus. Ich bezweifle sie aber in einem gewissen Maß in Anbetracht der auch so schon vorhandenen Leistung - auch z.B. verglichen mit einem i7 ohne SMT.
 
Verstehe, wenn ein Phenom (II) in Relation zu Intel gut abschneidet "muss" das die Ausnahme statt die Regel sein und der Code für den Phenom (II) zwangsläufig schon (nahe) am Optimum sein... So leid es mir tut, aber das ganze klingt etwas nach arroganter Intel-Sichtweise.
 
Nach meiner Google-Recherche spuckt der ICC ohne Bearbeitung keinerlei SSE-unterstützten Code für AMD-CPUs aus. Ohne jeglichen SSE-Support wäre aber keinerlei konkurrenzfähige Performance möglich - ganz im Gegenteil steht der PII im Cinebench sogar recht gut da...
Tja da war die google Suche wohl zu kurz :)
Da gibts nen Parameter /QxO :)
Natürlich schreibt Intel in der Doku da nicht hin "Parameter für AMD Prozessoren" sondern "Parameter für non-Intel CPUs, der vielleicht funktioniert" :fresse:
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.
Wenn Du also nach ICC und AMD suchst wird es wenig Treffer geben :)

Gibt allerdings eben auch nen /QxP Switch, (SSE2/SSE3 für Intels ab Prescott); und wenn man das Binary dannn nimmt, patcht, und auf AMD laufen läßt, ist das nochmal schneller als /QxO.

Weiteres hier, S.120, 12.1 CPU dispatching in Intel compiler:
http://www.agner.org/optimize/optimizing_cpp.pdf

ciao

Alex
 
Verstehe, wenn ein Phenom (II) in Relation zu Intel gut abschneidet "muss" das die Ausnahme statt die Regel sein und der Code für den Phenom (II) zwangsläufig schon (nahe) am Optimum sein... So leid es mir tut, aber das ganze klingt etwas nach arroganter Intel-Sichtweise.


Das ist wie gesagt eine reine Vermutung zur Gegenbetrachtung, dass hier noch nennenswert Potential besteht - dafür geben andere Programme nuneinmal keinerlei Hinweise.
Würden wir jetzt über eine Situation wie SuperPI reden, wo irrealerweise selbst ein Q6600 den schnellsten Deneb schlägt, hättest du schon eher meine Zustimmung.


@Opteron:

Gibt es dazu mal (von neutraler Quelle) eine kleine Perfromance-Übersicht? Wenn ich das jetzt richtig aufgefasst habe, wäre ja der Fall default vs. "/QxO" vs. Patch interessant - gerade die Differenz zwischen letzteren Fällen.
 
Zuletzt bearbeitet:
Gibt es dazu mal (von neutraler Quelle) eine kleine Perfromance-Übersicht? Wenn ich das jetzt richtig aufgefasst habe, wäre ja der Fall default vs. "/QxO" vs. Patch interessant - gerade die Differenz zwischen letzteren Fällen.
Das hat der pdf Autor, der Professor in Kopenhagen ist gemessen. Ich denke er ist neutral genug, Ihn nervt halt nur die blöde SSE Flag Abfrage, die erst *nach* der IntelInside Abfrage kommt ..

Angefangen hat die ganze Strory damals auf acceshardware, hier mal ein Ausschnitt:
I just tried Intel C++ compiler version 10.1 with option /QxO as you suggested. It generates the following versions of code for common mathematical functions: SSE2, SSE3, SSE4.1 and non-Intel SSE2. It doesn't work on any CPU prior to SSE2. This is the only compiler option that makes it run reasonably on an AMD, but why are there two different SSE2 versions, one for Intel and one for AMD? When I hack the CPU-dispatcher and makes it believe that it is an Intel, it runs 50 - 100 % faster. This means that the Intel-SSE2 version is faster than the AMD-SSE2 version when running on an AMD processor!

There are also options that work on any processor. For example /QaxB. This options runs non-vectorized SSE2 code on Intel processors and old 8087 code on AMD processors. I measured this to be 5-10 times slower than the /QxO option on an AMD Opteron.
http://aceshardware.freeforums.org/...d-because-of-flaw-in-intel-compiler-t428.html

Kannst den Thread gerne durchlesen, ist interessant :)
Der "who" Type ist übrigens Intel-Compiler Department Mitarbeiter ^^

ciao

Alex
 
Na, dann können wir wohl fast sicher davon ausgehen das bei Cinebench alles geht, oder hält es jemand für realistisch das der Phenom dort 50-100% zu langsam ist...?
 
Undertaker_1 schrieb:
Na, dann können wir wohl fast sicher davon ausgehen das bei Cinebench alles geht, oder hält es jemand für realistisch das der Phenom dort 50-100% zu langsam ist...?
Verstehe, wenn ein Phenom (II) in Relation zu Intel gut abschneidet "muss" das die Ausnahme statt die Regel sein und der Code für den Phenom (II) zwangsläufig schon (nahe) am Optimum sein... So leid es mir tut, aber das ganze klingt etwas nach arroganter Intel-Sichtweise.
Da muss ich NOIdS beipflichten.......
 
Wozu baut den Intel extra einen vendor ID check ein? Es gibt keinen logischen Grund dies zu tun außer still und heimlich die Leistung der Konkurrenz zu drosseln.

Die vendor ID sagt erstmal rein gar nichts aus bezüglich welchen Code die CPU benutzen kann. Sie sagt nur darüber etwas aus ob "Feind" oder "Freund".

Intel kann gerne tolle und optimierte Compiler bauen und diese diversen Softwareherstellern unterjubeln, solange beim erkennen von AMD Hardware nicht plötzlich umgeschaltet wird auf Handbremse und anderer Code verwendet wird.

Niemand würde sich darüber beschweren, wenn auf Intel optimierter Code auf einem AMD System nicht oder nur schlecht laufen würde. Intel geht aber hier den Schritt weiter und bremst AMD Systeme künstlich ein indem nicht der normale Code verwendet wird sondern speziell von Intel "für AMD" geschriebener.

Von einem Entwickler der mit dem ICC arbeitet:

Now I currently happen to like ICC because it integrates well with Visual Studio and generates excellent code from SSE intrinsics (less work than writing in assembly).
However we recently renewed Premier Support and the solicited feedback will definitely contain a complaint that we, the paying customer, are getting saddled with annoying work and/or poor performance on the large base of AMD systems. Patching is possible now and less work than using two compilers or writing assembly, but why can't Intel provide a --justUseFeatureFlagsAndDisableAmdCodepath switch? (can even be off by default to save the precious benchmarks by making older or competing CPUs look worse, because there'll never be an end to that..)

Momentan müssen die Entwickler also aufwändig per Hand verhindern das auf den langsamen "AMD Codepath" umgeschaltet wird bei AMD Hardware und das obwohl sie auch noch für den ICC bezahlen.

Hier noch ein Geschwindigkeitstest ->

http://terapix.iap.fr/forum/showthread.php?tid=134

AMD Prozessor
GCC -> ICC -> 15% schneller
ICC -> ICC ohne Herstellerabfrage -> nochmal 15% schneller

Damit ist der ICC grundsätzlich der schnellere Compiler, auch bei AMD Prozessoren. Wenn man aber die von Intel für AMD künstlich eingebaute Handbremse löst, ist der "gepatchte" ICC nochmal 15% schneller.

Aber um mal wieder die Kurve zu kriegen: weiß jemand wie man herausfinden kann ob der Intel Compiler bei einem Spiel/Programm zum Einsatz gekommen ist? Denn nur das bezieht sich auf das eigentliche Thema: Hardwaretests.
 
Zuletzt bearbeitet:
Na, dann können wir wohl fast sicher davon ausgehen das bei Cinebench alles geht, oder hält es jemand für realistisch das der Phenom dort 50-100% zu langsam ist...?

Lol, ne das nicht, aber wie der Kollege schon weiter oben sagte, da gibts viele Graustufen. Die 50-100% waren auf seinen persönlichen Beispielcodeschnippsel bezogen, der war bestimmt extra ausgewählt. Man darf also davon ausgehen, dass das ein best case / worst case war.

@redfirediablo:
weiß jemand wie man herausfinden kann ob der Intel Compiler bei einem Spiel/Programm zum Einsatz gekommen ist? Denn nur das bezieht sich auf das eigentliche Thema: Hardwaretests.
Gute Frage, was man im Maschinencode auf alle Fälle sehen müßte ist die "IntelInside Abfrage". Nach der müßte man suchen können.
Schwierig wirds da nur bei großen Paketen, da ist der wirkliche Code vielleicht nicht in der z.B. Gothic.exe sondern irgendwoanders in einer unscheinbaren Datei ... Man müßte vorsichtshalber also eigentlich alles scannen.

ciao

Alex
 
Zuletzt bearbeitet:
Wozu baut den Intel extra einen vendor ID check ein? Es gibt keinen logischen Grund dies zu tun außer still und heimlich die Leistung der Konkurrenz zu drosseln.

Wie so oft, keiner hindert AMD daran einen eigenen Compiler zu basteln - für den Nutzer interessiert dies letztlich auch in keiner Hinsicht.
 
Wie so oft, keiner hindert AMD daran einen eigenen Compiler zu basteln - für den Nutzer interessiert dies letztlich auch in keiner Hinsicht.
Außer er hat eine amd cpu ^^'

Deine Kernaussage war gerade "Intel darf ihren compiler manipulieren damit die Feind-CPU's langsamer arbeiten als die eigenen, das ist gaaarnix böses."

[Dramatisierung]
Intel & Microsoft fusionieren und daraufhin funktionieren AMD CPU's plötzlich noch schlechter.... :rolleyes:
[/Dramatisierung]

Irgendwo hat alles so seine grenzen...

Wie definierst du denn bitte "Wettbewerbsverzerrung"?
 
naive denkweise bei Intels Marktstellung

Sehr richtig, welcher Entwickler würde dem ICC schon AMDs Compiler vorziehen? Da es für AMD und Kunden in absehbarer Zeit keinen Ausweg geben wird, wird es auch weiterhin "friss oder stirb" heißen, leider.

Ich meine, so eine Denkweise kann einem vernünftigen Mensch der für Vielfalt und Konkurrenz am Markt ist nur missfallen. Denn wie man es auch dreht und wendet, Faktum ist, der ICC trägt ebenfalls dazu bei die (schwächere) Konkurrenz auf Dauer verschwinden zu lassen. Wer das bestreitet, kann seine Intel-Affinität nicht verbergen.
 
Zuletzt bearbeitet:
Deine Kernaussage war gerade "Intel darf ihren compiler manipulieren damit die Feind-CPU's langsamer arbeiten als die eigenen, das ist gaaarnix böses."

Seine Kernaussage war, dass Intel ihren Compiler so optimieren darf, dass ihre eigenen CPUs damit besser arbeiten.

Und nein, das ist garnix böses, sondern wird normalerweise als was gutes angesehen!


Aber das ist wohl auch naive Denkweise.. :fresse:


Die Frage müßte hier eher sein, warum Intel für AMD optimieren sollte?
 
Die Frage müßte hier eher sein, warum Intel für AMD optimieren sollte?

wenn man die Software selbst kompilieren würde wäre es ok.
Das ist aber in der Regel nicht der Fall (da closed source).

Gängige Software gibt es meist nur in einer Windows Version und so wird diese auch vertrieben.
Da besteht garnicht die Chance das ein AMD Compiler verwendet wird.

Deswegen darf Intel als Marktbeherrender diese Situation nicht ausnutzen dürfen.
 
Warum sollte es auch Open Source sein? Warum anderer Arbeit selber kompilieren können?

(Und nein, ich will jetzt hier keine Diskussion um Open Sorce bzw. Closed Source eröffnen. Es ist nur einfach kein Argument!)

Und warum sollte gängige Software nicht mit einem AMD Compiler verwendet werden können? Im Moment steht diese Aussage nur, weil es keinen AMD Compiler gibt!


Und schon mal davon gehört, dass Firma A ihre Geheimnisse verrät, um Firma B bessere Kundenresultate zu ermöglichen?
 
Und nein, das ist garnix böses, sondern wird normalerweise als was gutes angesehen!
Jo das ist auch supertoll und das Kreide ich Intel auch nicht an, sie dürfen gerne auf Ihren Prescott, Nehalem, was auch immer optimieren. Aber dann sollen sie bitte die SSEx Optimierung davon ausnehmen.

Die /QxO Option gibts erst seit ICC 10.x, 100%ig erst aufgenommen, nach AMD einen entsprechenden Punkt in der Klageschrift veröffentlichte.

Optimal ist das jetzt immernoch nicht, aber verglichen mit früher direkt ne Offenbarung. Einigermaßen nutzbares SSE2/3 samt Code-Vektorisierung für AMD mit nem Intelcompiler anstatt x87 Code :hail:

Wenn die Performanceverbesserung mit den gepatchten /QxP Binaries von Architekturoptimierungen abhängen, dann will ich mich nicht beschweren, aber ich kann mir beim besten Willen nicht vorstellen, dass der AMD so toll mit P4 Prescott Code harmoniert ...:stupid:

ciao

Alex
 
Wenn hier noch ein Post zu dem Thema kommt dann melde ich das ganze Berlinrider mit der Folge das sämtliche posts die dieses Thema betreffen weg sind.

Ich lass mir von keinem hier meinen Thread soweit sabotieren, dass er wieder geschlossen werden muss!

Der nächste der zu diesem Thema noch etwas schreibt, zeigt offenkundig das er will das dieser Thread wieder geschlossen wird. Ich werde alles in meiner Macht stehende tun, dass dieser Threadverbot bekommt, egal wer es ist.

Haltet euch also verdammt nochmal an die Regeln!

(ihr könnt gerne euren eigenen Intel Compiler ist unfair Thread aufmachen)
 
Seine Kernaussage war, dass Intel ihren Compiler so optimieren darf, dass ihre eigenen CPUs damit besser arbeiten.

Und nein, das ist garnix böses, sondern wird normalerweise als was gutes angesehen!


Aber das ist wohl auch naive Denkweise.. :fresse:


Die Frage müßte hier eher sein, warum Intel für AMD optimieren sollte?

Man stelle sich 2 weltweite Provider, a und b, vor. a hat 80% Marktanteil und b 20%. a gehört in einigen Ländern der Welt das gesamte Leitungsnetz, in einigen nicht. b hat aber ein Leitungsnutzungslizenz von a und darf seine Daten über das Netz von a schieben. Offiziell sagt der Anbieter a, dass er keinen Unterschied macht bei dem Transfer von Datenstrom a und Datenstrom b, heimlich jedoch routet er aber b über irgendwelche günstigeren Umwege, damit a mehr Kapazität über die kritischen Pfade hat. Beim Vergleich der Netzwerkleistungen der Länder fällt ins Auge, dass in den Ländern, in denen a das Netz besitzt, b unverhältnismässig schlecht abschneidet. Ist das keine Wettbewerbsverzerrung? Mit dem Compiler ist das im Prinzip dasselbe.
AMD hat offiziell die Nutzungslizenz von Intel gekauft, um SSE in vollem Umfang implementieren und einsetzen zu können, aber Intel verweigert mit seinem Compiler dieses Recht aus puren marktstrategischen Gründen, das ist wettbewerbswidrig. Das dürfte auch nachweisbar sein, aber so weit sind die Wettbewerbsbehörden leider noch nicht. Um das nochmal zu verdeutlichen, es geht hier nicht darum, dass irgendwelche Compileranpassungen an Intel-CPUs angeprangert werden, es geht einzig und allein um die Beschneidung der Funktionalität bei Fremd-IDs. Man kann selbstredend nicht von Intel erwarten, dass sie jetzt plötzlich SSE4a, SSE5 und/oder ABM implementieren müssen. Aber man kann verdammt nochmal erwarten, dass der Compiler mit Vendor-ID-Abfrage genausoschnell ist als ohne. Der Pferdefuss für Intel ist, dass die neueren CPU-Architekturen ab PPro bzw. K6 RISC-CPUs mit CISC-IS sind. Hier ist Optimierung nicht mehr so eindeutig, als hätte man eine reine RISC oder CISC-CPU. Das bedeutet im Klartext, dass die Optimierungen, die man für die eigene CPU vornimmt, plötzlich auch auf Konkurrenz-CPUs einiges bringen könnten. Das passiert offensichtlich, wenn man GCC mit dem gepatchten ICC vergleicht. Also bremst Intel die Konkurrenz künstlich aus, um sagen zu können, dass die eigenen CPUs doch viel schneller sind mit Hinweis auf die ICC-compilierten Apps. Das ist schlicht Vorspieglung falscher Tatsachen und jetzt sagt mir noch einmal einer, das wäre ok... Würde Intel dafür einen verbraten bekommen, könnte es passieren, dass einige Intel-treue Firmen, die den ICC "aus gutem Glauben" einsetzen, um die Reputation nicht zu verlieren, plötzlich auf Portland setzen würden ;) (man darf nicht vergessen, dass es sich hier um einen professionellen Markt handelt, in dem die Entscheidungsträger von der Technik selber kaum Ahnung haben. Wenn das aber plötzlich in den Nachrichten läuft, wird man unangenehme Fragen stellen intern). Das wäre die Situation, die wirklich Gleichheit zwischen den Herstellern schaffen würde, denn dann wäre Intel gezwungen, die Abfrage rauszuschmeißen. Vielleicht passiert da sogar noch was, wenn die erste große Wettbewerbsentscheideung der EU-Kommission endlich mal draußen ist. AMD wird sich des Problems durchaus bewußt sein, und auch die Compilerproblematik zu Sprache bringen, wenn die Zeit dafür reif ist.
Man kann sich hier nicht mit einer Art "Kompatiblitätsmodus" herausreden - der ICC ist offensichtlich beschnitten, wenn eine "falsche" ID zum Tragen kommt. Beweise gibts zuhauf, sei es die c't oder andere, die sich damit beschäftigt haben.

Das nur mal als Begründung, warum ich die Testerei solcher Programme, die den ICC als Basis haben, in Reviews als höchst problematisch erachte (um die Kurve zum Thread-Thema zu kriegen :d) und da für eine Blacklist bin, solange die Vorgänge nicht abschließend geklärt sind. Würde es die Abfrage nicht geben und der ICC auch auf AMD-CPUs voll funktionsfähig sein, hätte ich absolut nichts dagegen einzuwenden, diese Programme zu testen mit dem Hinweis, dass diese mit dem ICC compiliert wurden. Solche Programme gehören dann auch ins Gesamtrating, da sie nunmal einen Teil des Gesamtmarktes darstellen. Aber so wie das im Moment abläuft, ist das Scheisse. Gäbe es eine solche Blacklist und wird diese von nur einem Reviewer eingesetzt, wären die restlichen Reviewer ebenfalls gezwungen, sich damit auseinanderzusetzen. Das könnte schon einige bewirken bevor das rechtlich geklärt ist.

@ Threadersteller, wenn schon sowas gemacht wird, muss man vorher abschließend klären, warum sowas gemacht wird ;). So führt das, wie die ganze Zeit schon, nur zu Diskussionen darüber.
 
Zuletzt bearbeitet:
Status
Für weitere Antworten geschlossen.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh