Hi Liste,
angeregt durch die Diskussionen zur Softwarebeschleunigung habe ich ein bisschen mit den Compileroptionen experimentiert. Jedoch bringt nur die Option -O3 einen Geschwindigkeitsgewinn. Ansonsten ist das Programm für den 486 genauso schnell wie das für den 686.
2m1.527s # kein Optimierung -O3 1m28.125s -O3 -Di586 1m28.700s -O3 -Di686 1m28.189s
Sind die Optionen für den Pentium und höher nur Dummies, oder liegt das an dem sehr einfach gestrickten Programm? Das Programm rechnet in vielen Schleifen mit noch mehr Funktionsaufrufen nur einige Winkelfunktionen und Wurzeln aus. Vermutlich bringt eine Verbesserung des Codes mehr als ein $Wundercompiler, aber davon habe ich _keine_ Ahnung.
Achso, das ganze läuft unter Suse 7.3 mit gcc version 2.95.3 20010315 auf einem 700-ter Athlon
Jens Weiße
Hallo,
On Thursday, 11. April 2002 17:13, Jens Weiße wrote:
angeregt durch die Diskussionen zur Softwarebeschleunigung habe ich ein bisschen mit den Compileroptionen experimentiert. Jedoch bringt nur die Option -O3 einen Geschwindigkeitsgewinn. Ansonsten ist das Programm für den 486 genauso schnell wie das für den 686.
Vielleicht ist der Source mit -O3 schon so optimiert, daß es nichsts gibt, was ein 486 schlechter als ein 686 könnte. Oder aber der gcc erkennt nichts, was er besser machen könnte.
Sind die Optionen für den Pentium und höher nur Dummies, oder liegt das an dem sehr einfach gestrickten Programm? Das Programm rechnet in vielen Schleifen mit noch mehr Funktionsaufrufen nur einige Winkelfunktionen und Wurzeln aus. Vermutlich bringt eine Verbesserung des Codes mehr als ein $Wundercompiler, aber davon habe ich _keine_ Ahnung.
Naja, macht dein Programm das selber oder nutzt es z.B. die Wurzelfunktion von der libc/libm? Dann passiert nämlich folgendes: Die Bibliotheksfunktion selber ist normalerweise nur für i386 kompiliert worden, und zur Compilierzeit ist nur daß -O3 ausschlaggebend, weil es (sofern ich mich recht erinnere) inline-Funktionen erzwingt.
Achso, das ganze läuft unter Suse 7.3 mit gcc version 2.95.3 20010315 auf einem 700-ter Athlon
Der kann, im Gegensatz zum neuen gcc-3.0, beispielsweise noch kein -march=athlon/-mcpu=athlon. Wobei die richtig guten Athlon-Optimierungen erst mit dem gcc 3.1 kommen werden.
Josef Spillner (der sowas über $DEBIAN_BUILDARCH regelt)
On Thu, 11 Apr 2002 17:51:19 +0200, Josef Spillner wrote: Hallo Joseph,
Josef Spillner (der sowas über $DEBIAN_BUILDARCH regelt)
Wobei ich die Realisierung durch pentium-builder doof finde. Solche Optimierungen sollten von den Makefiles der Pakete gemacht werden statt durch einen gcc-Wrapper. Irgendwann haben wir sonst den WrapperWrapperWrapperWrapper zu gcc und keiner ahnt mehr, wie der gcc letzendlich wirklich aufgerufen wird.
Ist bei Debian was in Arbeit, um die Optimierung auf bestimmte CPUs sauber zu lösen? Man könnte beispielweise festlegen, daß der Build-Prozess $DEBIAN_BUILDARCH auswerten soll.
Reinhard
Tag,
On Thursday, 11. April 2002 19:04, Reinhard Foerster wrote:
Wobei ich die Realisierung durch pentium-builder doof finde. Solche Optimierungen sollten von den Makefiles der Pakete gemacht werden statt durch einen gcc-Wrapper. Irgendwann haben wir sonst den WrapperWrapperWrapperWrapper zu gcc und keiner ahnt mehr, wie der gcc letzendlich wirklich aufgerufen wird.
Bei mir ist das ja schon so, wenn ich den color-gcc verwende (z.B. immer dann wenn ich viel mit STL zu tun hab, weil jede Fehlermeldung dort gleich 5 Terminalseiten belegt wegen der vielen Templates). Und dann ist beim gcc wiederum wählbar, ob der entweder auf gcc-2.95 oder gcc-3.0 zeigt (beim g++ dasselbe). Also eine Kette: gcc: Symlink auf colorgcc colorgcc: Wrapperskript für builder-cc builder-cc: Wrapperskript auf gcc(-2.95,3.0).real Der colorgcc muß aber angepasst werden, einfach die Hash-Werte für die Compilernamen ändern, sonst ruft er wieder 'gcc' (sich selbst) auf...
Eine andere Realisierung dürfte schwer sein, da es ja transparent für alle Beteiligten sein muß. Es gibt noch mehr solche Situationen, z.B. Crosscompiler, und /usr/bin/cc ist ja auch nochmal ein Symlink.
Ist bei Debian was in Arbeit, um die Optimierung auf bestimmte CPUs sauber zu lösen? Man könnte beispielweise festlegen, daß der Build-Prozess $DEBIAN_BUILDARCH auswerten soll.
Also wenn ich meine Pakete baue, dann hab ich das konsequent auf i386 gestellt weil ich sonst böse Mails bekommen würde :)
Bisher sind ja die wenigsten Pakete optimiert (z.B. kernel-image-xxx für xxx Element aus {386,586,686,k6,k7}), wobei man das Problem hat daß die Kombination von Features nur eingeschränkt möglich ist. Alles andere würde zu einer Paketexplosion führen. Andere Pakete bekommt man also nur vom Source optimiert, und dafür ist configure zuständig, was ja einen String wie i586-pc-gnu-linux liefert was dann ausgewertet wird. Ein Beispiel dafür ist aRts von KDE (Werbung, Werbung), wo MMX-Optimierung zur Konfigurationszeit bestimmt wird.
Es gibt ja Überlegungen für Debian, sowas wie BSD-Ports über apt-get bereitzustellen. Beispielsweise gibt man ein apt-get source-autobuild mozilla und der holt die Quellen des Paketes und der Abhängigkeiten, kompiliert die im Hintergrund durch und schickt dann eventuell eine Mail wenn's fertig ist, so daß man nur noch apt-get install-autobuild eingeben muß und dann alles installiert wird. Oder so ähnlich ;)
Jetzt könnte man wieder diskutieren ob man jegliches Paket so optimieren muß, aber für alles was ständig aktiv ist (Kernel, glibc, X11, ...) lohnt sich sowas sicher.
Josef Spillner
Am Donnerstag, dem 11. April 2002 um 20:02:07, schrieb Josef Spillner:
apt-get source-autobuild mozilla
Meinst du:
# apt-get build-dep mozilla # apt-get source -b mozilla
Gibt es schon. Oder meinst du, dass auch alle Build-Dependencies automatisch gebaut werden sollen? Scheint mir ineffizient.
Torsten
On Thursday, 11. April 2002 20:31, Torsten Werner wrote:
Meinst du:
# apt-get build-dep mozilla # apt-get source -b mozilla
Ui, wieder was neues gelernt.
Gibt es schon. Oder meinst du, dass auch alle Build-Dependencies automatisch gebaut werden sollen? Scheint mir ineffizient.
Die Builddeps sicher nicht, weil das ja z.B. bei mir auch gettext und tetex-bin und die Autotools sind/waren, die für die Programmgeschwindigkeit keine Rolle spielen. Die reinen Dependencies dagegen schon. Also apt-get source -b in dem Fall. Wobei man halt einen Wrapper schreiben könnte (hier isser wieder), der bereits vorhandene Abhängigkeiten nochmal mit --reinstall saugt, damit nicht nur die Programmoberfläche optimiert ist während die Funktionalität noch mit i386 vor sich hindackelt.
Wobei man natürlich den Mozilla nie und nimmer schnell machen kann :)
Josef Spillner
On Thu, 11 Apr 2002 20:31:30 +0200, Torsten Werner wrote:
# apt-get source -b mozilla
Wie schafft man es, daß an der Stelle fakeroot genutzt wird? Ich bekomme so kein .deb hin und baue dehalb mit
apt-get source paket cd paket-x.y debuild cd .. dpkg -i *.deb
Und noch eine Frage zu Paketen mit gleichen Versionnummern:
Ich habe bzip2-1.0.2-1 installiert. Ganz normal das binary von debian. Nun sauge ich mir mal die source dazu, baue das Paket neu und installiere es. (gleiche Version, Vorgehen wie oben beschrieben)
Beim nächsten apt-get upgrade wird mein gerade installiertes, selbstgebautes Paket wieder durch das vom FTP-Sever ersetzt. Warum?
Wieso ist mein Eigenbau schlechter/älter als das Paket aus dem Netz?
Reinhard
Am Donnerstag, dem 11. April 2002 um 22:43:55, schrieb Reinhard Foerster:
On Thu, 11 Apr 2002 20:31:30 +0200, Torsten Werner wrote:
# apt-get source -b mozilla
Wie schafft man es, daß an der Stelle fakeroot genutzt wird?
$ fakeroot apt-get source -b mozilla
Beim nächsten apt-get upgrade wird mein gerade installiertes, selbstgebautes Paket wieder durch das vom FTP-Sever ersetzt. Warum?
Das darft im Normalfall nicht passieren. Hast du irgendwie --reinstall benutzt (apt.conf beachten)?
Torsten
On Fri, 12 Apr 2002 08:30:10 +0200, Torsten Werner wrote: Hallo Torsten,
Beim nächsten apt-get upgrade wird mein gerade installiertes, selbstgebautes Paket wieder durch das vom FTP-Sever ersetzt. Warum?
Das darft im Normalfall nicht passieren. Hast du irgendwie --reinstall benutzt (apt.conf beachten)?
Nö. Einzige Option für apt ist bei mir DPkg::Pre-Install-Pkgs {"/usr/sbin/dpkg-preconfigure --apt || true";};
--reinstall wirkt bei "apt-get upgrade" sowieso nicht denk ich mal. Sonst müßte er bei jedem update alles ersetzen.
Ich habs nochmal mit anderen paketen probiert (gzip, openssl). Jedesmal wird mein selbstgebautes Zeug beim "apt-get upgrade" wieder durch die gleiche Version vom FTP ersetzt.
Bsp: root@boss:/home/rf11/tmp> apt-get upgrade Reading Package Lists... Done Building Dependency Tree... Done 0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
rf11@boss:~/tmp> dpkg -l gzip ii gzip 1.3.2-3 The GNU compression utility.
rf11@boss:~/tmp> fakeroot apt-get -b source gzip ... rf11@boss:~/tmp> ls -la *.deb -rw-r--r-- 1 rf11 users 61616 Apr 12 11:23 gzip_1.3.2-3_i386.deb rf11@boss:~/tmp>
root@boss:/home/rf11/tmp> dpkg -i gzip_1.3.2-3_i386.deb (Reading database ... 48673 files and directories currently installed.) Preparing to replace gzip 1.3.2-3 (using gzip_1.3.2-3_i386.deb) ... Unpacking replacement gzip ... Setting up gzip (1.3.2-3) ...
root@boss:/home/rf11/tmp> apt-get upgrade Reading Package Lists... Done Building Dependency Tree... Done 1 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 61.7kB of archives. After unpacking 8192B will be freed. Do you want to continue? [Y/n] y Get:1 http://ftp.de.debian.org woody/main gzip 1.3.2-3 [61.7kB] Fetched 61.7kB in 0s (1631kB/s) (Reading database ... 48673 files and directories currently installed.) Preparing to replace gzip 1.3.2-3 (using .../archives/gzip_1.3.2-3_i386.deb) ... Unpacking replacement gzip ... Setting up gzip (1.3.2-3) ...
root@boss:/home/rf11/tmp>
Ist das bei dir nicht so? Der einzige Unterschied zwischen meinem Paket und dem vom FTP sollte die bei mir fehlende pgp-signatur sein.
Dehalb muß ich auf Athlon optimierte Pakete extra auf hold setzten um sie nicht gleich wieder zu verlieren :-(
Reinhard
Am Freitag, dem 12. April 2002 um 11:36:05, schrieb Reinhard Foerster:
Ist das bei dir nicht so?
Doch ist bei mir auch so. Ich bin verwirrt. Work around: Generiere vor dem Übersetzen des Pakets mittels 'dch -i' eine neue Debian-Sub-Version, dann wird dein Paket erst überschrieben, wenn es eine höhere Version auf dem Server gibt.
Torsten
On Fri, 12 Apr 2002 12:35:32 +0200, Torsten Werner wrote:
Am Freitag, dem 12. April 2002 um 11:36:05, schrieb Reinhard Foerster:
Ist das bei dir nicht so?
Doch ist bei mir auch so. Ich bin verwirrt. Work around: Generiere vor dem Übersetzen des Pakets mittels 'dch -i' eine neue Debian-Sub-Version, dann wird dein Paket erst überschrieben, wenn es eine höhere Version auf dem Server gibt.
Ich habe mal auf debian-user-german@lists.debian.org nachgefragt und eine sehr umfassende Antwort bekommen, auch zur genauen Versionierung.
Message-ID: 20020412122153.GA30115@chuzpe.logic.univie.ac.at
Reinhard
Am Freitag, dem 12. April 2002 um 15:16:24, schrieb Reinhard Foerster:
Ich habe mal auf debian-user-german@lists.debian.org nachgefragt und eine sehr umfassende Antwort bekommen, auch zur genauen Versionierung.
Das Archiv wird zwar nur täglich aktualisiert, sollte nun aber deine Mail enthalten. Ich finde sich trotzdem nicht. :-(
Torsten
On Thu, 11 Apr 2002 20:02:07 +0200, Josef Spillner wrote:
Eine andere Realisierung dürfte schwer sein, da es ja transparent für alle Beteiligten sein muß.
Sicher ist eine andere Realisierung schwerer. Ich finds aber blöd, wenn der Aufruf von gcc auf jedem System was anderes tut.
Wer Farben oder andere defaults fürs Optimieren will, muß halt was anderes aufrufen z.B. 'colorgcc' oder man baut den Wrapper so, daß man den "normalen" gcc-Aufruf komplett hinter dem Wrapper schreibt. Der diet-Wrapper von der dietlibc ist ein Beispiel dafür. Der will mit "diet gcc ..." aufgerufen werden.
Also wenn ich meine Pakete baue, dann hab ich das konsequent auf i386 gestellt weil ich sonst böse Mails bekommen würde :)
Ja, das ist ok. Die Pakete stellen alle explizit i386 ein. Bei normalen .tar.gz-Paketen mit autoconf reicht setzen von $CFLAGS vorm ./configrure. Das ist bei Debians Paketen außer Kraft gesetzt. Also muß man sich was einfallen lassen.
Bisher sind ja die wenigsten Pakete optimiert (z.B. kernel-image-xxx für xxx Element aus {386,586,686,k6,k7}), wobei man das Problem hat daß die Kombination von Features nur eingeschränkt möglich ist. Alles andere würde zu einer Paketexplosion führen.
Extra binary-Archive für Pentium oder Athlon seitens Debian finde ich auch sinnlos. Letzlich sind die aktuellen Rechner so schenll, daß sie beim update notfalls allles neubauen können. Das könnte man in apt einbauen.
Andere Pakete bekommt man also nur vom Source optimiert, und dafür ist configure zuständig, was ja einen String wie i586-pc-gnu-linux liefert was dann ausgewertet wird.
Eben. Grundsätzlich muß configure die Stelle bleiben, bei der der Wunsch nach bestimmten Optionen angemeldet werden muß. (indem man CFLAGS CXXFLAGS vorm Aufruf von configure entsprechend setzt)
Unterschieben von Optionen durch einen gefakten gcc ist böse weil:
Der Autor des Upstream-Pakets sollte letzlich das letzte Wort zu den beim Compilieren verwendeten Optionen haben. Der Upstream Autor muß die Chance behalten, bei einigen Files nur ganz bestimmte Flags zuzulassen. Er kann z.B. beim Compilieren eines einzigen Files seines Pakets die CFLAGS ignorieren weil er genau weiß, daß dieses File wegen eines gcc-Bugs mit -march=pentium Schrott wird. Mit dem Wrapper des pentium-builders hat der Upstream Autor diese Chance nicht mehr und der Debian-Maintainer hat die Arbeit.
Ich würde mir 2 Dinge wünschen: 1. ein Konfigfile in /etc welches die default Optionen für auf diesem Rechner gebaute Debian-Pakete enthält. Steht da nix drin, wird so gebaut wie bisher (also für die alten Systeme wie i386 oder sparcv7)
Diese Optionen dürfen NUR beim Bauen von Debian-Paketen aktiv werden, NICHT wenn ein Nutzer einfach mal "gcc hello.c" sagt!!!!!!!!
2. einen zu "apt-get apdate; apt-get upgrade" ähnlichen Aufruf von apt, der alle neu zu installierenden Paket als Source saugt und mit den in /etc definierten Flags baut und installiert. Vielleicht einfach als Option in die apt.conf um weiter "apt-get apdate; apt-get upgrade" nutzen zu können.
Es gibt ja Überlegungen für Debian, sowas wie BSD-Ports über apt-get bereitzustellen. Beispielsweise gibt man ein apt-get source-autobuild mozilla und der holt die Quellen des Paketes und der Abhängigkeiten, kompiliert die im Hintergrund durch und schickt dann eventuell eine Mail wenn's fertig ist, so daß man nur noch apt-get install-autobuild eingeben muß und dann alles installiert wird. Oder so ähnlich ;)
So meinte ich das auch.
Jetzt könnte man wieder diskutieren ob man jegliches Paket so optimieren muß, aber für alles was ständig aktiv ist (Kernel, glibc, X11, ...) lohnt sich sowas sicher.
Denk ich auch.
Reinhard
Am Donnerstag, 11. April 2002 17:51 schrieb Josef:
Vielleicht ist der Source mit -O3 schon so optimiert, daß es nichsts gibt, was ein 486 schlechter als ein 686 könnte. Oder aber der gcc erkennt nichts, was er besser machen könnte.
Das kann sein. Jedoch wäre eine _richtige_ Geschwindigskeitssteigerung recht praktisch :-) Denn die Zeiten bezogen sich auf einen einzigen Durchlauf. Etwa 500 bis 600 weitere Durchläufe sollte das Programm am Stück machen.
Sind die Optionen für den Pentium und höher nur Dummies, oder liegt das an dem sehr einfach gestrickten Programm? Das Programm rechnet in vielen Schleifen mit noch mehr Funktionsaufrufen nur einige Winkelfunktionen und Wurzeln aus. Vermutlich bringt eine Verbesserung des Codes mehr als ein $Wundercompiler, aber davon habe ich _keine_ Ahnung.
Naja, macht dein Programm das selber oder nutzt es z.B. die Wurzelfunktion von der libc/libm?
Alles Standardfunktionen aus dem Lieferumfang #include<iostream> #include<cmath> #include<vector> #include<fstream> #include<string> (Ich kann's definitiv auch nicht besser, als diese Bibliotheken :-( )
Dann passiert nämlich folgendes: Die Bibliotheksfunktion selber ist normalerweise nur für i386 kompiliert worden, und zur Compilierzeit ist nur daß -O3 ausschlaggebend, weil es
So ein Murks. Wie bekommt man nun elegant die gesamten Bibliotheken unter Suse kompiliert und installiert?
(sofern ich mich recht erinnere) inline-Funktionen erzwingt.
Du hast keine Alzheimer :-) -O3 Optimize yet more. This turns on everything -O2 does, along with also turning on -finline-functions.
Achso, das ganze läuft unter Suse 7.3 mit gcc version 2.95.3 20010315 auf einem 700-ter Athlon
Der kann, im Gegensatz zum neuen gcc-3.0, beispielsweise noch kein -march=athlon/-mcpu=athlon. Wobei die richtig guten Athlon-Optimierungen erst mit dem gcc 3.1 kommen werden.
Josef Spillner (der sowas über $DEBIAN_BUILDARCH regelt)
^^^^^^^^^^^^^^^^^^^^^^^ Das wird mir mit meiner Susi nicht wirklich helfen. Ausser ich plätte die komplett und mach was anderes auf die Platte. Wann kommt denn Debian 3.0 auf den (OpenSource-)Markt?
Jens Weiße
On 12.04.02 Jens Weiße (jens.weisse@gmx.net) wrote:
Wann kommt denn Debian 3.0 auf den (OpenSource-)Markt?
Anthony Towns (Release-Manager von woody) hat vom 1. 5. 2002 geredet. Ich glaub aber noch nicht so richtig dran.
H.
On Thu, 11 Apr 2002 17:13:52 +0200, Jens Weiße wrote:
angeregt durch die Diskussionen zur Softwarebeschleunigung habe ich ein bisschen mit den Compileroptionen experimentiert. Jedoch bringt nur die Option -O3 einen Geschwindigkeitsgewinn. Ansonsten ist das Programm für den 486 genauso schnell wie das für den 686.
2m1.527s # kein Optimierung-O3 1m28.125s -O3 -Di586 1m28.700s -O3 -Di686 1m28.189s
Sind die Optionen für den Pentium und höher nur Dummies, oder liegt das an dem sehr einfach gestrickten Programm?
-Di586 hat nicht direkt was mit dem Compiler zu tun. Es definiert nur das Symbol i586, wodurch u.U. im Code per #ifdef eine angepaßte Variante aktiviert wird.
vielen Schleifen mit noch mehr Funktionsaufrufen nur einige Winkelfunktionen und Wurzeln aus. Vermutlich bringt eine Verbesserung des Codes mehr als ein $Wundercompiler, aber davon habe ich _keine_ Ahnung.
Such einfach mal das Stück Code, was durch -Di586 aktiviert wird. Das wird wohl die innere Schleife sein, auf die es ankommt. Eventuell ist das Stück schon is asm geschrieben. Dann bringt der Compiler nix mehr.
Ist es noch C-Code wäre ein Versuch mir Intels C-Compiler zu empfehlen. Winkelfunktionen und Wurzeln sind FPU-Zeugs. An der Stelle ist der gcc vergleichsweise schlecht. (Ich erinnere mich an einen c't/iX-Artikel, bei dem povray mit intels cc genau doppelt so schnell war im Vergleich zum gcc-Output. Alledings auf P4. Keine Ahnung, wie athlonfreundlich Intels cc ist.)
Reinhard
lug-dd@mailman.schlittermann.de
-
Hilmar Preusse -
Jan Rakelmann -
Jens Weiße -
Josef Spillner -
Reinhard Foerster -
Torsten Werner