schon gewusst? gcc ist ein "bad compiler"

[Lorenz Blum]

Auszug aus http://lcc.chem.msu.ru/gran/gamess/systems.html:

What is the best PC operating system to run GAMESS?

To our opinion, choosing Linux (as well as other free UNIX-type OS like
FreeBSD, etc...) as the base environment to compile and then to run GAMESS
(as well as any other scientific software that is available to the users
only in its source form) can very often result in very inefficient usage of
CPU and other system resources. This problem is not related to the Linux
itself, but mainly to the peculiar philosophy of Linux users, and to the
lack of freely available high quality Fortran and C compilers. Although
there is a lot of available commercial compilers of higher quality, it
seems that the mentality of most Linux users forces them to use only free
software, including compilers. Unfortunately, almost any person who uses
Linux to perform various scientific calculations, uses also "free and
cheap" gcc, egcs, f2c/gcc, or g77 as compilers. Thus, the usage of bad
Fortran and C compilers leads to the really poor performance of GAMESS and
other calculation-intensive programs. In fact, such GAMESS versions use
typically from 50 to 10 percents only of the real power of the systems they
are running on.

Die Benchmarks die sie gemacht haben bestätigen obere Aussage. Jetzt frage
ich mich: Sind denn die freien Compiler wirklich schlechter oder haben die
nur keine Ahnung...???

gruss
lori

[Florian Weimer]

Post by Lorenz Blum
Die Benchmarks die sie gemacht haben bestätigen obere Aussage. Jetzt frage
ich mich: Sind denn die freien Compiler wirklich schlechter oder haben die
nur keine Ahnung...???

Die Seite ist fünf Jahre alt. Der gepriesene Watcom-Compiler ist
inzwischen mehr oder weniger freie Software.

[Bernd Nawothnig]

Wenn man den Links folgt, kommt man zu:

At present, the high-quality Watcom Fortran 77 compiler v. 11.0 is
used to build the PC GAMESS. Many time-critical sections of the
original GAMESS code were modified to achieve the maximum possible
performance on Intel x86 architecture, and a significant part of them
(approx. 20-30% of the original GAMESS (US) code) was rewritten
completely. Furthermore, very efficient assembler-level libraries are
used throughout.


Erstens duerften jene Assemblerteile nicht beim Linuxport Verwendung
finden und dann ist der gcc in erster Linie ein C und C++ Compiler.
F77 laeuft nur nebenher.

Ich wuesste jedenfalls kein wichtiges Programm hier unter Linux,
welches im Fortran geschrieben ist.




Bernd

[Bastian Blank]

Post by Bernd Nawothnig
Ich wuesste jedenfalls kein wichtiges Programm hier unter Linux,
welches im Fortran geschrieben ist.

Es gibt auch sonst nicht so sonderlich viele. Die meisten findet man im
Bereich Mathematik.

Bastian

[Bernd Nawothnig]

Post by Bastian Blank

Post by Bernd Nawothnig
Ich wuesste jedenfalls kein wichtiges Programm hier unter Linux,
welches im Fortran geschrieben ist.

Es gibt auch sonst nicht so sonderlich viele. Die meisten findet man im
Bereich Mathematik.

Und vor allem bei den Ingenieuren hat(te) Fortran eine
Riesenverbreitung. Aber auch das scheint sich dem Ende
entgegenzuneigen. Hier wird schon lange C statt Fortran im Studium
verlangt.




Bernd

[Bernd Schubert]

Post by Bastian Blank

Post by Bernd Nawothnig
Ich wuesste jedenfalls kein wichtiges Programm hier unter Linux,
welches im Fortran geschrieben ist.

Es gibt auch sonst nicht so sonderlich viele. Die meisten findet man im
Bereich Mathematik.

Auch hier in der theoretischen Chemie ;)

MCTDH: Bei Dynamikern sehr beliebt (obwohl ich mich noch immer mit dem
eigenen Konkurrenzprodukt rumschlage ;) ). Laut meiner Kollegen sehr auf
fortran-Standards ausgelegt und damit mit fast allem übersetzbar.

Gaussian: Soll nur mit dem PGI Compiler übersetzt werden, Intel Compiler
geht wohl auch, g77 (bis gcc-3.4) geht definitiv nicht. Der g77 vom gcc-4.0
ist noch ziemlich viele bugs und kann wohl nicht mal das MCTDH richtig
übersetzen.

