Alles rund um Compiler und Softwareentwicklung

Ah, der 4.9.0 versteckt sich bei personal builds ...
Muss man auch erstmal drauf kommen.

@x264 - Klar, Wunder werden da keine bei rauskommen, aber vielleicht passiert ja doch was messbares, wenn man es auf den Vishera compiliert.
Deswegen kam ich ja auch auf die Idee mit Yeppp, weil x264 schon so ausgereizt ist, das da vielleicht eine schnellere Mathe *.lib was bringt.
Natürlich nur wenn entsprechende Routinen auch aufgerufen werden. Müsst man mal die Devs fragen.
 
Schön das Beispiel mit ICC und GCC am Anfang. Auch wenn ich nicht daran glaube müsste man auch mal auf einer Intel-Kiste testen ob GCC mit Lame nicht schneller ist vielleicht liegt der Code dem ICC einfach nicht.

Die Diskussion ging begann ja anhand der Benchmark Situation los und man muss dann eigentlich auch immer den Gegenbeweis führen und dann entscheiden wann welcher Compiler besser ist für die entsprechende Architektur.
Das ganze wird dann vermutlich recht aufwändig aber hätte die Möglichkeit zumindest in Ansätzen eine "faire" Vergleichsbasis zu bieten.
Dazu kommt dann noch wie Praxisrelevant der einzelne Test aber irgendwas muss ja auch der Leser machen und sei es nur denken^^;-).
 
Weil ich da etwas im Hinterkopf hatte, dass wir hier schon mal spezielle Bulldozer Kompilate hatten und ich ziemlich lange danach gesucht habe, verlinke ich das hier mal: http://www.planet3dnow.de/vbulletin...r-Infothread?p=4620672&viewfull=1#post4620672
Zugehörig dazu: http://www.phoronix.com/scan.php?page=article&item=amd_fx4100_gcc&num=2

Woran ich mich auch noch glaube zu erinnern ist, dass auch mal bei einem Test, ich vermute es war auf Computerbase, eine extra kompilierte Version verwendet wurde, um sie gegen eine Standardversion antreten zu lassen. Das konnte ich aber bisher nicht finden. Kann sich da zufällig jemand erinnern und hat einen Link zur Hand?

LG
 
So, ich habe x264 für K10 und Piledriver mit MinGW 4.9 übersetzt. Allerdings ohne externe Bibliotheken. Ist mir im Moment zu viel Aufwand. Beim Eingangsmaterial ist man also auf YUV beschränkt. Für Testzwecke sollte das aber reichen.

x264_mingw_4.9.0_x86_64_amdfam10
x264_mingw_4.9.0_x86_64_bdver2

Ein kurzer Test brachte erwartungsgemäss keine nennenswerte Performanceunterschiede im Vergleich zu den Binaries bei VideoLAN.


Interessant ist allerdings x265. Hiervon gibt es Builds unterschiedlicher Compiler, zB mit MinGW oder mit MSC / ICC. Hier brachte ein kurzer Test immerhin messbare Unterschiede von ~10% mehr Performance mit MinGW.

GCC (MinGW)


Microsoft Compiler


Intel Compiler
 
Ich will nicht schon wieder die "Spaßbremse" sein, aber du hast beim GCC eine andere HEVC Version, 1.1+35 zu 1.1+45.
Keine Ahnung, ob das was ausmacht, du solltest aber lieber noch mal einen anderen MS und ICC-Builds testen, gibt es ja auch in den verlinkten Binaries.
 
Das sollte aber maximal ungünstiger für den MinGW Build sein, weil der ja mit älterer Version daherkommt. Ich hatte vorher auch mit Version 1.1+46 getestet, welche man hier finden kann. Da waren die Ergebnisse sogar minimal besser. Allerdings nutzen die eine deutlich ältere MinGW Version. Daher für mich nicht so wirklich interessant. Ich denke die Unterschiede zwischen 1.1+35 und 1.1+45 sind quasi vernachlässigbar bzw legt 1.1+45 eher noch etwas an Geschwindigkeit zu.
 
