Kompiler, das A und O der EDV?

[meisterthomas]

Wie sich den CT-Artikel entnehmen läßt, variert die Performance eines Progrmmes selbst unter aktuellen compilern erheblich. So bringt der neue Intel-Compiler 7.0, auch ohne das Hyper-Threading zu nutzen 10 - 15 % mehr Leistung, als der ebenso neue Compiler von Microsoft. Sehr viel grösser wird dieser Leistungsunterschied zwischen auf den Pentium 4. und 486-er optimierte Programme, von denen es reichlich zu geben scheint. Nicht zuletzt dürften auch die Programmentwickler eine breite Kundenschicht erreichen wollen, oder können auch am Compiler gesparrt haben.

CT 5. 2003
c++ Compiler
http://www.hocomputer.de/ct0503.pdf
(Fortran)
http://www.hocomputer.de/ct2402.pdf

Die Unterschiede der Linux-Distributionen, SuSe, Red Hat, Mandrake, usw. ergeben sich nur wenig aus dem Quellkode, werden aber durch die jeweilige Kompilation und Vorkompilation der Programme zementiert.
Letzteres vereinfacht die Programminstallation unter Linux erheblich. Es verhindert aber auch eine angepaßte Kompilation. Insbesondere mit dem dot.net-framework werden Performance-Unterschiede zwischen Linux und Windows deutlicher werden.

Anstat der Vorkompilation, ließe sich die Installation natürlich auch vereinfachen, indem entsprechend einfach zu handhabende Kompiler gebaut werden.
Dies widerspricht allerdings den Interessen der Distributeure.

Die wichtigsten Assembler TASM und MASM sind bereits von Borland und Microsoft in kooperation eingeschläfert worden. Der veraltete Turbo-Assembler ist nicht einmal für das Open Source freigegeben worden.

Die neue Allianz um das dot-net-System könnte gleichsam, jeden Kompiler im Windows-Markt verdrängen, was dann auch auf Linux durchwirkt.

Wenn Open Source, auch "open" bleiben soll, so erfordert das, daß wir den Kompilern auch unter Linux unsere Aufmerksamkeit schenken.
Unabhängigkeit erfordert gar exelente open source Kompiler, auch unter Linux.
(Der Intel Pentium C/C++ Kompiler wird auch für Linux angeboten, hat aber seinen Preis. Siehe auch
http://www.hocomputer.de/intel_c___fur_linux.htm).
oder:
http://www.intel.com/software/products/compilers/c60l/resources/c_ug_lnx.pdf


Thomas

[Jan Krüger]

Wie sich den CT-Artikel entnehmen läßt, variert die Performance eines Progrmmes selbst unter aktuellen compilern erheblich. So bringt der neue Intel-Compiler 7.0, auch ohne das Hyper-Threading zu nutzen 10 - 15 % mehr Leistung, als der ebenso neue Compiler von Microsoft. Sehr viel grösser wird dieser Leistungsunterschied zwischen auf den Pentium 4. und 486-er optimierte Programme, von denen es reichlich zu geben scheint. Nicht zuletzt dürften auch die Programmentwickler eine breite Kundenschicht erreichen wollen, oder können auch am Compiler gesparrt haben.
Soweit sicher richtig, aber eine entscheidende Komponente des Compiler wäre auch noch die Optimierung an sich, d.h. ein bestimmtes Stück Code möglichst effizient in Assembler umzusetzen. Das kann auch mit ein- und demselben Befehlssatz (angenommen, beide Compiler optimieren auf Pentium) erheblich unterschiedlich aussehen - der eine Compiler schafft es vielleicht sogar, Schleifen wegzuoptimieren (ob das wirklich möglich ist, kann ich nicht sagen, ich hab noch nie einen Compiler geschrieben ;)).

Die Unterschiede der Linux-Distributionen, SuSe, Red Hat, Mandrake, usw. ergeben sich nur wenig aus dem Quellkode, werden aber durch die jeweilige Kompilation und Vorkompilation der Programme zementiert.
So wenig machen die Distributoren gar nicht am Quellcode - ich hab schon erlebt, dass ein selbstkompilierter Kernel nicht mit den Boot-Parametern eines Linux-Kernel-Images aus einem RedHat-Paket lief.
Aber ich finde es selber auch überraschend, dass es noch so viele Distributionen gibt, die ihre Pakete für i386-Prozessoren compilieren...