Molpro: PGI (und andere kommerzielle Compiler?), g77 geht nicht.

Molcas: g77 und andere kommerzielle Produkte.

[Viele andere Programme zum Lösen der Schrödingergleichung, die mir jetzt
nicht einfallen]

Und noch viele kleine Programme bei uns und anderen Gruppen. Häufig wurden
die Projekte in f77 angefangen und niemand hat sich jemals bemüht sie zu
portieren. Viele können auch nur f77 programmieren, haben dann aber
natürlich auch mit den Begrenzungen dieser Sprache zu leben (z.B. keine
dynamische Speicherallozierung, typecasts, etc, etc.).
Die kommerziellen Fortran-Compiler bieten häufig die Möglichkeit, einige der
f77 Beschränkungen zu umgehen, z.B. alle intergers als 8 Byte intergers zu
setzen (-i8). Die großen kommerziellen Quantenchemie-Programme (siehe oben,
also Gaussian, Molpro, Molcas) brauchen dann häufig diese Optionen.
Solange der g77 diese Optionen noch nicht kennt, sind wir dann auf die
kommerziellen Compiler angewiesen. Durch den Zwang vom gaussian, haben wir
dann die PGI Compiler, obwohl sie nicht die schnellsten sind.
Bei der Geschwindigkeit ist der g77 zumindestens auf i686 und x86_64
ziemlich gut.

Mein eigenes C-Projekt stelle ich immer mehr auf C99 um, z.B. complexe
Zahlen lassen sich doch damit deutlich leichter bearbeiten. Da PGI C99 nun
aber nicht unterstützen will, bleibt mir sogar nur der gcc. Gut, der
(freie) Intel-Compiler würde auch gehen, habe ich aber noch nicht probiert.

Grüße,
Bernd

[Jörg W Mittag]

[...] Unfortunately, almost any person who uses
Linux to perform various scientific calculations, uses also "free and
cheap" gcc, egcs, f2c/gcc, or g77 as compilers. Thus, the usage of bad
Fortran and C compilers leads to the really poor performance of GAMESS and
other calculation-intensive programs. In fact, such GAMESS versions use
typically from 50 to 10 percents only of the real power of the systems they
are running on.
Die Benchmarks die sie gemacht haben bestätigen obere Aussage. Jetzt frage
ich mich: Sind denn die freien Compiler wirklich schlechter oder haben die
nur keine Ahnung...???

Das kann schon stimmen. Speziallösungen sind auf ihrem Spezialgebiet häufig
allgemeinen Lösungen überlegen, das gilt natürlich auch für Compiler.

GCC übersetzt sieben Programmiersprachen (C, C++, Objective-C, Fortran,
Java, Ada und Treelang in der Standard-Distribution plus noch ein Dutzend
oder so andere Sprachen in anderen Versionen (z.B. Objective-C++ in Apples
Variante)) für Dutzende von Prozessorplattformen; die meisten proprietären
Compiler übersetzen meist nur C, C++ und Fortran (wenn überhaupt) für eine
Handvoll von Prozessorplattformen, da optimiert es sich wesentlich leichter.

Dazu kommt, dass der Compilerhersteller oftmals auch gleich der
Prozessorhersteller ist und daher über weitaus bessere Dokumentation
verfügt. Selbst bei den anderen Compilerherstellern gibt es immer noch den
Vorteil, dass diese aufgrund ihrer proprietären Natur weitaus leichter NDAs
unterzeichnen können als ein GCC-Entwickler.

Die Ausrichtungen sind einfach unterschiedlich: bei GCC steht die Freiheit
an allererster Stelle, dann kommt Portabilität; Geschwindigkeit (sowohl was
die Übersetzungszeit als auch die übersetzten Programme angeht) kommt dann
irgendwann unter ferner liefen. Die Compilerhersteller, die sich auf
High-Performace-Computing spezialisiert haben, scheißen auf Freiheit und
interessieren sich meist auch nur wenig für Portabilität (wieviele
Rechencluster gibt es mit Embedded-ARM-Prozessoren?), dafür konzentrieren
sie sich auf die Performance der Kompilate.