Rein logisch sollte die ältere Version eigentlich für AMD schlechter sein, da idr. weniger optimiert. Ich will dich ja nur vor der "du bevorzugst AMD"-Fraktion warnen und es wäre halt zum Vergleichen besser.
 
Und um es nochmal klar zu machen, zu Cinebench wurde nun schon genügend gesagt. Es ist bewiesen, dass hier der Intel Compiler verwendet wird. Wer das nicht wahrhaben will, sollte mal seine Scheuklappen nachjustieren. Und wie auch mehrfach gezeigt wurde, kann der Intel und Microsoft Compiler häufig langsameren Code für AMD erzeugen als Compiler die besseren Support für AMD mitbringen.

Aber schon lustig, wie die Intel Fraktion immer dieses oder jenes behauptet, aber rein gar nichts in diesem Thread an Nachweisen dazu erbringt. Auf der anderen Seite werden Fakten dargelegt und es wird trotzdem weggeredet. Einfach nur armselig.

Ausserdem sei auch nochmal ausdrücklich darauf hingewiesen, dass dies kein AMD vs Intel Thread ist. Hier soll es um sachliche Erkenntnisse zur Softwareoptimierung gehen. Erkenntnisresistente Störenfriede sollten sich eine andere Spielwiese suchen.
 
gruffi, Du darfst aber auch nicht von vornherein jedes Programm verdammen, welches mit dem ICC compiliert wurde. Irgendein Compiler muss es ja sein. Die allermeisten (nahe oder gleich 100%) der Programme, die der normale Windows-User benutzt, sind mit MSxx kompiliert. Und das ist gut so (Kompatibilität unter Windows)! Mit Benchmarks (oder wissenschaftlichen Anwendungen) reden wir über absolute Sonderfälle, die der Normal-User eh nicht kennt. Das Intel (oder jede andere Firma auch) für seine eigenen Produkte optimiert; na was für´n Ding! Ich als alter AMD-Fan sage mal, da hat AMD seit jeher gewaltig gepennt. Ein eigener, mit den eigenen Produkten wachsender, die eigenden Vorzüge zeigender Compiler wäre goldwert gewesen. Und sei es "nur" für Demos oder eben Benchmarks; das könnte Marketing im besten Sinne sein. Und bitte kein Gegenargument wie mangelnde Resourcen; wenn ich ein neues Produkt entwickle, teste ich ich es auch mit Software/Compiler. Und das entwickelt sich von Produkt zu Produkt. Leider nichts davon zu sehen!
Also meine Meinung: Eine Diskussion über Compiler bringt überhaupt nichts, wenn ich die Vorzüge (m)einer CPU zeigen will.
Damit komme ich zum zweiten Teil Deines Thread-Titels: Du schreibst von Software-Entwicklung; ich fände in diesem Zusammenhang besser Software-Optimierung. Hat natürlich auch mit obiges zu tun. Als kleiner Hobby-ASM-Programmierer juckt es mich jedesmal, das was A.Stiller in der c´t als Code-Schnipsel vorstellt (mit Testwerten), direkt in blanken Assembler umzusetzen (zuletzt u.a. Vielkörper-Problem, Matrix reloaded). Das optimiere ich dann (ohne Vorbehalte) für Intel (i7-4770K) und AMD (FX-8120). Wenn ich z.B. Matrix mit AVX2 (Gather!) ausführe, geht AMD (ohne AVX2, soll ja erst mit Excavator kommen) baden. Ich erwähne dies hier, weil dafür natürlich CPUID-Aufrufe im Programm nötig sind. Das ist aber keine Diskriminierung!
Wenn Du einen "echten" CPU-Vergleich möchtest, mach doch mal ein paar Vorschläge, was verglichen/getestet werden soll. Das interessiert mich!
Gruß
Helle
 
