Eigenes Zitat:
Spricht für sich, dass dies der Scheduler macht.
Natürlich läuft alles auch Multithreaded bei AMD. Nur wenn AMD anfängt eigene Erweiterungen zu erstellen, werden diese nicht genutzt, da nicht im Standard. Und natürlich muss man als Entwickler immer alles schön concurrent halten, doch kann man schlecht auf AMD FX Prozzis optimieren. #ifdef mit inline Assembler in C++ mit AMD spezifischem Code? Naja viel Spass^^
Und es ist schlicht einfach falsch zu behaupten, dass Applikationen nicht Multithreaded programmiert werden und deswegen AMD langsamer ist. Sogar uralte Frameworks wie Java Swing arbeiten in mehreren Threads. Sonnst kann ja der User Code gar nicht concurrent zu den ganzen repaint Events und sonstigem laufen. Stichwort ist hier die AWT Ereigniswarteschlange. Und natürlich kann man immer weiter optimieren, die Synchronisationskosten können aber oft viel höher sein.
Gebs bitte auf... NOCHMAL LLVM. Genau Synchronisation du sprichst es an. Guck dir an wie ein Spiel aufgebaut ist, dann überleg mal wie du das machen willst. Wo wären denn deiner Meinung nach ein Beispiel wo ich unbedingt ein #ifdef im code brauche. Du hast noch nie C++ angepackt würde ich sagen niemand würde im richtigen code nen #ifdef nutzen außer es ist unausweichlich. Ich mache ganz einfach eine lib die Plattform spezifische Sachen bereitstellt und diese nutze ich dann, da habe ich kein #ifdef mehr später im code sondern rufe die Funktion aus der lib auf. Swing wird wahrscheinlich mit Locks arbeiten bei Zugriffen auf ein User Control. Im Spiel hast du aber jede menge Sachen die Kontext abhängig voneinander sind, da kannst du nicht immer locken da du so häufig locken würdest, dass es langsamer wäre.
Intel ist von der Core Performance fast überall wo es nur geht besser als Amd, dass hat nichts mehr mit irgendwelchen Erweiterungen zu tun. Beschäftige dich mal mit internen Sachen wie Branch Prediction. Intel ist Amd da Lichtjahre voraus.