Intels ICC liegt auf Intel-Prozessoren meist deutlich vor GCC und selbst auf
AMD-Prozessoren kann man noch ein paar Prozent rausholen, obwohl der ICC gar
keine AMD-spezifischen Optimierungen kennt. Noch mehr kann man hier wohl mit
AMDs Hauslieferant Metrowerks erwarten. Auf PowerPC sind IBMs Compiler klar
besser als GCC und ich würde -- obwohl ich dazu keine Benchmarks kenne --
dasselbe auch von den Sun-Compilern für Sparc-CPUs erwarten. Die
Fortran-Spezialisten, die reine Fortran-Compiler bauen, leben sowieso in
ihrer ganz eigenen Welt. Das wird noch eine ganze Weile dauern, bis GCC da
einbrechen kann: das alte Fortran-Frontend (g77) war nicht wirklich ein
Glanzstück (z.B. unterstützt es nur das antiquierte Fortran 77 und nicht die
neueren Versionen Fortran 90, 95 und 2000) und das brandneue Frontend in
GCC4 (gfortran) ist ... nun ja ... noch brandneu. Proprietäre Compiler
unterstützen meist Autovektorisierung und Autoparallelisierung, die sich für
GCC noch in der Entwicklung befinden (rudimentäre Teile von autovect sind
bereits in GCC 4.0.0 enthalten). Proprietäre (Fortran-)Compiler enthalten
oft für jede mitgelieferte Bibliothek mehrere für spezifische Prozessoren
handoptimierte Assembler-Implementierungen, was bei GCC schon alleine
aufgrund der schieren Anzahl unterstützer Plattformen undenkbar ist.

Und schließlich gibt es noch einen ganz simplen Grund, wie die o.g. Aussagen
zustande gekommen sein können: sie scheinen mir ziemlich alt zu sein und GCC
hat sich in den letzten paar Jahren stark weiterentwickelt. Insbesondere,
was Fortran angeht, worum es auf der zitierten Website schließlich geht.

jwm

[Felix von Leitner]

Post by Jörg W Mittag
Intels ICC liegt auf Intel-Prozessoren meist deutlich vor GCC und selbst auf
AMD-Prozessoren kann man noch ein paar Prozent rausholen, obwohl der ICC gar
keine AMD-spezifischen Optimierungen kennt.

Das kann ich so nicht bestätigen.

Mit icc kann der vorsichtige Admin oder Entwickler noch ein paar Prozent
rauskitzeln, das ist richtig, aber sicher ist das nicht. Ich habe hier
auch Software, die unter gcc 10% schneller ist. Und bei der meisten
Software ist es +- 0.

Post by Jörg W Mittag
Noch mehr kann man hier wohl mit AMDs Hauslieferant Metrowerks
erwarten.

Halte ich für ein Gerücht.

Post by Jörg W Mittag
Auf PowerPC sind IBMs Compiler klar besser als GCC

Auch das halte ich für ein Gerücht.

Post by Jörg W Mittag
und ich würde -- obwohl ich dazu keine Benchmarks kenne --
dasselbe auch von den Sun-Compilern für Sparc-CPUs erwarten.

Die Sun Compiler sind berühmt dafür, langsamer zu laufen und langsameren
Code zu erzeugen als gcc. Und weniger Standards einzuhalten.

Aber was erwartet man. Der Sun C Compiler ist -- laut einem Insider --
ein FORTRAN für 68k Compiler gewesen, den sie so lange aufgehackt haben,
bis er C++ für SPARC übersetzt hat.

Post by Jörg W Mittag
Die Fortran-Spezialisten, die reine Fortran-Compiler bauen, leben
sowieso in ihrer ganz eigenen Welt. Das wird noch eine ganze Weile
dauern, bis GCC da einbrechen kann: das alte Fortran-Frontend (g77)
war nicht wirklich ein Glanzstück (z.B. unterstützt es nur das
antiquierte Fortran 77 und nicht die neueren Versionen Fortran 90, 95
und 2000) und das brandneue Frontend in GCC4 (gfortran) ist ... nun ja
... noch brandneu.

Who cares?

Post by Jörg W Mittag
Proprietäre Compiler unterstützen meist Autovektorisierung und
Autoparallelisierung, die sich für GCC noch in der Entwicklung
befinden (rudimentäre Teile von autovect sind bereits in GCC 4.0.0
enthalten).