Das Intel (oder jede andere Firma auch) für seine eigenen Produkte optimiert; na was für´n Ding! Ich als alter AMD-Fan sage mal, da hat AMD seit jeher gewaltig gepennt. Ein eigener, mit den eigenen Produkten wachsender, die eigenden Vorzüge zeigender Compiler wäre goldwert gewesen. Und sei es "nur" für Demos oder eben Benchmarks; das könnte Marketing im besten Sinne sein. Und bitte kein Gegenargument wie mangelnde Resourcen; wenn ich ein neues Produkt entwickle, teste ich ich es auch mit Software/Compiler. Und das entwickelt sich von Produkt zu Produkt. Leider nichts davon zu sehen!
Gruß
Helle

Mein reden seit inzwischen Jahrzehnten!
Da setzen Sie lieber aber Millionen in den Sand für eine suboptimale/zeitlich unpassende, oder eben auch schlicht zu wenig unterstützte CPU Architektur, anstatt lieber endlich mal einen eigenen Compiler an den Start zu bringen. Das Problem wird doch mit GPGPU/HSA auch nicht kleiner, ganz im Gegenteil.
Da ist auch die Hardware schon da und das SDK? ... Der Compiler? ... Musterlösungen? ..."Leuchtturmprojekte"? ...
Obendrein lassen Sie sich die Portland Group auch noch von nVidia wegschnappen, irgendwie haben die die Vollnarkose ... :] ;D
 
@Atombossler
Was meinst du mit zu wenig Unterstützte CPU Architektur?
Soll zuerst alles mit CMT Code "verseucht" werden damit die Unterstützung genug ist?

Der Intel Compiler ist schon lange nicht mehr der schnellste: http://www.nersc.gov/users/computat...timization/compiler-comparisons/#toc-anchor-6
+60% ist schon heftig nur durch einen anderen Compiler!

Die Compilier Zeit (also bis die .exe Datei erstellt ist) ist bei den alternativen Compiler inzwischen auch schneller: http://news.dice.com/2013/11/04/speed-test-comparing-intel-c-gnu-c-and-llvm-clang-compilers/
 
Was soll der Unsinn mit dem eigenen Kompiler? - Das ist Zeit- und Resourcenverschwendung.
Wer wird damit schon etwas kompilieren wenn dadurch 90% der "anderen" Rechner langsamer wird.
Da schießt man sich ja ins eigene Knie.

Sinnvoll ist, dass man eigene libraries raus bringt und sämtliche, bestehende Kompilererzeuger unterstützt und sich dort einbringt.
Was meines Wissens nach auch getan wird.
 
@Atombossler
Was meinst du mit zu wenig Unterstützte CPU Architektur?
Soll zuerst alles mit CMT Code "verseucht" werden damit die Unterstützung genug ist?

Der Intel Compiler ist schon lange nicht mehr der schnellste: http://www.nersc.gov/users/computat...timization/compiler-comparisons/#toc-anchor-6
+60% ist schon heftig nur durch einen anderen Compiler!

Die Compilier Zeit (also bis die .exe Datei erstellt ist) ist bei den alternativen Compiler inzwischen auch schneller: http://news.dice.com/2013/11/04/speed-test-comparing-intel-c-gnu-c-and-llvm-clang-compilers/

Die AMDler haben oft gute Ideen, aber kein Timing, da würden eigene Musterimplementationen nicht schaden und sei's nur, damit sich die Anderen das angucken können.

3DNow -> weg
64bit -> hat gedaaauuuuuert
multicore -> ...
cmt -> ?
HSA -> ?

uvm.

---------- Beitrag hinzugefügt um 13:31 ---------- Vorheriger Beitrag um 13:23 ----------

Was soll der Unsinn mit dem eigenen Kompiler? - Das ist Zeit- und Resourcenverschwendung.
Wer wird damit schon etwas kompilieren wenn dadurch 90% der "anderen" Rechner langsamer wird.
Da schießt man sich ja ins eigene Knie.