Anstat der Vorkompilation, ließe sich die Installation natürlich auch vereinfachen, indem entsprechend einfach zu handhabende Kompiler gebaut werden.
Dies widerspricht allerdings den Interessen der Distributeure.
Man muss hier eindeutig zwischen der Oberfläche und dem Compiler an sich trennen. Sprichst du von Oberflächen oder von Compilern?
Ich persönlich finde, dass man durchaus an den Oberflächen mehr tun könnte, aber der Compiler ist ja nunmal das Werkzeug des Entwicklers und normale Benutzer sollten damit nicht unbedingt zu tun haben müssen (außer natürlich, sie wollen unbedingt ;)). Und das ist ja bei vielen Linux-Source-Paketen schon der Fall - der Benutzer muss nur noch einmal ./configure und einmal make eingeben, den Rest erledigen das Autoconf-Script, Make und der Compiler von alleine.
Steigerung wäre z.B. das Portage-System von Gentoo Linux (eine Distribution, die aus Sourcecode-Paketen besteht) - hier lässt sich mit einem einzigen Befehl ein Paket downloaden, konfigurieren, compilieren und installieren, und das genau an die Systemkonfiguration angepasst.

Die wichtigsten Assembler TASM und MASM sind bereits von Borland und Microsoft in kooperation eingeschläfert worden. Der veraltete Turbo-Assembler ist nicht einmal für das Open Source freigegeben worden.
Ich selber finde es auch etwas schade, dass es in der Windows-Welt keinen ernstzunehmenden, weiterentwickelten Assembler gibt.
Ist der Microsoft-Assembler eigentlich inzwischen wenigstens frei verfügbar?

Die neue Allianz um das dot-net-System könnte gleichsam, jeden Kompiler im Windows-Markt verdrängen, was dann auch auf Linux durchwirkt.
Inwiefern? Ich muss gestehen, ich habe mich mit dem .NET-System noch nicht so besonders viel beschäftigt, von daher stehe ich dieser Aussage etwas hilflos gegenüber. ;)

Unabhängigkeit erfordert gar exelente open source Kompiler, auch unter Linux.
Was hälst du von GCC? Nach allem, was ich gehört habe, ist der Inter-Compiler zwar schneller, aber GCC funktioniert immerhin, ist universell einsetzbar und optimiert ziemlich gut, soweit ich das beurteilen kann (leider fehlen mir etwas die Vergleichswerte - vielleicht teste ich ja mal den Intel-Compiler).

Schlussendlich möchte ich noch anmerken, dass ich den Threadtitel für nicht zum Inhalt passend halte. Ich glaube, niemand würde abstreiten, dass Compiler einen zentralen Bestandteil der EDV darstellen und nicht wegzudenken sind. ;)

[meisterthomas]

:)Auch bei ein und dem selben Compiler kann es zu erheblichen Unterschieden kommen, je nach dem ob auf Code-Länge oder Geschwindigkeit optimiert wurde. Von immenser Bedeutung ist das bei Mikrokontrollern, bzw wenn das Programm „Chip-intern“ untergebracht werden muß. -- Denkbar wäre auch eine Programmbibliothek im Cachespeicher unter Linux.

Von einer Schleife spreche ich, wenn ein und dieselbe Unterprogramfolge in Abhängigkeit von einer Abbruchsbedingung wiederholt wird. Wenn diese Abbruchbedingung bereits zur Compile-time feststeht und nicht erst zur runtime eines Programms eindeutig gegeben ist, z. B. Ein feststehender numerischer Wert, der Angibt das die Schleife 100mal durchlaufen werden soll, dann kann der Compiler selbstverständlich auch 100 mal hintereinander das betreffende Unterprogramm übersetzen. Das Selbe gilt wenn Werte wie Fakultät, "n!" etc. zur Laufzeit berechnet, anstatt einer Tabelle entnommen werden.

