Jaja nur OpenSource... wäre ja schön, aber Gerade im Bereich Compiler ist das manchmal echt schwer. An Unis wird in den Bereichen Maschinenbau/Verfahrenstechnik noch sehr viel Fortran eingesetzt und ganz bestimmt nicht, weil es so toll zu programmieren ist. Es ist einfach schnell. Vorrausgesetzt man hat vernünftige Compiler. IBM hat solche und Intel ist da auch sehr gut. Der GNU Compiler ist nicht brauchbar, denn Fortran 77 ist schon lange nicht mehr Stand der Technik. Mittlerweile gibt es schon den Fortran 2000 Standard, da ist 77 schon lange her. Ähnlich verhält es sich mit C++ Compilern. Ich habe stark den Eindruck das Borland und Microsoft C++ Compiler sehr viel schnelleren Code erzeugen als der g++. Dann bin ich immer ganz traurig, schließlich entwickele ich auch lieber mit GNU Produkten. Nur wenn die Performance nicht stimmt, dann kann man auch niemanden überzeugen. Was hinzu kommt ist, daß die Standarbibliothek/STL nicht vollständig implementiert ist.
In diesem Fall kann Intel auch keine Lizenz im Sinne "frei für akademischen Gebrauch" schließlich ist das eine der Hauptanwendungen (vermute ich jedenfalls). Für mich stellt sich die Frage, was wichtiger ist: Linux verbreiten und verhindern das in typischen UNIX Gebieten (Forschung) auf einmal Windows Einzug hält. Auch wenn man dann mit kommerziellen Produkten arbeiten muß. Oder den Gedanken von freier Software sehr viel mehr in den Vordergrund zu stellen, und Abstriche in Kauf zu nehmen. Eine Antwort darauf ist mir noch nicht eingefallen und leicht ist sie schon gar nicht.
Von Christoph Maurer am Fr, 4. Mai 2001 um 12:57 #
@ anonymous:
Du hast insofern Recht, daß es an wirklich leistungsfähigen Kompilern (Borland) unter Linux mangelt, und speziell für Fortran sieht es noch mal deutlich dürftiger aus als für C/C++
Worin ich Dir allerdings widersprechen möchte, ist die angeblich mangelhafte Unterstützung der C++-Standardbibliothek durch den g++. Ich verwende hier parallel MSVC++ und g++ 2.95.3 bei der Programmierung wissenschaftlicher Software, die sehr intensiv die Routinen der Standardbibliothek nutzt und der MS-Kompiler macht da aus meiner Sicht deutlich mehr Ärger. (z.B. werden keine Reverse-Iteratoren unterstützt) Ich programmiere unter Linux, portiere das Zeug aber dann irgendwann nach WinNT, weil unsere Kunden die entwickelte Software in aller Regel auf Windows-Kisten einsetzen, und das ist immer wieder festzustellen, daß lange nicht alles, was unter Linux funktioniert und auch STL-konform ist, mit MSVC++ auch kompilierbar ist. Erst gestern hatte ich wieder die Meldung; Internal Kompiler-Error, kontaktieren Sie den MS Software Service
Hallo Christoph, ich hätte jetzt gerne einen Kommentar abgegeben, aber ich bekomme die Meldung "Einige der Wörter in deiner Reaktion sind zu lang", tja Pech gehabt. Der Grund, warum ich meinte die STL sei nicht vollständig ist, daß ich versuchte habe Zeilen in einer Datei zu zählen mit dem count Algorithmus und einem istreambuf_iterator und genau den scheint es nicht zu geben. Vielleicht hast Du ja einen Tip. Ich bin noch nicht solange dabei C++ zu programmieren. Jörg :-)
Von Harald Nikolisin am Fr, 4. Mai 2001 um 19:03 #
aber hallo
Wir nutzen seit 1998 den Lahey/Fujitsu F90/95 Compiler. Wir, heisst die Sofistik AG, die Statik Programme auf Basis der Finiten Element Methode herstellt. Während wir in den Anfängen schon einen Geschwindigkeitsvorteil vom Faktor 2 gegenüber dem Windows Programmen (Digital Compiler), ist es mittlerweile 3 (!). Und das noch mit der Compilerversion 5.5. Seit neuestem benutzen wir den Compiler V 6.0, der laut Lahey automatische Parallelisierung betreiben kann. Allerdings ist ohne Vorbereitung des Codes nicht allzuviel zu erwarten.Trotzdem ist dieser Compiler seit geraumer Zeit eine wichtiges Standbein, bei technischen Anwendungen, die wohl weiterhin in Fortran geschrieben werden. Niemand konnte den Geschwindigkeitsvorteil von Fortran brechen. Leider sind die Frontends mehrheitlich in der MFC geschrieben, so dass nur die Rechen-Kerne auf Linux laufen. Allerdings so schnell, dass einige Bauingenieurbüros in Deutschland, Linux-Rechenserver (oft SMP) betreiben.
Ich muss hier auch nochmal betonen, dass die Forschungsschiene und technische Schiene auf gar keinen Fall vernachlässigt werden darf. Hier ist noch ein Umfeld, in dem UNIX/Linux dominiert.
Zum Thema OSS. Die Verbreitung des Wissens auf öffentlicher und unkommerzieller Ebene ist eine wichtige und richtige Sache. Allerdings kann man es Lahey und uns schlecht vorwerfen, dass wir Geld für unsere Produkte verlangen, in die wir viel Arbeit stecken müssen. Schliesslich müssen die Pinguin Austauschkappen für die Cherry Tastatur auch bezahlt werden
Super, hoffentlich bringen die auch bald den Intel Compiler raus. Ich will ja nichts sagen aber das Ding erzeugt Programme die teilweise um Längen (30%) schneller sind als die vom GCC mit -03. Das macht ja schon fast 1 Jahr Prozessortechnik Evolution aus - und damit einiges an gespartem Geld bei Highend Anwendungen.
GCC ist weder gut noch schnell. Eins von beiden sollte es aber sein.
>GCC ist weder gut noch schnell. Eins von beiden sollte es aber sein.<
Da gibt es nur 3 Lösungen: Packe selbst mit an, wähle ein Konkurrenz Produkt (bald gibt es ja den BCB Compiler ) oder du hörst auch dich zu beschweren.
@tmmw: das dürfte von den Optimierungs-Optionen abhängen.
@anonymous: Es gab eine Zeit, da war gcc besser als jeder kommerzielle UNIX-C-Compiler. Aber entweder hat die Entwicklung seither stagniert, oder die Chiphersteller haben enorme Ressourcen in die Entwicklung von optimierten Compilern gesteckt.
@tmmw: in der regel kommt man mit etwas herumprobieren sogar ft auf das ergebnis, das die Optimierungen, mit denen die Programme am schnellsten laufen für beide CPUs die gleichen sind...
auf meine Kiste kommt nur OSS :-)
wäre ja schön, aber Gerade im Bereich Compiler ist das manchmal echt schwer. An Unis wird in den Bereichen Maschinenbau/Verfahrenstechnik noch sehr viel Fortran eingesetzt und ganz bestimmt nicht, weil es so toll zu programmieren ist. Es ist einfach schnell. Vorrausgesetzt man hat vernünftige Compiler. IBM hat solche und Intel ist da auch sehr gut. Der GNU Compiler ist nicht brauchbar, denn Fortran 77 ist schon lange nicht mehr Stand der Technik. Mittlerweile gibt es schon den Fortran 2000 Standard, da ist 77 schon lange her. Ähnlich verhält es sich mit C++ Compilern. Ich habe stark den Eindruck das Borland und Microsoft C++ Compiler sehr viel schnelleren Code erzeugen als der g++. Dann bin ich immer ganz traurig, schließlich entwickele ich auch lieber mit GNU Produkten. Nur wenn die Performance nicht stimmt, dann kann man auch niemanden überzeugen. Was hinzu kommt ist, daß die Standarbibliothek/STL nicht vollständig implementiert ist.
In diesem Fall kann Intel auch keine Lizenz im Sinne "frei für akademischen Gebrauch" schließlich ist das eine der Hauptanwendungen (vermute ich jedenfalls). Für mich stellt sich die Frage, was wichtiger ist: Linux verbreiten und verhindern das in typischen UNIX Gebieten (Forschung) auf einmal Windows Einzug hält. Auch wenn man dann mit kommerziellen Produkten arbeiten muß. Oder den Gedanken von freier Software sehr viel mehr in den Vordergrund zu stellen, und Abstriche in Kauf zu nehmen. Eine Antwort darauf ist mir noch nicht eingefallen und leicht ist sie schon gar nicht.
Du hast insofern Recht, daß es an wirklich leistungsfähigen Kompilern (Borland) unter Linux mangelt, und speziell für Fortran sieht es noch mal deutlich dürftiger aus als für C/C++
Worin ich Dir allerdings widersprechen möchte, ist die angeblich mangelhafte Unterstützung der C++-Standardbibliothek durch den g++. Ich verwende hier parallel MSVC++ und g++ 2.95.3 bei der Programmierung wissenschaftlicher Software, die sehr intensiv die Routinen der Standardbibliothek nutzt und der MS-Kompiler macht da aus meiner Sicht deutlich mehr Ärger. (z.B. werden keine Reverse-Iteratoren unterstützt) Ich programmiere unter Linux, portiere das Zeug aber dann irgendwann nach WinNT, weil unsere Kunden die entwickelte Software in aller Regel auf Windows-Kisten einsetzen, und das ist immer wieder festzustellen, daß lange nicht alles, was unter Linux funktioniert und auch STL-konform ist, mit MSVC++ auch kompilierbar ist. Erst gestern hatte ich wieder die Meldung; Internal Kompiler-Error, kontaktieren Sie den MS Software Service
Christoph
ich hätte jetzt gerne einen Kommentar abgegeben, aber ich bekomme die Meldung "Einige der Wörter in deiner Reaktion sind zu lang", tja Pech gehabt.
Der Grund, warum ich meinte die STL sei nicht vollständig ist, daß ich versuchte habe Zeilen in einer Datei zu zählen mit dem count Algorithmus und einem istreambuf_iterator
und genau den scheint es nicht zu geben.
Vielleicht hast Du ja einen Tip. Ich bin noch nicht solange dabei C++ zu programmieren.
Jörg :-)
Christoph
Gruss
Matthias
(Ich würde ja mithelfen, wenn
ich gut im Compilerbau wäre ...)
Wir nutzen seit 1998 den Lahey/Fujitsu F90/95 Compiler. Wir, heisst die Sofistik AG, die Statik Programme auf Basis der Finiten Element Methode herstellt. Während wir in den Anfängen schon einen Geschwindigkeitsvorteil vom Faktor 2 gegenüber dem Windows Programmen (Digital Compiler), ist es mittlerweile 3 (!). Und das noch mit der Compilerversion 5.5. Seit neuestem benutzen wir den Compiler V 6.0, der laut Lahey automatische Parallelisierung betreiben kann. Allerdings ist ohne Vorbereitung des Codes nicht allzuviel zu erwarten.Trotzdem ist dieser Compiler seit geraumer Zeit eine wichtiges Standbein, bei technischen Anwendungen, die wohl weiterhin in Fortran geschrieben werden. Niemand konnte den Geschwindigkeitsvorteil von Fortran brechen.
Leider sind die Frontends mehrheitlich in der MFC geschrieben, so dass nur die Rechen-Kerne auf Linux laufen. Allerdings so schnell, dass einige Bauingenieurbüros in Deutschland, Linux-Rechenserver (oft SMP) betreiben.
Ich muss hier auch nochmal betonen, dass die Forschungsschiene und technische Schiene auf gar keinen Fall vernachlässigt werden darf. Hier ist noch ein Umfeld, in dem UNIX/Linux dominiert.
Zum Thema OSS. Die Verbreitung des Wissens auf öffentlicher und unkommerzieller Ebene ist eine wichtige und richtige Sache. Allerdings kann man es Lahey und uns schlecht vorwerfen, dass wir Geld für unsere Produkte verlangen, in die wir viel Arbeit stecken müssen. Schliesslich müssen die Pinguin Austauschkappen für die Cherry Tastatur auch bezahlt werden
GCC ist weder gut noch schnell. Eins von beiden sollte es aber sein.
Da gibt es nur 3 Lösungen: Packe selbst mit an, wähle ein Konkurrenz Produkt (bald gibt es ja den BCB Compiler
) oder du hörst auch dich zu beschweren.
Laufen Programme, die mit einem Intel Compiler übersetzt wurden, auch auf einer AMD CPU?
@anonymous: Es gab eine Zeit, da war gcc besser als jeder kommerzielle UNIX-C-Compiler. Aber entweder hat die Entwicklung seither stagniert, oder die Chiphersteller haben enorme Ressourcen in die Entwicklung von optimierten Compilern gesteckt.
in der regel kommt man mit etwas herumprobieren sogar ft auf das ergebnis, das die Optimierungen, mit denen die Programme am schnellsten laufen für beide CPUs die gleichen sind...
... wer kann, der helfe mit!!
:-)
Crunch in freedom