Damit ist wohl die Geschwindigkeit des eigentlichen Linkvorganges gemeint (und der dauerd sowieso nicht allzu lange im Vergleich zu Compilezeit). Ich finde das etwas Zweideutig geschrieben. Faktor 5 bei der Laufzeit wäre ja...eben unglaublich.
Der Linker arbeitet 5mal schneller als der bisherige Linker. Natürlich ist normalerweise die Compile-Zeit wesentlich länger. Wenn man aber entwickelt und z.B. nur Änderungen an einer einzigen Datei vorgenommen hat, kann das Linken beim Nachfolgenden Kompiliervorgang wesentlich länger dauern als das Kompilieren.
Aber wenn dynamisches anstatt statisches Linken verwendet wird (ist heute ja AFAIK nicht unüblich), dann sollte sich der Performance-Gewinn doch auch beim Starten von Anwendungen bemerkbar machen, oder?
Beim statischen linken werden keine Relocationseinträge erzeugt, daher ist es unabhängig von ld-linux.so. Rein statische programme werden einfach ge-mmapt.
Beim statischen linken werden keine Relocationseinträge erzeugt, daher ist es unabhängig von ld-linux.so. Wie kommst du auf statisch gelinkte Programme? Steffen fragte, ob die Verbesserungen des Linkers den Start von dynamisch gelinkten Anwendungen beschleunigen würden.
Bei uns wird die Applikation grundsätzlich statisch gelinkt, da sie später so auch ausgeliefert wird. Da es sich dabei um viel Code handelt dauert das Linken mehrere Minuten. Für den täglichen Dreisprung Editieren/Übersetzen/Linken wäre eine Verbesserung um Faktor 5 ein Quantensprung.
Daher wäre das für mich die wichtigste Verbesserung der GNU/Linux Entwicklungsumgebung seit Jahren.
Der Compiler übersetzt den Quellcode eines Programms in Maschinencode. Der Computer kann damit aber noch nichts anfangen, zuerst muss der Linker die vielen Dateien mit dem Maschinencode sowie externe Bibliotheken etc. in eine ausführbare Datei packen.
es geht um das Linken der dynamischen Bibliotheken beim Start einer Anwendung bzw zur Laufzeit. Speziell C++ Anwendungen sind mit vielen Bibliotheken verlinkt. Stichwort 'Prelinking'.
Wenn das nicht multithreaded ist (nein linking ist nicht wirklich IO lastig, erst recht nicht mit SSD Disks) dann sollte man das lieber einstampfen und nicht freigeben.
Linking hat heutzutage einen erheblichen Anteil an der Compilezeit (insbesondere wenn man nicht von Krankheiten wie GCC befallen ist).
ICC? ja nett, wenn man einen Intel sein eigen nennt, aber abseits davon ein witz. Borland || Microsoft || Digital Mars? ja nett, wenn man Windows sein eigen nennt, aber abseits ein witz. Sun? ja nett, wenn man eine Solaris sein eigenen nennt, aber abseits ein witz. Watcom? ja nett, wenn man ein x86 sein eigen nennt, aber abseits ein witz.
Es gibt für jede Plattform jeweils mindestens einen besseren Compiler. Der aber jeweils weder frei noch kostenlos ist. Zudem dürfte es in vielen Fällen Probleme geben, den Linux-Kernel zu kompilieren, da dieser stark auf Eigenheiten der GCC baut.
Nichts für ungut, aber diese Fähigkeit find ich auf Sun oder Windows sinnlos. Aber sicher nicht unter Linux. Auf Solaris würde ich den Sun-Compiler verwenden, unter Windows den MSVC++.
Ob der Frei oder Kostenlos ist mir ehrlich gesagt scheiss egal. Wenn er gut ist zahle ich dafür einen angemessenen Preis.
Jeden Scheiss nur gut zu finden weil er nichts kostet ist pubertierender Hartz IV Mist. Ich arbeite und will dafür Tools. Tatsache unter Linux gibts aufgrund der Existenz des GCC keinene anderen wirklichen Compiler. LCC-linux ist noch nicht zu weit.
Ob der Frei oder Kostenlos ist mir ehrlich gesagt scheiss egal. Dann nimm einen der kostenpflichten Compiler.
Jeden Scheiss nur gut zu finden weil er nichts kostet ist pubertierender Hartz IV Mist. Du kannst nicht von einem OpenSource-Betriebssystem erwarten, dass ClosedSource-Compiler bevorzugt werden. Es ist wohl klar, dass man sich nicht bei einer so wichtigen Komponente an einen Hersteller bindet.
Tatsache unter Linux gibts aufgrund der Existenz des GCC keinene anderen wirklichen Compiler. Doch, beispielsweise von Intel und PathScale (2000 USD pro User).
Ja, aber nicht wegen der Aussage, sondern wegen des offensichtlichen Mangels an Recherche :)
> Wenn das nicht multithreaded ist (nein linking ist nicht wirklich IO lastig, erst recht nicht mit > SSD Disks) dann sollte man das lieber einstampfen und nicht freigeben.
Er ist multithreaded. Siehe z.B.: http://www.airs.com/blog/archives/78
(und der dauerd sowieso nicht allzu lange im Vergleich zu Compilezeit).
Ich finde das etwas Zweideutig geschrieben. Faktor 5 bei der Laufzeit
wäre ja...eben unglaublich.
Natürlich ist normalerweise die Compile-Zeit wesentlich länger. Wenn man aber entwickelt und z.B. nur Änderungen an einer einzigen Datei vorgenommen hat, kann das Linken beim Nachfolgenden Kompiliervorgang wesentlich länger dauern als das Kompilieren.
Beim statischen linken werden keine Relocationseinträge erzeugt, daher ist es unabhängig von ld-linux.so.
Rein statische programme werden einfach ge-mmapt.
es geht nicht um statisch, sondern um dynamisch!
Wie kommst du auf statisch gelinkte Programme? Steffen fragte, ob die Verbesserungen des Linkers den Start von dynamisch gelinkten Anwendungen beschleunigen würden.
Daher wäre das für mich die wichtigste Verbesserung der GNU/Linux Entwicklungsumgebung seit Jahren.
Schöne Grüße
Mark
Ich denke das sollte im Ansatz auch für den Laien verständlich sein
Es geht um das statische Linken.
Wenn das nicht multithreaded ist (nein linking ist nicht wirklich IO lastig, erst recht nicht mit SSD Disks) dann sollte man das lieber einstampfen und nicht freigeben.
Linking hat heutzutage einen erheblichen Anteil an der Compilezeit (insbesondere wenn man nicht von Krankheiten wie GCC befallen ist).
ICC? ja nett, wenn man einen Intel sein eigen nennt, aber abseits davon ein witz.
Borland || Microsoft || Digital Mars? ja nett, wenn man Windows sein eigen nennt, aber abseits ein witz.
Sun? ja nett, wenn man eine Solaris sein eigenen nennt, aber abseits ein witz.
Watcom? ja nett, wenn man ein x86 sein eigen nennt, aber abseits ein witz.
Tendenz
Der aber jeweils weder frei noch kostenlos ist. Zudem dürfte es in vielen Fällen Probleme geben, den Linux-Kernel zu kompilieren, da dieser stark auf Eigenheiten der GCC baut.
Nichts für ungut, aber diese Fähigkeit find ich auf Sun oder Windows sinnlos.
Aber sicher nicht unter Linux. Auf Solaris würde ich den Sun-Compiler verwenden, unter Windows den MSVC++.
Wenn er gut ist zahle ich dafür einen angemessenen Preis.
Jeden Scheiss nur gut zu finden weil er nichts kostet ist pubertierender Hartz IV Mist.
Ich arbeite und will dafür Tools. Tatsache unter Linux gibts aufgrund der Existenz des GCC keinene anderen wirklichen Compiler. LCC-linux ist noch nicht zu weit.
Dann nimm einen der kostenpflichten Compiler.
Jeden Scheiss nur gut zu finden weil er nichts kostet ist pubertierender Hartz IV Mist.
Du kannst nicht von einem OpenSource-Betriebssystem erwarten, dass ClosedSource-Compiler bevorzugt werden. Es ist wohl klar, dass man sich nicht bei einer so wichtigen Komponente an einen Hersteller bindet.
Tatsache unter Linux gibts aufgrund der Existenz des GCC keinene anderen wirklichen Compiler.
Doch, beispielsweise von Intel und PathScale (2000 USD pro User).
Ja, aber nicht wegen der Aussage, sondern wegen des offensichtlichen Mangels an Recherche :)
> Wenn das nicht multithreaded ist (nein linking ist nicht wirklich IO lastig, erst recht nicht mit
> SSD Disks) dann sollte man das lieber einstampfen und nicht freigeben.
Er ist multithreaded. Siehe z.B.: http://www.airs.com/blog/archives/78
...na dann warten wir mal ab, wann der (bayrische?) Verfassungsschutz auf diesen aufmerksam wird...
;-)
CNR!
Bussi!