Interessanter ist das Problem mehrfachverschachtelter indirekter Sprünge. Manchmal lassen sich Schleifen in solch eine Folge rekursiver Sprünge darstellen und dann vielleicht auch kompilieren, sofern die Rekursion nicht erst zur Laufzeit aufgeht. Der Begriff Thread, ist ansich als Sprung zu verstehen: Thread-adress, indirect-thread, duble-indirect-thread, multi-threading, hyperthreading, usw. und dies sind nicht zuletzt auch die Adressierungsarten guter alter Interpreter. Hyperthreading ist kein echtes, aber quasi paralleles ausführen 2-er Sprünge. Hier wird der Zweite nicht blockiert bis der Erste erledigt ist, sonder wird in einem multitastkting schon mal in gang gesetzt und auch weiter geführt, falls der Erste ins stocken kommt. (letzteres soweit ich es verstanden habe.) Es sind aber keine 2 parallel ausgeführten Sprünge, wie es zumindest 2 parallel-arbeitende Prozessoren könnten. Es gab aber von Haris-Semikonductor einen Prozessor, der einen indirekten Sprung in einem Arbeitstakt konnte, der s.g. FORTH-Prozessor. D. h. Die Produktion einigermaßen brauchbarer Hardware-Interpreter, steht längst an und wurde nur absichtlich ausgebremst. Insbesondere Microsofs dot-net-technologie wird aber nun aufgrund des dortigen s.g. Just-In-Time-Compilers eine entsprechende Nachfrage bilden. Der JIT-Compiler läuft zur Laufzeit des Programms und ist dementsprechend definitionsgemäß eigentlich ein Interpreter. Ich ahne, daß Microsoft mit seiner dot-net-technik seinen schwersten Angriff gegen Linux fahren wird. Darauf komme ich aber später noch zurück.

Mit meinem Titel habe ich sicher polemisiert, aber Werbung und Aufmerksamkeit sind legitim.

Ich bin kein Experte für Compiler und stelle hier lediglich mein Verständnis zur Diskusion. Der GCC ich kenne ihn kaum, er erscheint aber immer wieder als Referenz und gibt nicht selten vergleichsweise gute Werte. Auch weis ich von jemanden, der die Sprache Forth mit dem GCC implementiert hat, anstatt wie bis dato üblich in Assembler und angeblich zu annähernd gleichguten Ergebnissen kam. Ich denke wir müssen gucken, wer GCC produziert und wartet. Und dort unser Interesse an einem guten Compiler deutlich machen. Aus meiner sicht dürfte es ggw. Am vorteilhaftesten sein zur Programmentwicklung den Borland C/C++ Compiler von Kylix 3 einzusetzen. Er verfügt über alle Werkzeuge und den unter Windows üblichen Komfort, jetzt auch als IDE unter Linux. Wärend Linux bisher quasi Konsolenanwendung war, ist es mit Kylix 3 möglich moderne graphische Programmoberflächen einfach in die Programme einzubauen. Kylix 3 gibt es auch in einer open source Version, bei Borland zum download, mit eingeschränktem Funktionsumfang. Sch... ist allerdings der Code dieses Compilers, riesig aufgebläht. Ich denke es ist sinnvol, die Borland-IDE zur Entwicklung zu nutzen, den Quellcode aber möglichst mit dem GCC, oder Intel zu compilieren. Sicher wird das aber auch noch Probleme schaffen.

Was wir zunächst unter Linux machen können, um gewappnet zu sein ist, den Assembler auf vorderman zu bringen. Das heißt auch ein Stück Unabhängigkeit bewahren. Meines Wissens haben Borland und Microsoft in gegenseitiger Absprache, und mangels Nachfrage ihre Assembler aus dem Verkauf genommen. Bei Microsoft habe ich nicht recherschiert, kann mir aber nicht vorstellen, daß der MASM jetzt open source ist. Im übrigen bedarf das Programm Hallo World unter Kylix 3- C++ 562 928 Beytes; „24 Beytes“ groß ist dagegen der Debug des Assemblerprogramms und 12 926 beytes unter GCC 32.

Auf die Stärken und Schwächen des dot-netsystem so wie sie mir erscheinen komme ich nocheinmal später zu sprechen.

Gruß Thomas


P/S Ich meine die Compiler-Oberfläche zur einer vereinfachten Bedienung, nicht den Übersetzer selbst.

[meisterthomas]

Meine o. abgegebene Definition, kompilierbarer Schleifen ist falsch. Der o. g. Sinn würde für High-Level Abbruchbedingungen zutreffen, die ein Interpreter abfragt, z B. in der Künstlichen Intelligenz.

Selbstverständlich sollten sämmtliche Schleifen, deren Abruchbedingungen sich in Assembler eindeutig beschreiben lassen auch kompilierbar sein.


