Compiler für Intel Prozessoren beschleunigen neue CPUs von AMD um 22 %
Ein bisher noch unbekannter Informatikstudent mit den Fachbereichen Betriebssysteme und Embedded Systems fand heraus, dass Softwarecompiler für die 64-Bit-CPU-Technologie von Intel mit Hilfe eines kleinen Tricks auch neue AMD-CPUs beschleunigen.
Der Geschwindigkeitszuwachs lag nach Angaben des Studenten bei 22 %, was im Hinblick auf die Prozessoren eine enorm große Steigerung ist.
Bei dem Test wurden ein AMD FX51, ein Gigabyte RAM und das Betriebssystem Windows XP genutzt.
Nicht nur bei dem Konkurrenzprozessor ließ sich ein Schnelligkeitszuwachs verzeichnen, auch bei dem genutzten Intel Pentium 4 Extreme Edition mit 3.2 GHz wurden ebenfalls 22 % mehr erreicht.
Quelle: www.ochardware.de
Pech würde ich sagen! Ist AMD doch wieder schneller als INTEL.*g*
Grüße
Raimund
Moin
Compiler für Intel Prozessoren beschleunigen neue CPUs von AMD
um 22 %
Das klappt seit jeher mit dem Intel-Compiler. Das ist nicht neu.
Ein bisher noch unbekannter Informatikstudent mit den
Fachbereichen Betriebssysteme und Embedded Systems fand
heraus, dass Softwarecompiler für die 64-Bit-CPU-Technologie
von Intel mit Hilfe eines kleinen Tricks auch neue AMD-CPUs
beschleunigen.
(In dem man die 64-Bit-Befehle des Intel ausbaut… )
cu
Hallo CU,
kann ich das auch mit meinem AMD machen? Und wie geht das?
22 % schneller ist schließlich ein Wort!
Grüße
Raimund
Hallo Raimund,
kann ich das auch mit meinem AMD machen? Und wie geht das?
22 % schneller ist schließlich ein Wort!
Wenn du den Source-Code des Programms und den entsprechenden Compiler hast, dann schon.
Die angegebenen 22% beziehen sich aber auf ein bestimmtes Programm bzw. eine bestimmete Software-Lösung.
Zum besseren verständnis um was es da eigentlich geht:
-
Eine CPU besteht aus mehreren Einheiten, welche mehr oder weniger unabhängig voneinander arbeiten können. Das sind z.B. die Floatingpoint-Unit (berechnet Fliesskommazahlen) und die Integer-Unit (berechnet Ganzzahlen).
-
Nehmen wir einmal folgenden Programmausschnitt:
A = 3 * 5;
B = 3.1 * 5.0;
-
Ein normaler Compiler, ohne Optimierung macht daraus:
Befehl Operand Zeit(CPU Takte)
LadeGanzzahl „3“ 10 Laden des Wertes
AddiereGanzzahl „5“ 10 Laden des Wertes
Warten auf das Resultat 20
Speichere Resultat in „A“ 10 Speichern des Resultates
LadeFliesskomma „3.1“ 14 Laden des Wertes
AddiereFliesskomma „5.0“ 14 Laden des Wertes
Warten auf das Resultat 40
Speichere Resultat in „B“ 14 Speichern des Resultates
Total 132 Takte
-
Da aber die Flisskomma-Einheit unabhängig von der Ganzzahl-Einhaeit arbeiten kann, kann man das Ganze optimieren:
Befehl Operand Zeit(CPU Takte)
LadeFliesskomma „3.1“ 14 Laden des Wertes
AddiereFliesskomma „5.0“ 14 Laden des Wertes (in 40 Takten ist das Resultat berechnet)
LadeGanzzahl „3“ 10 Laden des Wertes
AddiereGanzzahl „5“ 10 Laden des Wertes (in 20 Takten ist das Resultat berechnet)
Warten auf FliessKommaResultat 20
Speichere Resultat in „B“ 14 Speichern des Resultates
Speichere Resultat in „A“ 10 Speichern des Resultates
Total 92 Takte
Geschwindigkeitsgewinn etwa 30%
Das ist jetzt nur ein eifaches Beispiel um das Ganze aufzuzeigen.
MfG Peter(TOO)
Moin
Hallo CU,
CU ist die Abkürzung für „see you“, eine Art englisches MfG.
kann ich das auch mit meinem AMD machen?
Klar. Ich machs (XP1700+), wenn eines meiner Programme rechenintensiv ist und sich die Umstellungen von gcc-C auf intel-C lohnt.
Und wie geht das?
Einfach 1x Recompilieren. (Evtl. den Code ein bisschen umschreiben, das was den Intel unter C versteht ist was anderes als das C von gcc. Hält sich aber meist in Grenzen)
22 % schneller ist schließlich ein Wort!
Maximale Steigerung bei mir war ±65% (ray-tracer), weil gcc (2.XX) diverse Optimierungen für Arrays und float’s nicht macht/machen wollte. Ausserdem klappte das automatische Ausrollen von Schleifen in gcc nicht. Allerdings habe ich mich nicht besonders intensiv mit den Optimier-Optionen von gcc beschäftigt.
Es ist allgemein bekannt dass ein Teil der Rechnenleistung eines System durch die Compiler verloren geht. Bei so überzüchteten und vermurksten Architeckturen wie dem x86 ist der Effekt besonders gross. Das sind doch nach dem 486 alles RISC-Prozessoren mit einem vorgebauten CISC-Emulator. Das war damals eine Notlösung und ist heute immer noch nicht besonders effektiv. Deshalb ist mein nächster Rechner auch ein ppc.
Würden die Compiler für x86 immer perfekt optimalen Machinen-Code liefern, wären die meisten Programme um 20-50% schneller, wenn nicht noch mehr. Bei Spielen würds wahrscheinlich am meisten bringen. Aber universel optimaler Machinen-Code ist nicht zu erreichen, da die Programme auf vielen verschiedenen PC’s laufen müssen und die Hersteller so ein grosses Geheimniss um die Innereien ihrer Prozessoren machen. AMD mal teilweise ausgenommen, da sind wenigstens die Grundzüge bekannt.
Deshalb ist es auch heute noch teilweise interessant Assembler zu lernen. Da fällt der Compiler einfach flach und man macht die Optimierungen selbst „von Hand“. Allerdings braucht man Jahre wenn nicht Jahrzehnte Training um Assembler richtig zu beherrschen.
cu
hallo pumpkin,
Assembler habe ich mal gelernt. Ich hage damals geflucht und geschitzt.
sollte ich heute (nach 30 Jahren) noch mal in Assembler programmieren müsen, ging´s voll daneben.
Ich hatte damals einen Kollegen, der schaffte es (kleine programme in Maschinensprache zu schreiben. Ich habe ihn bewundert!
Übrigens: alle Programme, die in Ass. geschrieben wurden (nicht PL1 odrer Cpbol, oder…) waren sehr schnell.
es gab mal eine Konkurrenz zu MS-DOS, das PTS-Dos. In der UDSSR geschrieben (in Ass.). Dageben benahm sich das MS-Dos wie aus dem Altersheim.
Grüße
Raimund
Hallo,
kann ich das auch mit meinem AMD machen? Und wie geht das?
22 % schneller ist schließlich ein Wort!
Du kannst es zwar machen, aber es wird nicht viel bringen. Um das nutzen zu können, brauchst du ja den Quelltext eines Programms. Wird dieses Programm dann mit dem Inter Compiler kompiliert, dann sie in der Regel einige Prozent schneller, weil der Compiler ziemlich gut optimiert.
Aber unter Windows z.B. nutzt da nicht viel. Der größte Teil der Software (Windows, MS-Office, Photoshop, usw usf) ist ClosedSource und daher hast du ja auch keinen Quelltext.
Unter Linux liegt zwar so ziemlich alles als OpenSource vor, aber hier bringt der Quelltext meist auch nur bedingt was. Der Intel-Compiler versteht unter „C“ meist ein bisschen was anderes, als das andere Compiler wie z.B. der GCC tun. Wenn du jetzt mit dem Intel-Compiler z.B. ein Programm wie z.B. Mozilla oder KDE übersetzen willst, dann bekommst du hunderte und tausende von Fehlermeldungen des Compilers. Du müsstest also erstmal den ganzen Code umschreiben, damit der sich überhaupt mit dem Intel-Compiler kompilieren lässt.
Da das wohl kaum einer will, macht da ganze eben auch wenig Sinn.
Und die neuen GCC-Versionen sind von der Performance auch schon mal viel besser. Gerade bei Compiler-Vergleichen wird oft ziemlich viel Dünnpfiff erzählt. Jeder Compiler optimiert nämlich anders. Meist wird aber den Compilern der gleiche Code vorgesetzt, d.h. der eine optimiert besser, weil ihm der Code einfach gelegener kommt. In einem anderen Beispiel mag das ganze auch mal genau anders herum sein.
Nichts desto trotz ist der Intel Compiler verdammt schnell, nur damit ein schnelleres System zu erzeugen ist eben so gut wie unmöglich.
mfg
deconstruct