Und die auch nie mit dem Hirn eines Hackers mithalten kann.

Ich halte Autovektorisierung ja für einen Marketing-Witz. Am Ende
fummeln die Programmierer ihren Code so zurecht, daß der Compiler
erkennt, daß das vektorisierbar ist. Mit dem selben Aufwand hätte man
das auch schnell selbst vektorisiert gekriegt.

Post by Jörg W Mittag
Proprietäre (Fortran-)Compiler enthalten oft für jede mitgelieferte
Bibliothek mehrere für spezifische Prozessoren handoptimierte
Assembler-Implementierungen, was bei GCC schon alleine aufgrund der
schieren Anzahl unterstützer Plattformen undenkbar ist.

Auch die libm unter Linux ist handoptimierter Assembler.

Und von Intel gibt es eine optimierte Mathe-Library für Linux.

Felix

[Adrian Knoth]

Post by Felix von Leitner

Post by Jörg W Mittag
Auf PowerPC sind IBMs Compiler klar besser als GCC

Auch das halte ich für ein Gerücht.

Laut den Ausführungen von Noses in de.comp.sys.mac.misc gibt es
mindestens einen deutlich besseren Compiler für Apple-CPUs (xlc).

Post by Felix von Leitner
Ich halte Autovektorisierung ja für einen Marketing-Witz.

Ich finde zumindest die Idee gut. Ob es am Ende was bringt, ist
die andere Frage, aber das Herausziehen von Parallelität ist
potenziell eine gute Sache, wenngleich dieser "magische" Compiler-
ansatz eventuell der falsche Weg ist. Ein portables Auszeichnen
von vektorisierbarem Code wäre sicherlich besser.

Post by Felix von Leitner
Am Ende fummeln die Programmierer ihren Code so zurecht, daß der
Compiler erkennt, daß das vektorisierbar ist. Mit dem selben
Aufwand hätte man das auch schnell selbst vektorisiert gekriegt.

Es ist zumindest halbwegs portabel. Wobei das ja wiedermal ein
typisches Intel-Problem ist: während bei Apple seit dem G4 das
SIMD-Instructionset in Form von AltiVec konstant und umfassend
ist, gurkt man auf x86 im Jahresrhythmus mit irgend einer anderen
Vektoreinheit rum. Kaum hat man den Krempel in MMX fertig, kann
man es für SSE neu formulieren, brauchbar wird es ab SSE2 (schon
wieder rewrite) und mit SSE3 ist man dann in etwa dort wo AltiVec
vor fünf Jahren war. Dabei sind die ganzen AMD-eigenen Erweiterungen
noch gar nicht mit inbegriffen (3dnow, 3dnow2).

Da kann man dem Kunden auch gleich ne DSP-Einsteckkarte verkaufen,
die ändert wenigstens nicht so häufig ihren Befehlssatz ;)

[Stefan Reuther]

Post by Felix von Leitner

Post by Jörg W Mittag
Proprietäre Compiler unterstützen meist Autovektorisierung und
Autoparallelisierung, die sich für GCC noch in der Entwicklung
befinden (rudimentäre Teile von autovect sind bereits in GCC 4.0.0
enthalten).

[...]

Post by Felix von Leitner
Ich halte Autovektorisierung ja für einen Marketing-Witz. Am Ende
fummeln die Programmierer ihren Code so zurecht, daß der Compiler
erkennt, daß das vektorisierbar ist. Mit dem selben Aufwand hätte man
das auch schnell selbst vektorisiert gekriegt.

Ich weiß jetzt nicht, was gcc unter Autovektorisierung versteht. Ich hab
hier einen Compiler für einen DSP, der, wenn man den C-Code für ein
Skalarprodukt, eine Faltung oder ähnliche Algorithmen hinschreibt,
direkt den optimalsten[tm] Assemblercode dafür generiert (Nulloverhead-
Schleife, Multi-Issue-Instruktionen, ..., also in Summe ein Vektor-
element pro Takt, wie sich das gehört), und nicht irgendwie dusslig mit
Zählern, Vergleichsoperationen usw. rumoperiert.

