App installieren
How to install the app on iOS
Follow along with the video below to see how to install our site as a web app on your home screen.
Anmerkung: This feature may not be available in some browsers.
Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden.
Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
PGI mit neuem Compiler für AMDs Quad-Core Prozessoren
- Ersteller Nero24
- Erstellt am
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.
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.
Großer Manitu
Lieutnant
- Mitglied seit
- 28.05.2007
- Beiträge
- 63
- Renomée
- 1
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).
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).
Zuletzt bearbeitet:
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).
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).
tomturbo
Technische Administration, Dinosaurier
- Mitglied seit
- 30.11.2005
- Beiträge
- 9.455
- Renomée
- 665
- Standort
- Österreich
- Aktuelle Projekte
- Universe@HOME, Asteroids@HOME
- Lieblingsprojekt
- SETI@HOME
- Meine Systeme
- Xeon E3-1245V6; Raspberry Pi 4; Ryzen 1700X; EPIC 7351
- BOINC-Statistiken
- Mein Laptop
- Microsoft Surface Pro 4
- Prozessor
- R7 5800X
- Mainboard
- Asus ROG STRIX B550-A GAMING
- Kühlung
- Alpenfön Ben Nevis Rev B
- Speicher
- 2x32GB Mushkin, D464GB 3200-22 Essentials
- Grafikprozessor
- Sapphire Radeon RX 460 2GB
- Display
- BenQ PD3220U, 31.5" 4K
- SSD
- 1x HP SSD EX950 1TB, 1x SAMSUNG SSD 830 Series 256 GB, 1x Crucial_CT256MX100SSD1
- HDD
- Toshiba X300 5TB
- Optisches Laufwerk
- Samsung Brenner
- Soundkarte
- onboard
- Gehäuse
- Fractal Design Define R4
- Netzteil
- XFX 550W
- Tastatur
- Trust ASTA mechanical
- Maus
- irgend eine silent Maus
- Betriebssystem
- Arch Linux, Windows VM
- Webbrowser
- Firefox + Chromium + Konqueror
- Internetanbindung
-
▼300
▲50
Es würde schon reichen wenn amd ordentlich bei der gcc mitarbeiten würde.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
Wer würde dann noch nach einem icc krähen.
Doku würde auch schon helfen.
lg
__tom
Sir Ulli
Grand Admiral Special
- Mitglied seit
- 06.02.2002
- Beiträge
- 14.440
- Renomée
- 202
- Standort
- Bad Oeynhausen
- Aktuelle Projekte
- Seti, Spinhenge
- Lieblingsprojekt
- Seti, Spinhenge, ich war vor Ort
- Meine Systeme
- Athlon64 X2 4.400, Imhell Quad 6.600
- Mein Laptop
- HP 530
- Prozessor
- Imhell Quad 6.600 at 3.240 8 x 405
- Mainboard
- Aus P5K Rev 2.1
- Kühlung
- Thermalright SI-128 SE Papst 120 at 1.200
- Speicher
- 2 x A-DATA 4 GB DDR2-800 Kit 4,4,4,12
- Grafikprozessor
- Asus 8.500 GT SILENT/HTP/256M
- Display
- Samsung SyncMaster 2232BW 22 Zoll TFT
- HDD
- Western Digital WD10EACS 1 TB
- Optisches Laufwerk
- Samsung SH-S203P Sata
- Soundkarte
- onboard
- Gehäuse
- CS601 mit 2extra Päpsten at 9 Volt
- Netzteil
- Fortron 350 Watt
- Betriebssystem
- Windows7 Home Premium
- Webbrowser
- Mozilla Firefox
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
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
RavenTS
Grand Admiral Special
- Mitglied seit
- 23.01.2003
- Beiträge
- 5.092
- Renomée
- 50
- Mein Laptop
- lenovo T400
- Prozessor
- Core2 Duo E7500 @ 3.5 GHz
- Mainboard
- Gigabyte D965G-DS3
- Kühlung
- Scythe Orochi
- Speicher
- 3 GByte
- Grafikprozessor
- ATi Radeon 6870
- Display
- 3x Acer 19TFT @ Eyefinity
- HDD
- Seagate MomentusXT 750GB & 500GB, Samsung HD250
- Optisches Laufwerk
- LG DVD-RW, MSI-Combo, ASUS CD-ROM
- Soundkarte
- Creative SB Audigy
- Gehäuse
- Chieftec BX, MODDED: 6 Gehäuselüfter
- Netzteil
- Be Quiet E8 400W
- Betriebssystem
- Win7 64 Pro
- Webbrowser
- Opera 12
- Verschiedenes
- Silent, alle Lüfter 5V
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
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!
PuckPoltergeist
Grand Admiral Special
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!
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.
RavenTS
Grand Admiral Special
- Mitglied seit
- 23.01.2003
- Beiträge
- 5.092
- Renomée
- 50
- Mein Laptop
- lenovo T400
- Prozessor
- Core2 Duo E7500 @ 3.5 GHz
- Mainboard
- Gigabyte D965G-DS3
- Kühlung
- Scythe Orochi
- Speicher
- 3 GByte
- Grafikprozessor
- ATi Radeon 6870
- Display
- 3x Acer 19TFT @ Eyefinity
- HDD
- Seagate MomentusXT 750GB & 500GB, Samsung HD250
- Optisches Laufwerk
- LG DVD-RW, MSI-Combo, ASUS CD-ROM
- Soundkarte
- Creative SB Audigy
- Gehäuse
- Chieftec BX, MODDED: 6 Gehäuselüfter
- Netzteil
- Be Quiet E8 400W
- Betriebssystem
- Win7 64 Pro
- Webbrowser
- Opera 12
- Verschiedenes
- Silent, alle Lüfter 5V
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.
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)
Opteron
Redaktion
☆☆☆☆☆☆
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 ...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)
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
Zuletzt bearbeitet:
Bobo_Oberon
Grand Admiral Special
- Mitglied seit
- 18.01.2007
- Beiträge
- 5.045
- Renomée
- 190
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)
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)
tomturbo
Technische Administration, Dinosaurier
- Mitglied seit
- 30.11.2005
- Beiträge
- 9.455
- Renomée
- 665
- Standort
- Österreich
- Aktuelle Projekte
- Universe@HOME, Asteroids@HOME
- Lieblingsprojekt
- SETI@HOME
- Meine Systeme
- Xeon E3-1245V6; Raspberry Pi 4; Ryzen 1700X; EPIC 7351
- BOINC-Statistiken
- Mein Laptop
- Microsoft Surface Pro 4
- Prozessor
- R7 5800X
- Mainboard
- Asus ROG STRIX B550-A GAMING
- Kühlung
- Alpenfön Ben Nevis Rev B
- Speicher
- 2x32GB Mushkin, D464GB 3200-22 Essentials
- Grafikprozessor
- Sapphire Radeon RX 460 2GB
- Display
- BenQ PD3220U, 31.5" 4K
- SSD
- 1x HP SSD EX950 1TB, 1x SAMSUNG SSD 830 Series 256 GB, 1x Crucial_CT256MX100SSD1
- HDD
- Toshiba X300 5TB
- Optisches Laufwerk
- Samsung Brenner
- Soundkarte
- onboard
- Gehäuse
- Fractal Design Define R4
- Netzteil
- XFX 550W
- Tastatur
- Trust ASTA mechanical
- Maus
- irgend eine silent Maus
- Betriebssystem
- Arch Linux, Windows VM
- Webbrowser
- Firefox + Chromium + Konqueror
- Internetanbindung
-
▼300
▲50
Ja aber zum ersten mal in der vor kurzen herausgekommenen Version 12 gibt es auch compiler für x86 bzw x86-64.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.
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
Ähnliche Themen
- Antworten
- 0
- Aufrufe
- 736
- Antworten
- 0
- Aufrufe
- 346
- Antworten
- 0
- Aufrufe
- 398
- Antworten
- 0
- Aufrufe
- 398