Optimierung von gcc auf Ultra10

[Miq]

Welcher Architekturschalter liefert auf einer 440MHz-Ultra10 beim gcc 3.4.2 unter Solaris9 die laufzeitoptimiertesten Binaries? -mv8? -mv8plus? Das in Frage stehende Programm benutzt sehr viel float-Berechnungen - falls das eine Rolle spielt.

[DoomWarrior]

-mcpu=v9 oder -march=v9 bzw. der selbe Spaß mit ultrasparc. Weiß nicht mehr ganz genau ob es mcpu ist oder march. Tippe aber auf das erste.

[Miq]

-mcpu=v9 oder -march=v9 bzw. der selbe Spaß mit ultrasparc. Weiß nicht mehr ganz genau ob es mcpu ist oder march. Tippe aber auf das erste.

Danke, Du hast senkrecht: "-mcpu=v9" tut's. ultrasparc kennt gcc übrigens scheinbar nicht als CPU-Typ, das gibt einen Fehler.

[paraglider242]

Wenn dir Perfomance wichtig ist wuerde ich das ganze mal durch Sun Studio 11 jagen (gibts kostenlos bei Sun) - der Code ist erheblich flotter als der des gcc...

[Miq]

Wenn dir Perfomance wichtig ist wuerde ich das ganze mal durch Sun Studio 11 jagen (gibts kostenlos bei Sun) - der Code ist erheblich flotter als der des gcc...

...auch portabel? Ich habe keine große Lust, mich durch eine aufwendige Installationsarie zu kämpfen, und dann zig "#ifdef SUNSTUDIO" einbauen zu müssen. gcc ist eben fast überall verfügbar und relativ portabel, sieht man von Nickeligkeiten der Libraries ab.

[paraglider242]

Du wirst schon des oefteren mal die Makefiles bearbeiten muessen, damit das unter Sun Studio ebenfalls kompiliert - da musst du dann selbst entscheiden, was dir wichtiger ist.

[stiefkind]

Heute erst bei einer Sun-Veranstaltung gelernt: Es gibt ein gcc-Frontend zum Sun-Compiler. D. h., Du rufst gcc auf wie gewohnt, im Backend kompiliert aber der Sun Studio 11 Compiler. Details incl. Download da:

  http://cooltools.sunsource.net/gcc/index.html

Mangels eigener Erfahrung kann ich nicht sagen, wie gut das wirklich tut. Der Mann vom Engineering jedenfalls hat begeistert darueber berichtet.

wolfgang

[DoomWarrior]

Danke, Du hast senkrecht: "-mcpu=v9" tut's. ultrasparc kennt gcc übrigens scheinbar nicht als CPU-Typ, das gibt einen Fehler.

so bin wieder zuhause

 -mcpu=cpu_type
           Set the instruction set, register set, and instruction scheduling
           parameters for machine type cpu_type.  Supported values for
           cpu_type are v7, cypress, v8, supersparc, sparclite, f930, f934,
           hypersparc, sparclite86x, sparclet, tsc701, v9, ultrasparc, and
           ultrasparc3.

die einstellungen sollte es geben, f930, f934 ist meines wissens erst bei 4.0 dazugekommen, aber ultrasparc gabs imho schon bei 3.4.
Ist aber, wenn ich mich richtig entsinne, kaum schneller gewesen als v9

außerdem gibts noch die etwas abgeschwächte version -mtune. Vielleicht noch wichtig -m32 bzw. -m64 für 32bit/64bit.

[paraglider242]

Du rufst gcc auf wie gewohnt, im Backend kompiliert aber der Sun Studio 11 Compiler.

Bist du dir da wirklich sicher? So, wie ich das verstehe, handelt es sich hier nur um einen für SPARC (und wahrscheinlich auch T1) optimierten gcc.

[stiefkind]

Du rufst gcc auf wie gewohnt, im Backend kompiliert aber der Sun Studio 11 Compiler.

