AW: [Sammelthread] AMD K15 Bulldozer - aktuell: BD laut AMD erst im 4. Quartel 2011
Ich versteh nicht, was ihr alle mit euren Updates und neuen Treibern habt
Eine CPU ist keine Grafikkarte und braucht auch keinen Treiber, wie von vielen Helden hier behauptet. Auch Softwareupdates werden wohl wenig bringen, immerhin ist die Architektur intern ja nicht grundlegend verschieden zu Intel. Nur die Anordnung der Kerne ist anders.
Dieses Microsoft Update ist wohl das einzigste was irgendwie plausibel erscheint. Laut SiSoft ist das Scheduling von W7 nicht optimal für den Bulli. Aber es ist schon fraglich, ob diese Update die immensen Unterschied im SiSoft Bench wettmachen kann. SiSoft hat auch auch geschrieben, dass sie ihr eigenes "Hard Scheduling" benutzt haben, was auch immer das heißt.
ok,da müssen wir jetzt wohl oder übel recht weit ausholen, um dieses Missverständnis zu beseitigen.
also es gibt ja bekanntlich x86(CISC) und RISC, wobei RISC für reduced instruction Set computer steht, und CISC eben für complex ...
bei risc setzt man auf sehr einfache Befehle, also eine reduzierte ISA im Vergleich zu CISC. Bei RISC ist es dadurch möglich alle Befehle fest zu verdrahten, also in Silizium zu realisieren. Bei CISC ist dies schlicht aufgrund der Vielzahl an Befehlen und auch deren teilweise komplexität nicht wirtschaftlich zu realisieren (früher wie heute theoretisch schon, aber das würde halt sehr viel platz erfordern, für befehle die teilweise fast nie benutzt werden etc. Es macht also keinen Sinn alles zu implemenitieren.)
durch die fest verdrahteten Befehle hat RISC kürzere Latenzen, einfachere decodinglogik etc.dafür muss der Compiler-(echo auch Software-) Entwickler manche Dinge über mehrere Befehle von Hand realisieren, die bei CISC mit einem
Befehl gehen würden.
Bei CISC Werden (heutige CPUs sind eine Mischung aus fest verdrahteten und Microcode Befehlen) Befehle per Microcode realisiert. Die CPU erhält also z.b. Einen x86-Befehl und decodiert diesen in Microtower, der dann auf den kleinen weniger komplexen Funktionseinheiten ausgeführt wird über mehrere Takte.
Das klingt jetzt auf den ersten Blick nicht so toll, aber man hat halt eine größere ISA UND wasnauch sehr wichtig ist, kann Fehler in den Hardware teilweise ausbügeln. Wenn z.b. Bei RISC ein Fehler drin ist im Silizium und ein Befehl einen Fehler hat, kannst du den Chip (also die ganze Serie) wegwerfen. Wenn du Microcode hast, kannst du eventuell den Microcode für den Befehl so umschreiben, das es doch funktioniert. Ist dann natürlich langsamer, aber immer noch besser, als den ganzen Chip weg zu werfen. Dies wurde sowohl von AMD und Intel auch schon benutzt, soweit ich mich richtig erinnere. Intel hatte aber mal mit ihrem FP-Bug Pech, und hatte da noch kein microcode, oder konnte es nicht beheben, und musste die Chips alle austauschen (wenn ich mich jetzt nicht fallsch erinnere).
Wie du siehst ist Microcode doch gar nicht so schlecht.
ABER CPUs haben wirklich auch so etwas wie einen "Treiber", wobei ich hier eher von Firmware sprechen würde. Von "Treiber" würde ich eher beim threadsheduler vom Os sprechen. Wie man den umgehen will ist mir jetzt aber auch nicht klar, also was die unter "hardsheduler" verstehen. Mir würde spontan nur einfallen, dass sich das Programm asoziale verhält und halt sehr viele Prozesse erzeugt und sich so praktisch die gesamte Rechenleistung ergaunert, weilmdie anderen Prozesse Gast nie dran kommen.
Ich glaub man konnte das Sheduling nicht per Flug deaktivieren, leg dafür aber nicht meine hand ins Feuer.
Ich hoffe jetzt ist die Sache klarer, wenn nicht, dann einfach fragen.