Ja, Stand heute, das war ja aber nicht immer so und müsste folglich auch jetzt (wenn Sie denn früh genug was gemacht hätten) nicht so sein.
Eigene Compilate von OS-Tools bereitstellen wäre z.B. Marketing, was kaum was kostet.

Sinnvoll ist, dass man eigene libraries raus bringt und sämtliche, bestehende Kompilererzeuger unterstützt und sich dort einbringt.
Was meines Wissens nach auch getan wird.

Ausreichend?

Hier, Linkgenau so was meine ich, da wäre für AMD viel gewonnen (nat. nicht monetär gesehen), aber Sie überlassen es Drittklitschen und wundern sich dann über das mässige Ergebnis.
 
Zuletzt bearbeitet:
gruffi, Du darfst aber auch nicht von vornherein jedes Programm verdammen, welches mit dem ICC compiliert wurde.
Das tue ich auch nicht. Ansonsten hätte ich wohl Cinebench nicht im Startbeitrag verlinkt. ;) Es soll darum gehen, dass die Leute dafür sensibilisiert werden, welche Auswirkungen Software auf die Performance haben kann. Zu oft werden halt irgendwelche Benchmarks in den Raum geworfen und dann wird geschrien, Prozessor X oder Y ist scheisse, weil man da nicht auf genügend Punkte kommt. So einfach ist das aber nicht. Es wäre gut, wenn man mit solchen vorschnellen Aburteilungen endlich mal aufhören würde. Der theoretisch schnellste Prozessor kommt nicht auf Touren, wenn er softwareseitig nicht richtig unterstützt wird. Es wurde oft genug gezeigt, dass bei AMD gerade mit MSC und ICC etwa 10-20% an Performance in typischen Alltagsanwendungen verlorengehen kann. Bei Spezialanwendungen kann das auch noch wesentlich mehr sein. Wobei ich da zumindest beim MSC noch Hoffnung für die Zukunft habe. Und solange niemand nachweisen kann, dass zB Cinebench mit MinGW auf AMD nicht schneller ist, was bisher keiner hier getan hat, schon gar nicht die, die immer so darauf rumreiten und ohne jegliche Nachweise stur behaupten, der ICC wäre ja sowieso immer der schnellste, sollte man solche Benchmarks eben nicht als Maszstab hochstilisieren. So wie es von einigen ja leider gerne gemacht wird. Es sagt ja niemand, dass Cinebench nichts taugt. Wer damit testen will, soll seinen Spass daran haben. Nur man kann andersrum genau so wenig sagen, dass es ein fairer und aussagekräftiger Vergleich für CPUs ist, solange das nicht nachgewiesen wurde.

Ein eigener, mit den eigenen Produkten wachsender, die eigenden Vorzüge zeigender Compiler wäre goldwert gewesen. Und sei es "nur" für Demos oder eben Benchmarks; das könnte Marketing im besten Sinne sein.
Da habe ich aber was strikt dagegen. Ich als User will jedenfalls keinen Benchmarkcompiler, der mir ausser bei Benchmarks nichts nutzt. Solche "dreckigen" Tricks sollte ein seriöses Unternehmen nicht nötig haben. AMD hat im Grunde einen guten Compiler mit dem Open64. Mal abgesehen vom für mich sehr wichtigen C++11 Support, der leider fehlt. Letztendlich ist die Frage, was würde eine Unterstützung von Open64 für Windows bringen? Ich hätte da ehrlich gesagt wenig Hoffnung. Wichtiger für AMD ist mMn, dass man sich in die Entwicklung der Microsoft Compiler besser einbringt. Egal ob C, C++, C#, Visual Basic usw. Da sind AMDs Ressourcen besser investiert als in einen eigenen Benchmarkcompiler. Ein eigener Compiler auf dem freien Softwaremarkt lohnt sich nur, wenn man auch die entsprechende Marktmacht hat. Die hat AMD einfach (noch) nicht.