Natürlich ist das teilweise ein Marketinggag ("seht her, unsere Chips
sind so benutzerfreundlich, dass ihr sie nicht in Assembler program-
mieren müsst, um optimale Performance zu erhalten"). Aber andererseits
ist das wesentlich besser, als wenn ich selber mit irgendwelchen
hässlichen intrinsics durch die Gegend wuseln müsste, um diese Perfor-
mance zu erhalten. Insbesondere hab ich 100% ISO-C geschrieben, und kann
somit die Funktionalität auch auf dem PC testen, ohne erst irgendwelche
Emulationslayers schreiben zu müssen.


Stefan

[Rainer Weikusat]

Post by Stefan Reuther

Post by Felix von Leitner

Post by Jörg W Mittag
Proprietäre Compiler unterstützen meist Autovektorisierung und
Autoparallelisierung, die sich für GCC noch in der Entwicklung
befinden (rudimentäre Teile von autovect sind bereits in GCC 4.0.0
enthalten).

[...]

Post by Felix von Leitner
Ich halte Autovektorisierung ja für einen Marketing-Witz. Am Ende
fummeln die Programmierer ihren Code so zurecht, daß der Compilern
erkennt, daß das vektorisierbar ist. Mit dem selben Aufwand hätte man
das auch schnell selbst vektorisiert gekriegt.

Ich weiß jetzt nicht, was gcc unter Autovektorisierung versteht. Ich hab
hier einen Compiler für einen DSP, der, wenn man den C-Code für ein
Skalarprodukt, eine Faltung oder ähnliche Algorithmen hinschreibt,

... und der Compiler das ueberraschenderweise bemerken sollte und auch
dann nicht vergisst, nachdem der Code ein paar Mal geaendert wurde und
usf ...

"Den C-Code fuer ein Skalarprodukt" gibt es nicht. Es gibt eine
potentiell unendliche Menge von in C geschriebenen Algorithmen, die
Skalarprodukte usf berechnen und aus dieser Menge wird der Prozessor
einen gewissen und wahrscheinlich kleinen Teil erkennen, und wenn man
die Phantasie noch ein wenig spielen laesst, dann wird man vermuten,
dass es primaer der Teil sein wird, der ungefaehr so aussieht, wie ihn
ein Mensch, der eher etwas von Skalarprodukten versteht, naiv
hingeschrieben haette.

Post by Stefan Reuther
direkt den optimalsten[tm] Assemblercode dafür generiert

Vermutlich den 'optimiertesten', obwohl das auch Quatsch ist. Falls Du
ein Kriterium (einen Satz von Kriterien) ausreichend genau definieren
und messen kannst, das Du "dem Abschneiden" (mangels besseren
Begriffes) eines bestimmten Algorithmus auf einer gegebenen Hardware
eindeutig eine Zahl zuordnen kannst, wenn Du ausserdem quasi eine
"Wunschzahl" kennst, und Du auf der Menge der Paare <gemessene Zahl,
gewuenschte Zahl> eine wenigstens partielle Ordnung so definiert hast,
dass ein 'Fortschritt' oder 'Rueckschritt von einem Paar zum anderen
dadurch beschreibar wird, dann gibt es einen 'optimalen Algorithmus'
und das ist der, bei dem, verglichen mit den Paar <Wunschzahl,
Wunschzahl>, das Paar <gemessene Zahl, Wunschzahl> den technisch
geringstmoeglichen 'Rueckschritt' darstellt (und der wird auch
dadurch, dass Positiv, Comparativ und Superlativ ein weites Feld sind,
auf dem schon mancher verlorenging, nicht optimaler).

Post by Stefan Reuther
(Nulloverhead-Schleife,

Korrekterweise sollte man hier von 'Zaehlschleifenhardware' sprechen.

[...]

Post by Stefan Reuther
Natürlich ist das teilweise ein Marketinggag ("seht her, unsere Chips
sind so benutzerfreundlich, dass ihr sie nicht in Assembler program-
mieren müsst, um optimale Performance zu erhalten").

... sondern sie muessen lediglich noch durch Versuch und Irrtum
ermitteln, unter welchen Umstaenden unser Compiler den 'besten' (::=
'optimalen') Code erzeugt und schon tut er das [... das koennen sie aber
ausprobieren und muessen es nicht nachlesen ...].

Post by Stefan Reuther
Insbesondere hab ich 100% ISO-C geschrieben, und kann somit die
Funktionalität auch auf dem PC testen, ohne erst irgendwelche
Emulationslayers schreiben zu müssen.

Du bist allerdings auf die Untermenge von ISO-C beschraenkt, fuer die
Deine Software Code mit den entsprechenden Eigenschaften erzeugt und
das hast (wahrscheinlich) keine Moeglichkeit, a priori sicher zu
ermitteln, ob ein gegebener Quellcode Element dieser Untermenge ist.

[Felix von Leitner]

Post by Stefan Reuther
Ich weiß jetzt nicht, was gcc unter Autovektorisierung versteht.

Der Compiler erkennt Sequenzen, die man mit SIMD-Instruktionen abbilden
kann, und formuliert gegebenenfalls die Schleifen neu, um da mehr
rausholen zu können.

Felix

[Jörg Sommer]

Post by Felix von Leitner

Post by Stefan Reuther
Ich weiß jetzt nicht, was gcc unter Autovektorisierung versteht.

Der Compiler erkennt Sequenzen, die man mit SIMD-Instruktionen abbilden
kann, und formuliert gegebenenfalls die Schleifen neu, um da mehr
rausholen zu können.

In wieviel Prozent der Fälle ist das möglich? Irgendwie klingt die Idee
recht abwegig.

Jörg.

[Patrick Cornelißen]

Post by Jörg Sommer
In wieviel Prozent der Fälle ist das möglich? Irgendwie klingt die Idee
recht abwegig.

Es gibt auf symbolischer Ebene schon einige Regeln, mit denen man
Befehlsfolgen transformieren kann, so daß sie hinterher immernoch das
tun, was sie vorher auch tun sollten, aber "besser" laufen.
Autovektorisierung gehört da aber schon zu den schwierigen Regelwerken.

Dazu gibt es nette Vorlesungen, vorwiegend Theoretische Informatik.

[Rainer Weikusat]

Post by Patrick Cornelißen

Post by Jörg Sommer
In wieviel Prozent der Fälle ist das möglich? Irgendwie klingt die Idee
recht abwegig.

Es gibt auf symbolischer Ebene schon einige Regeln, mit denen man
Befehlsfolgen transformieren kann, so daß sie hinterher immernoch das
tun, was sie vorher auch tun sollten, aber "besser" laufen.

Das ist schon theoretisch vollkommen unmoeglich, weil 'besser'
ohne Bezugsrahmen nicht beurteilt werden kann.

[Patrick Cornelißen]

Post by Rainer Weikusat
Das ist schon theoretisch vollkommen unmoeglich, weil 'besser'
ohne Bezugsrahmen nicht beurteilt werden kann.

Daher die Anführungszeichen.
Schon mal probiert bei -O$num einen Verwendungszweck anzugeben?

[Adrian Knoth]

Post by Jörg Sommer

Post by Felix von Leitner

Post by Stefan Reuther
Ich weiß jetzt nicht, was gcc unter Autovektorisierung versteht.

Der Compiler erkennt Sequenzen, die man mit SIMD-Instruktionen abbilden
kann, und formuliert gegebenenfalls die Schleifen neu, um da mehr
rausholen zu können.

In wieviel Prozent der Fälle ist das möglich?

Wieviel Prozent wovon? "Hello World" wird man wohl schwierig
parallelisieren können, bei FX-Loops über Audiosamples sieht es
schon besser aus. Die Frage ist äußerst schwammig ;) Aber vielleicht
erstmal das hier lesen:

http://www.gnu.org/software/gcc/projects/tree-ssa/vectorization.html

Post by Jörg Sommer
Irgendwie klingt die Idee recht abwegig.

Geht so. Portable SIMD-Unterstützung ist schon nicht schlecht. AMD und
Intel könnten natürlich auch einfach AltiVec lizensieren, dann wäre mein
größter Schmerz bereits gelindert ;)

[Felix von Leitner]

Post by Jörg Sommer

Post by Felix von Leitner
Der Compiler erkennt Sequenzen, die man mit SIMD-Instruktionen abbilden
kann, und formuliert gegebenenfalls die Schleifen neu, um da mehr
rausholen zu können.

In wieviel Prozent der Fälle ist das möglich? Irgendwie klingt die Idee
recht abwegig.

Das ist ja der Punkt.
Es bringt so gut wie nie was.
Außer in speziell dafür konstruierten Benchmarks, natürlich.
man Apple.

Felix