Immer noch: Intel Compiler benachteiligt AMD CPUs

@Twodee

Eins muß man Dir absolut lassen - Du bist unheimlich zäh, wenn Du eine Meinung hast *lol* :P
 
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 :]
 
Zuletzt bearbeitet:
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:

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
 
Zuletzt bearbeitet:
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 ;))
 
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
 
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:
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 MS Compiler immer besser :)
Nicht mit einem Mercedes ( Intel ). :w_grins:
 
Zurück
Oben Unten