Also meine Meinung: Eine Diskussion über Compiler bringt überhaupt nichts, wenn ich die Vorzüge (m)einer CPU zeigen will.
Darum soll es in diesem Thread auch gar nicht gehen. Wenn du über Vorzüge deiner CPU gegenüber anderen sprechen willst, bist du im falschen Thread. Wenn du hingegen zeigen willst, was deine CPU mit unterschiedlichem Softwaresupport zu leisten im Stande ist, zB x87 vs SSE vs AVX, dann ist jegliches Material dazu willkommen.

Wenn Du einen "echten" CPU-Vergleich möchtest, mach doch mal ein paar Vorschläge, was verglichen/getestet werden soll. Das interessiert mich!
Nochmal, in dem Thread soll es nicht um direkte CPU Vergleiche gehen. Das gibt's an anderer Stelle schon zur Genüge. Irgendwie hast du was falsch verstanden. Es soll um die Auswirkungen von Compiler- bzw Softwareoptimierung gehen. Wenn du in diesem Kontext verschiedene CPUs gegenüberstellen willst, dann ist das natürlich okay.


Da setzen Sie lieber aber Millionen in den Sand für eine suboptimale/zeitlich unpassende, oder eben auch schlicht zu wenig unterstützte CPU Architektur, anstatt lieber endlich mal einen eigenen Compiler an den Start zu bringen.
So kann man das aber auch nicht sagen. Letztendlich muss man die Wechselwirkung sehen. Der beste Compiler nützt einem auch nichts, wenn es keine gute Hardware dazu gibt. Man braucht beides. Zeitlich unpassend in den Sand gesetzte Millionen sehe ich auch nicht. Cat und Bulldozer waren sehr wichtig für AMD. Sie kamen eigentlich zum genau richtigen Zeitpunkt. Der Unterschied ist nur, während Cat sehr gut auf einen Markt abgestimmt war, hat man gerade bei Orochi einen Mittelweg gesucht, der weder für Server noch Clients optimal war. Aber bekanntlich lernt man auch aus solchen Fehlern. Ich denke jedenfalls, dass K12 und sein x86 Abkömmling schlechter werden würden, wenn man bis heute ausschliesslich K10 im Portfolio hätte. Und ob es zu den Konsolendeals gekommen wäre, ist auch fraglich.

Das Problem wird doch mit GPGPU/HSA auch nicht kleiner, ganz im Gegenteil.
Sehe ich anders. Mit HSA hat AMD mehr Möglichkeiten, optimierend einzugreifen. Das geht dann in eine ähnliche Richtung wie die Grafiktreiber. Die Herausforderung ist halt, ein gutes SDK anzubieten und die Entwickler dazu zu bewegen, HSA auch zu nutzen. Am besten wäre aber auch da eine Zusammenarbeit mit Microsoft, zumindest was Windows betrifft.
 
Zuletzt bearbeitet:
@ Atombossler
Genau...wir wissen schließlich alle das Intel nur Singlecores hatte und auch noch nie etwas mit multi CPU Systeme etwas am Hut hatte, pfeift auf GPGPU und war üüüüberhaupt nicht an einem 64Bit Support und den damit verbundenen Support von 4GB RAM interessiert.
Des weiteren wissen wir auch das AMD mal mehr Marktanteile und Kohle als Intel hatte, wodurch sie dei Kohle und die Marktmacht für einen eigenen Compiler gehabt hätten. *suspect*
 
Die AMDler haben oft gute Ideen, aber kein Timing, da würden eigene Musterimplementationen nicht schaden und sei's nur, damit sich die Anderen das angucken können.

3DNow -> weg
64bit -> hat gedaaauuuuuert
multicore -> ...
cmt -> ?

uvm.

Und bei Intel sieht es so viel besser aus?! Also ich erinnere mich da an:

MMX -> weg
SSE1, 3 -> hat ewig gedauert
SSE4.x, AVX -> dauert immer noch
64bit (Itanium) -> weg vom Fenster
ALLE Grafikkarten Projekte von Intel -> weg, eins dann doch immerhin bei HPC überlebt
SMT-> ?
Thunderbolt -> Ob das jemals wirklich kommt? Ich glaube nicht...


