PGI mit neuem Compiler für AMDs Quad-Core Prozessoren

Die neuen Dual-Core- und Quad-Core-Prozessoren von Intel und AMD stellen die Software-Entwickler vor völlig neue Aufgaben. Während es auf der Mainstream x86-Schiene bisher üblich war, einen Prozessor mit einem Kern vorzufinden und die gesamte Software-Landschaft der letzten 15 Jahre sich darauf ausgerichtet hat, benötigen die neuen Multi-Core Prozessoren nun plötzlich komplett andere Programmstrukturen, um überhaupt einen Nutzen aus den zusätzlichen Kernen ziehen zu können. Nicht nur Programme, selbst Betriebssysteme haben damit mitunter Probleme (wir <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1180476553">berichteten</a>).

Dies hat nicht nur andere Programmierweisen durch die Entwickler zur Folge, dafür bedarf es auch geeigneter Werkzeuge. Der Compiler-Bauer Portland Group hat daher heute <a href="http://www.planet3dnow.de/vbulletin/showthread.php?p=3279150#post3279150">angekündigt</A>, mit der Version 7.1 ihres PGI Compilers explizit die neuen AMD Opteron Quad-Core Prozessoren unterstützen zu wollen. Konkret handelt es sich dabei um die neuen K10 Barcelona CPUs, AMDs erste native 4-Kern Prozessoren, die demnächst erwartet werden. Dabei wird der Compiler nicht nur versuchen, die zahlreichen Kerne durch eine eignete Compilierung optimal zu nutzen, sondern auch die neuen Features des K10-Kerns:<ul><i>Built on AMD's revolutionary Direct Connect Architecture which improves overall system performance and efficiency by eliminating bottlenecks inherent in traditional front-side bus architectures, the Quad-Core AMD Opteron processor will also introduce several major enhancements that the PGI compilers leverage for improved compile-and-go performance: smart code selection to use the full 128-bit wide floating-point units and avoid merge dependencies; low-overhead inline parallel regions to extend efficient auto-parallelization from dual-core to quad-core; alignment of hot loops to take advantage of the expanded 32 byte code fetch window; highly-optimized bit and string library intrinsics that leverage new ABM and SSE4a instructions; instruction scheduling and selection for improved latency and bandwidth; modified software pre-fetching to complement the Level-1 data cache prefetch hardware; and memory hierarchy optimizations to reduce memory access-related conflicts between cores and to improve throughput efficiency.</i></ul>Der neue Compiler der Version 7.1 für C/C++ und Fortran soll im Herbst 2007 verfügbar sein.

Hmmmm nur blöd, dass die bisherigen Compilate langsamer waren als die mit Intel Compiler ... naja vielleicht wirds jetzt ja besser ^^
Quelle: c't Test vor ner (langen) Zeit.

ciao

Alex

Es gibt keinen Quad-Core-Compiler. Die Auto-Parallelisierung der bestehenden Compiler kann man getrost vergessen. Die kann nur primitivste Schleifen parallelsieren und ansonsten ist es einem OpenMP-Programm egal ob da nun zwei oder vier Kerne existieren; aber OpenMP ist auch nicht das Wahre weil man damit nicht an die Performance von händischer Parallelisierung rankommt weil die grobkörniger ist und weniger Abhängigkeiten hat.
Letztlich bestehen die Besserungen dieses neuen Compilers sicher in der Unterstützung der neuen K10-Instruktionen und -Laufzeiten (d.h. der Optimierer geht anders vor auch wenn er die selben Instruktionen verwendet).

naja, Intels TBB liefert dann doch schon ordendliche Ergebnisse bei praktisch keinem Mehraufwand. Die Entwicklung wird da in den nächsten Jahren noch weitergehen.

Mit der Optimierung auf K10 Befehle kann man sicher ein paar Prozent rauskitzeln, Intel macht das ja auch vor (da macht AMD auch einen riesen fehler, die Lücke zwischen C2D und K8 wäre wohl ein gutes Stück kleiner wenn man selbst optimierte Compiler anbieten würde).

Mr T schrieb:

da macht AMD auch einen riesen fehler, die Lücke zwischen C2D und K8 wäre wohl ein gutes Stück kleiner wenn man selbst optimierte Compiler anbieten würde

Zum Vergrößern anklicken....

Es würde schon reichen wenn amd ordentlich bei der gcc mitarbeiten würde.
Wer würde dann noch nach einem icc krähen.
Doku würde auch schon helfen.

lg
__tom

tomturbo schrieb:

Es würde schon reichen wenn amd ordentlich bei der gcc mitarbeiten würde.
Wer würde dann noch nach einem icc krähen.
Doku würde auch schon helfen.

lg
__tom

Zum Vergrößern anklicken....

das ist richtig...

aber Imhell gibt richtig viel Geld für seine Compiler raus, und daran wird GCC niemals rankommen, vermurte ich mal...

mfg
Sir Ulli

Sir Ulli schrieb:

das ist richtig...

aber Imhell gibt richtig viel Geld für seine Compiler raus, und daran wird GCC niemals rankommen, vermurte ich mal...

mfg
Sir Ulli

Zum Vergrößern anklicken....

Richtig, AMD ist ja öfter mal in finanziell angespannter Lage, da wird es natürlich schwer solche langfristigen "sunk costs" den Aktionären schmackhaft zu machen. Gerade aber in der Top-Phase mit dem A64 hätte man das ruhig angehen können...könnte Managementfehler sein!

RavenTS schrieb:

Richtig, AMD ist ja öfter mal in finanziell angespannter Lage, da wird es natürlich schwer solche langfristigen "sunk costs" den Aktionären schmackhaft zu machen. Gerade aber in der Top-Phase mit dem A64 hätte man das ruhig angehen können...könnte Managementfehler sein!

Zum Vergrößern anklicken....

Das wäre witzlos. Compiler-Optimierung braucht Zeit, viel Zeit. Das kann man nicht mal eben auf eine Top-Phase beschränken. Insbesondere wäre da die Frage, wo AMD anfangen sollte. Quasi bei Null, komplett neu geschrieben? Würde erst Recht viel zu viel Zeit erfordern. Ein paar Entwickler bei gcc mit rein setzen? Auch keine so gute Idee. Wenn sie nicht einigermaßen konform mit dem Mainline-Tree bleiben, pflegen sie recht bald ihren eigenen Compiler. Andernfalls sind sie recht stark vom restlichen Development-Team abhängig. Dann müssen sie sich bei der Entwicklung sehr nach deren Interessen richten, und können nicht wild eigene Optimierungen einbauen. Bremst auch wieder. Egal, wie man es dreht, eine Topphase reicht dafür nicht aus.

PuckPoltergeist schrieb:

Das wäre witzlos. Compiler-Optimierung braucht Zeit, viel Zeit. Das kann man nicht mal eben auf eine Top-Phase beschränken. Insbesondere wäre da die Frage, wo AMD anfangen sollte. Quasi bei Null, komplett neu geschrieben? Würde erst Recht viel zu viel Zeit erfordern. Ein paar Entwickler bei gcc mit rein setzen? Auch keine so gute Idee. Wenn sie nicht einigermaßen konform mit dem Mainline-Tree bleiben, pflegen sie recht bald ihren eigenen Compiler. Andernfalls sind sie recht stark vom restlichen Development-Team abhängig. Dann müssen sie sich bei der Entwicklung sehr nach deren Interessen richten, und können nicht wild eigene Optimierungen einbauen. Bremst auch wieder. Egal, wie man es dreht, eine Topphase reicht dafür nicht aus.

Zum Vergrößern anklicken....

Klar das es nicht reicht, aber da hätte man den Aktionären diese Ausgaben vielleicht besser klarmachen können, als beispielsweise jetzt. Aber soviel Ausgaben sollten das doch eh nicht sein, wenn man dafür mal paar Leute abstellt.?! (aber eben sunk costs, da weiß man net ob da groß was "brauchbares" rausgeholt werden kann)

RavenTS schrieb:

Klar das es nicht reicht, aber da hätte man den Aktionären diese Ausgaben vielleicht besser klarmachen können, als beispielsweise jetzt. Aber soviel Ausgaben sollten das doch eh nicht sein, wenn man dafür mal paar Leute abstellt.?! (aber eben sunk costs, da weiß man net ob da groß was "brauchbares" rausgeholt werden kann)

Zum Vergrößern anklicken....

Soviel ich mal gehört hab (vor längerem) unterstützt(e) AMD den erwähnten PGI Compiler mit Manpower .. nur leider eben nicht gerade mit überragendem Erfolg ...

Geheimtipp bleibt wohl immernoch der Pathscale Compiler:
http://www.pathscale.com/

Angeblich ist der auch "gcc kompatible", d.h. Kompatibel zur "gcc-toolchain" .. also wohl doch nicht 100% zum Code
ciao

Alex

Die Jungs von der Portland Group sind von Anfang an mit dem K8 dabei gewesen ... da ist diese Ankündigung sozusagen obligatorisch und von daher keine Sensation.

Abgesehen davon gibt es auch Compiler von Sun, die ebenso für SPARC, als auch für x86 (Linux, Solaris) Code für x86-64 zusammenstellen ... und das ist sogar kostenlos in Sun Studio 12 enthalten, wenn auch dann ohne Support.

MFG Bobo(2007)

Bobo_Oberon schrieb:

Abgesehen davon gibt es auch Compiler von Sun, die ebenso für SPARC, als auch für x86 (Linux, Solaris) Code für x86-64 zusammenstellen ... und das ist sogar kostenlos in Sun Studio 12 enthalten, wenn auch dann ohne Support.

Zum Vergrößern anklicken....

Ja aber zum ersten mal in der vor kurzen herausgekommenen Version 12 gibt es auch compiler für x86 bzw x86-64.

Wobei man beim Sun Studio immer aufpassen muss was man auch tatsächlich kompilieren kann. Denn da siehts nicht so rosig aus.

Performancemäßig ist er ja zweifellos gut bzw. hat einen guten Ruf, zumindest unter SPARC.

Ich beispielsweise konnte samba nicht mit den sun studio übersetzen und musste den gcc verwenden. Ohne support ist das halt hart.

lg
__tom