Sorry, war wohl letzte Nacht doch etwas übermüdet.

Thomas

[Schaf]

@thomas: afaik wird masm weiterentwickelt, oder zumindest versionstechnisch auf level des devstudio 6 festgehalten. open source ist bei meikro$oft keine größere software. schließlich ist masm ein sehr weitläufiges m$-projekt, dass es schon seit den 80ern gibt, und ich hier noch als 8bit-version für cp/m stehen habe ;) das würden die bestimmt nicht einfach so freigeben. [ohne gewehr]

[Jan Krüger]

Huch, die erste Reaktion auf meinen ersten Post total übersehen... :eek:

Ich habe mich mit Compilerbau nur bis vor die Phase der Optimierung beschäftigt und kann von daher nicht behaupten, dass ich viel Ahnung davon hätte, was die Compiler da so eigentlich alles anstellen. Soweit ich das, was du gesagt hast, nachvollziehen kann, kommt es mir sehr schlüssig vor.

Ich betrachte GCC (entwickelt vom GNU-Projekt) als DEN (Linux-)Compiler schlechthin. Er läuft auf allen nennenswerten Plattformen (wenn wir Cygwin als Windows oder MinGW gelten lassen) und Architekturen, und ich habe irgendwie noch nie Kritik an ihm gehört (abgesehen davon, dass er immer größer und unüberschaubarer wird ;)).
Ich denke mal, die Tatsache, dass das GNU-Projekt den GCC entwickelt, spricht dafür, dass man die Aktivität der Entwickler nicht weiter mitverfolgen muss (wie auch immer man zum GNU-Projekt steht, die Leute sind sehr engagiert und haben hohe Standards (hab ich gehört)).

Was Compileroberflächen angeht, kann ich schon wieder nichts sagen, weil ich nämlich keine benutze. Ich fand allerdings die Delphi-Oberfläche (ahh, those were the days... ;)) überzeugend (und der Borland-Compiler war *schnell*...).
Deine Größenangaben zu den Binares sind übrigens nicht unbedingt aussagekräftig - hast du beim Erstellen des Borland-Binaries die CLX (das war der Name des Linux-Pendants zu VCL, richtig?) mit eingebunden?

Schlussendlich gibt es genügend Assembler unter Linux, von denen einige durchaus aktiv entwickelt werden. Dazu gehören unter anderem gas (der GNU-Assembler) und nasm (naja, letztes Release März 2003).

Und jetzt muss ich leider in's Bett.

[Schaf]

meinst du das buch "compilerbau" von niklaus wirth? ich denke mal, dass sein pl/0-compiler nicht so wirklich gut optimieren kann ;) habe auch kein kapitel zum thema optimirieung gefunden. dass der GCC immer größer und unüberschaubarer wird, finde ich auch recht unpraktisch. man kann ihn z.b. nicht mal eben auf ein paar floppies packen, und auf einen cd-rom-losen rechner installieren. selbst die minix-version ist 7 floppies (typ 1440k) groß :( und das, obwohl es sich nur um den gcc (also den c-compiler des GCC) handelt ... und er ist zwar sehr gut optimierend, aber auch nicht grade schnell. der borland bcp 5.5 ist immernoch der schnellste, den ich je gesehen habe - und ist ein c++-compiler! allerdings weiss ich nicht, wie optimiert sein output ist.

[Jan Krüger]

Felix hat mir versichert, dass zumindest der Object-Pascal-Compiler von Borland sehr gut optimiert, und ich wüsste nicht, warum das beim C++-Compiler anders sein sollte.

[Schaf]

na hauptsache man stellt den object-pascal-compiler von der standardeinstellung p-code auf maschinencode, sonst kann man gleich vb benutzen :D ;)

[Jan Krüger]

Die letzte Version, die ich benutzt habe, hat noch gar keinen P-Code benutzt... tja, alles geht irgendwie den Bach runter. ;)

[Schaf]

p-code gabs schon seit version 4, wenn nicht noch früher :D

[Jan Krüger]

Ja, und ich hab Version 3 benutzt. :D

[Schaf]

das waren noch zeiten *g* kann mich noch an die vbx-controls erinnern, die borland damals von vb geklaut hatte :D das war bei version 1, und bei zwei sind die langsam umgestiegen