Was kann denn Intel außer gute CPUs und NICs zu bauen?
HTPC - gescheitert
Smartphone - bisher gescheitert
Tablet - bisher gescheitert


Erweiterungen wie SSE & Co brauche immer (sehr) viel Zeit, das ist normal, einzig SSE2 ging relativ (gefühlt) zügig. Die 64bit Einführung war von Anfang an klar das diese länger dauert, da es viel Aufwändiger ist als ein paar SIMD-Befehlssätze. Außerdem hat es erst lange Intel Boykottiert (hat es nicht eingebaut etc.) und dann kam MS nicht wirklich in die Pushen bzw. hat mit Vista es verbockt und XP war zu erfolgreich, ergo nicht AMDs schuld. Erst der zwang mehr als 4GB RAM hat die Sache ins rollen gebracht.


@Atombossler
Was meinst du mit zu wenig Unterstützte CPU Architektur?
Soll zuerst alles mit CMT Code "verseucht" werden damit die Unterstützung genug ist?

Der Intel Compiler ist schon lange nicht mehr der schnellste: http://www.nersc.gov/users/computat...timization/compiler-comparisons/#toc-anchor-6
+60% ist schon heftig nur durch einen anderen Compiler!

Die Compilier Zeit (also bis die .exe Datei erstellt ist) ist bei den alternativen Compiler inzwischen auch schneller: http://news.dice.com/2013/11/04/speed-test-comparing-intel-c-gnu-c-and-llvm-clang-compilers/

Das ist erstens mal wieder einmal Rosinen-Pickerrei. Zweites sind die Compiler (teils) sehr spezielle. Drittens sind die 60% sogar sehr wenig.

Die ct (12/14 S.176ff) hat bspw. den MVS2013 Update 2RC mit dem Intel Composer 2013 C++ 14.0.2.176 vergleichen, in dem die eine Matrixoperation optimierten hat lassen mit verscheiden Flags. Das Ergebnis war bei statisch global das MS 0,12 GFlops und Intels 2,5 (/Qver-) bzw. 8,5GFlops (auto) erreicht haben, also rund das 20x bzw. 70x Fache!
Wenn alle Optimierungen eingeschaltet kam MS bestenfalls auf 29GFlops und Intel schafft es auf 140GFlops, damit ist immer noch ein Faktor 4,8 zwischen den beiden Compilern!

Zwischen dem schlechtesten (0,12 GFlops) und besten Ergebnis (140GFlops) liegt somit ein Faktor von über 1000!

Es wird auf Detailliert darauf eingegangen wo (noch) die schwächen des MS Compiler liegen.
 
@ bbott
Dir ist aber schon bekannt das es auch XP x64 gab, oder?
Der Knackpunkt war und ist aber eher die 4GB Hürde.
 
Die AMDler haben oft gute Ideen, aber kein Timing, da würden eigene Musterimplementationen nicht schaden und sei's nur, damit sich die Anderen das angucken können.

3DNow -> weg
64bit -> hat gedaaauuuuuert
multicore -> ...
cmt -> ?
HSA -> ?

uvm.
Das dauert natürlich alles etwas länger, Mantle ist bisher das beste Musterbeispiel, soviel aufmerksam von Developers bekam AMD noch nie!
Es sind meine ich inzwischen über 40 Spiele Entwickler Studios die sich damit beschäftigen.

Das ist erstens mal wieder einmal Rosinen-Pickerrei. Zweites sind die Compiler (teils) sehr spezielle. Drittens sind die 60% sogar sehr wenig.

Die ct (12/14 S.176ff) hat bspw. den MVS2013 Update 2RC mit dem Intel Composer 2013 C++ 14.0.2.176 vergleichen, in dem die eine Matrixoperation optimierten hat lassen mit verscheiden Flags. Das Ergebnis war bei statisch global das MS 0,12 GFlops und Intels 2,5 (/Qver-) bzw. 8,5GFlops (auto) erreicht haben, also rund das 20x bzw. 70x Fache!
Wenn alle Optimierungen eingeschaltet kam MS bestenfalls auf 29GFlops und Intel schafft es auf 140GFlops, damit ist immer noch ein Faktor 4,8 zwischen den beiden Compilern!