Bist du dir da wirklich sicher? So, wie ich das verstehe, handelt es sich hier nur um einen für SPARC (und wahrscheinlich auch T1) optimierten gcc.

Ja, bin ich. Ich habe Folien gesehen mit der Architektur. Backend ist ein Sun Studio 11. Auf der Folie war neben dem gcc-Frontend auch das herkoemmliche Studio 11 Frontend dargestellt, mit einem Pfeil ins gleiche Backend. Die Slides habe ich noch nicht da, sonst wuerde ich nochmal genauer nach Begriffen sehen. Aus den Release Notes ist das in der Tat nicht ersichtlich. Ich habe im Moment nicht genug Zeit, sonst wuerde ich mal eben die Packages runterladen, installieren und mit einer Studio 11 Installation vergleichen. Argumentation von Sun: Es war/ist einfacher und schneller, das so zu realisieren, als zum gcc selbst entsprechend beizutragen. Hintergrund ist, dass gcc zwar weit verbreitet ist und gerade bei OpenSource-Software die passenden Makefiles etc. existieren, bzw. eben darauf vertraut, dass GNU-Tools da sind, das fertige Binary eines herkoemmlichen gcc aber idR. nicht optimal laeuft, weil gcc eben auf UltraSPARC nur suboptimale Ergebnisse liefert. Und es geht fuer jede SPARC-CPU, nicht nur T1.

Spezielles fuer den T1 ist ja nur bedingt zu beachten: Auch ein T1 hat 'herkoemmliche' UltraSPARC-Kerne. Halt acht davon auf einem Chip. Und jeder Kern kann vier Threads. Fuer ein Solaris sieht das aus wie 32 CPUs. Aus Compilersicht ist das nichts wesentlich anderes wie ein 'normales' 32-CPU-SMP-System. Allerdings hat die CPU nur eine Floating Point Einheit, die sich die acht Cores teilen. Deshalb die schlechte Floatingpoint-Leistung. Wird mit dem Nachfolger T2 besser werden, da hat dann jeder Core seine eigene FPU.

wolfgang

Nachtrag: Hab' eben die Seiten mit diesem Sun GCC noch ein wenig genauer untersucht:

The GCC for SPARC Systems compilers bring the world-class performance and robustness of the SunStudio compiler backend components to GCC users. As a result, users will find that their programs run correctly with higher levels of optimizations.  Also, users can utilize additional optimizations that are not available with GCC:

• Traditional scalar optimizations
• Loop optimizations
• Prefetch
• Interprocedure optimization
• Automatic parallelization
• Inline assembler is optimized

Quelle: http://cooltools.sunsource.net/gcc/porting.html

[paraglider242]

OK, danke fuer die Erklaerung;
ich werd's bei Gelegenheit mal versuchen...

[llothar]

Eine andere Sache die insbesondere zu berücksichtigen ist wenn wirklich mal Fehler debuggt werden müssen.
Sun Studio 11 ist etwa 3x schneller mit der Compilierung als ein gcc. Die edit/compile/debug Zyklen sind also angenehmer.

Daher ist auch ein dual 900 Ultra Blade noch eine halbwegsvernüftige Unix Entwicklerkiste gegenüber einem
aktuellen Linux System (das dann etwa 5,4 GHz haben müsste).

[stiefkind]

Du rufst gcc auf wie gewohnt, im Backend kompiliert aber der Sun Studio 11 Compiler.

Bist du dir da wirklich sicher? So, wie ich das verstehe, handelt es sich hier nur um einen für SPARC (und wahrscheinlich auch T1) optimierten gcc.

Mittlerweile gibt's die Aussage auch mehr oder weniger amtlich von Sun-Mitarbeitern. Zu lesen in Weblogs:

http://www.c0t0d0s0.eu/archives/1829-GCC-for-Sparc-Systems.html
http://blogs.sun.com/roller/page/alexey?entry=1st

wolfgang