Zwischen dem schlechtesten (0,12 GFlops) und besten Ergebnis (140GFlops) liegt somit ein Faktor von über 1000!

Es wird auf Detailliert darauf eingegangen wo (noch) die schwächen des MS Compiler liegen.
Ja das ist Rosinen Pickerei, die ganz großen Schübe 100%+ kommen nicht durch Optimieren sondern durch den Einsatz von neuen Features (AVX2).
Intel ist nun mal soweit, das sie ihre Quell Code nur nochmal durch den Compiler laufen lassen damit neue Befehlssätze genutzt werden.
Das kann AMD noch nicht, sie sind aber auf dem richtigen Weg mit HSA.

Zumal man hier nicht AMD vs. Intel sehen sollte sondern eher Intel vs. die anderen.
 
Und bei Intel sieht es so viel besser aus?! Also ich erinnere mich da an:

MMX -> weg
SSE1, 3 -> hat ewig gedauert
SSE4.x, AVX -> dauert immer noch
64bit (Itanium) -> weg vom Fenster
ALLE Grafikkarten Projekte von Intel -> weg, eins dann doch immerhin bei HPC überlebt
SMT-> ?
Thunderbolt -> Ob das jemals wirklich kommt? Ich glaube nicht...


Was kann denn Intel außer gute CPUs und NICs zu bauen?
HTPC - gescheitert
Smartphone - bisher gescheitert
Tablet - bisher gescheitert

So ist es, ganz richtig und das trotz Marktführerschaft, eigenem Compiler zehnfacher Marktkapitalisierung und zweifelhafter Methoden.

Jetzt ziehst Du das ganze ab und Du hast AMD und warum Sie da sind, wo Sie sind.
Natürlich kann man Die nicht wirklich 1:1 vergleichen, aber AMD müsste wirklich mehr für die eigenen Produkte machen z.B. im Win Scheduler oder im MS Compiler.
Die (beste) ausgefallenste Lösung bringt ohne den Softwaresupport nichts und die Freaks, die den Genius der Produkte erkennen, sind nicht "Der Markt".

Mantle ist jetzt endlich mal ein positives Beispiel für AMD, genau sowas meine ich ja.
 
Zuletzt bearbeitet:
@ bbott
Dir ist aber schon bekannt das es auch XP x64 gab, oder?
Der Knackpunkt war und ist aber eher die 4GB Hürde.

Ist dir ist aber schon bekannt das XP x64 wohl einige Probleme hatte und von MS nicht wirklich offiziell und offensiv Vermarktet wurde... es also faktisch nur ein Testballon von MS war!
 
Ich habe es recht zeitig genutzt und abgesehen von den Problemen der ersten Grafikkarten Treiber und der Tatsache das lange Zeit kein (freier) Virenscanner erhältich war hatte ich kaum Probleme damit, obwohl ich es vor allem zum zocken nutzte.

Problematisch waren eigentlich nur systemnahe Programme die nicht dafür geschrieben wurden und natürlich die Versorgung mit Treibern....also Probleme die bei praktisch jedem neuen OS auftreten.
 
Kein Cinebench-Beweis? Alles wie gehabt also.

Beweis deiner Aussage, das Cinema 4d AMD CPU nicht benachteilig steht auch aus. Vor einiger Zeit gab es die Aussage, dass erst mit R12/13/14 optimierungen für AMD CPU eingezogen sind aber wenn man heute danach sucht findet man nix. Leider verwenden die Meissten Seiten immer noch CB10 der nachweislich Intel bevorzugt, da wirst selbst du nicht verneinen können, dass das eine Dummheit ist.
 
Zurück
Oben Unten