Hallo Linuxfriends, hier ging vor kurzem ein Thread über obiges Thema. Ich habe dazu mal ein paar Fragen. Laut "Get Acquainted with Linux Security and Optimization System" sind folgende CompilerFlags besonders auf Optimierung ausgelegt. Pentium II: CFLAGS= -O9 -funroll-loops -ffast-math -malign-double -mcpu=pentiumpro -march=pentiumpro -fomit- frame-pointer -fno-exceptions Pentium: CFLAGS= -O3 -march=pentium -mcpu=pentium -ffast-math -funroll-loops -fomit-frame-pointer -fforce- mem -fforce-addr -malign-double -fno-exceptions Wäre folgendes möglich: Flags in /etc/profile.local eintragen und exportieren. Sourcen von verschiedenen Softwarepaketen installieren. (zum Beispiel: KDE-Packages) Und dann mit RPM neukompilieren: rpm -ba /usr/src/packages/SPECS/k....spec Und dann Paket updaten: rpm -U /usr/doc/packages/RPMS/i386/k.....rpm Stell ich mir die Sache zu einfach vor? Kann es zu unvorhergesehenen Komplikationen mit den optimierten Paketen kommen und wenn ja warum? Bringt es Geschwindigkeitsvorteile oder lohnt der Aufwand nicht? P.S. Es geht hier nicht, um die Frage warum SuSE AG keine pentiumoptimierte Distribution ausliefert, das wurde plausibel erläutert. Thanks for any comments :-) -- MfG Waldemar Brodkorb Linux rulez! --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hallo Waldemar Brodkorb,
Laut "Get Acquainted with Linux Security and Optimization System"sind folgende CompilerFlags besonders auf Optimierung ausgelegt.
Wo steht das? Würde ich auch gerne mal lesen.
Wäre folgendes möglich: Flags in /etc/profile.local eintragen und exportieren. Sourcen von verschiedenen Softwarepaketen installieren. (zum Beispiel: KDE-Packages) Und dann mit RPM neukompilieren: rpm -ba /usr/src/packages/SPECS/k....spec Und dann Paket updaten: rpm -U /usr/doc/packages/RPMS/i386/k.....rpm
Stell ich mir die Sache zu einfach vor?
Nein, sollte bei den meisten Paketen gehen. Es werden aber in manchen Spec-Files, oder in manchen Makefiles die Flags explizit gesetzt. Da muß man dann an den betreffenden Stellen eingreifen.
Kann es zu unvorhergesehenen Komplikationen mit den optimierten Paketen kommen und wenn ja warum?
Ja. Leider. 1. kann der Compiler fehler machen. Das sollte eigentlich nicht der Fall sein. 2. Da der C-Code mit der "Standarteinstellung" getestet wurde, kann man nicht sagen wie sich der andere Code verhält. Kritisch ist Hardwarecode. z.B. es muß ein Register in einer Karte 3. geschrieben werden. Das kommt manchmal vor. also. for (x=0;x<3;x++) { *a = 27; } Bei der Optimierung fallt auf das a mehrfach der gleiche Wert zugewisen wird. Also: *a = 27; for (...) { } Die leere for schleife fliegt auch raus. Falls der Entwickler nicht mit den Schlüsselworten "register" und "volatile" arbeitet kann es passieren das eine Variable die Hardwareregister darstellen in CPU register umgewandelt werden. Das kann dann nicht mehr gehen. Dazu kommt noch das inlinen der Funktionen. Wenn wie z.B. im dosemu in einer Funktion gleich mit einem Zeiger auf dem Stack zugegriffen wird, was zugegeben nicht gerade ein guter Programmierstil ist (aber schnell!), so fällt der Stack weg wenn diese Funktion zu einer Inlinefunktion wird. Da geht der Zugriff auf den Stack ins Leere. Also, man kann nicht jedes Programm mit den gleichen Optimierungen übersetzen! Prinzipiell kann man Software die eng mit Hardware zusammenarbeitet wie, XServer, Kernel, DosEmu nicht unbedingt mit allen Optimierungsoptionen übersetzten (inline und loop Optimierungen sind kritisch). Bei Numerisch anspruchsvollen Programmen wie Povray sollte man das fastmath schon mal ausprobieren. Bei *reiner* Software wie KDE, Bildbearbeitung kann man eigentlich alles aus dem Compiler rausholen. Falls der Compiler keinen Fehler macht sollte alles klappen.
Bringt es Geschwindigkeitsvorteile oder lohnt der Aufwand nicht? Ich denke das sich der Aufwand bei Programmen lohnen die immer laufen, also auf einem Webserver würde ich den Kernel und den apache optimieren. Ein optimiertes ls bringt sicher nicht viel. Auf einem Mailserver könnte man schon das sendmail mar neu durch den Compiler jagen. Auf meiner Büchse habe ich Kernel, XFree, KDE neu übersetzt und es bringt eine spürbare Verbesserung.
Meine Idee wäre für bestimmte Ensatzzwecke wie z.b. Webserver, Mailserver, KDE Workstation usw. Bestimmte optimierte Pakete zur Verfügung zu stellen. Da sollten aber auch die älteren CPUs nicht fehlen. (Linux ist auch was für alte Rechner!) also die ganz Bandbreite 386nicht (ist ja def.) aber 486,586 ... alles was der Compiler so kann. Ich würde da auch das eine oder andere Paket einbringen. -- Helmut --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Am Fre, 07 Apr 2000 schrieb Helmut Fahrion:
Hallo Waldemar Brodkorb,
Laut "Get Acquainted with Linux Security and Optimization System"sind folgende CompilerFlags besonders auf Optimierung ausgelegt.
Wo steht das? Würde ich auch gerne mal lesen.
http://www.linuxdoc.org/docs.html#guide -- MfG Waldemar Brodkorb Linux rulez! --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Bei *reiner* Software wie KDE, Bildbearbeitung kann man eigentlich alles aus dem Compiler rausholen. Falls der Compiler keinen Fehler macht sollte alles klappen.
Bringt es Geschwindigkeitsvorteile oder lohnt der Aufwand nicht? Ich denke das sich der Aufwand bei Programmen lohnen die immer laufen, also auf einem Webserver würde ich den Kernel und den apache optimieren. Ein optimiertes ls bringt sicher nicht viel. Auf einem Mailserver könnte man schon das sendmail mar neu durch den Compiler jagen. Auf meiner Büchse habe ich Kernel, XFree, KDE neu übersetzt und es bringt eine spürbare Verbesserung. Na das klingt doch interessant. Mich nervt es immer wieder, zu sehen, dass die Software in der Regel für einen Uralt-Prozessor kompiliert wurde. Ich habŽ ja nichts dagegen, dass SuSE das zunächst so auf CD
Helmut Fahrion wrote: Wird zwar eventuell langsam OT, aber vielleicht sind hier noch einige anderen daran interessiert. [...] presst, aber wenn man schon soŽn nettes AMD-Teil hat ...
Meine Idee wäre für bestimmte Ensatzzwecke wie z.b. Webserver, Mailserver, KDE Workstation usw. Bestimmte optimierte Pakete zur Verfügung zu stellen. Da sollten aber auch die älteren CPUs nicht fehlen. (Linux ist auch was für alte Rechner!) also die ganz Bandbreite 386nicht (ist ja def.) aber 486,586 ... alles was der Compiler so kann.
Ich würde da auch das eine oder andere Paket einbringen. Gibt es noch andere, die an der Erstellung derartiger Pakete interesse haben? Dann könnte man doch eine entsprechende Site aufbauen. Unter Umständen auch für andere Distries? Ich würde Serverplatz spendieren.
Um die Liste nicht weiter zu belasten, bitte Antowrten per PM an mich. Wenn etwas interessantes entsteht, melde ich mich wieder! Heiner -- Heiner Lamprecht Philosophenweg 79 D - 72076 Tuebingen email: heiner@kijumfo.de http://www.kijumfo.de GnuKontor: http://agenda21.ggi.uni-tuebingen.de/heiner/gk/ KFLog: http://agenda21.ggi.uni-tuebingen.de/heiner/kflog/ --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Waldemar Brodkorb (linux@netcologne.de) [20000406 22:51]:
CFLAGS= -O9 -funroll-loops -ffast-math -malign-double -mcpu=pentiumpro -march=pentiumpro -fomit-frame-pointer -fno-exceptions
<ironie> Ich *liebe* solche Generalisierungen. </ironie> -O9 bringt mit dem standard gcc überhaupt nichts, denn der kennt nur 3 Optimierungsstufen und -O3 schaltet nur zusätzlich automatisches inlinen ein, was in der Regel wenig sinnvoll ist. -ffast-math ist mit Vorsicht zu geniessen und -fomit-frame-pointer macht das Debuggen unmöglich. -mcpu kann man sich sparen, wenn -march angegeben wurde, denn letzteres impliziert ersteres. -malign-doubles ist auch nur bedingt sinnvoll. Schau Dir einfach mal die Texinfo-Dokumentation zum GCC an ( 'info gcc' ), speziell die Beschreibung der von Dir genannten Schalter. Die meisten haben ihre Haken und deshalb muss man von Fall zu Fall, sprich von Paket zu Paket, entscheiden, welche Schalter sinnvoll sind. Meiner Erfahrung nach sind ab Pentium aufwärts generell nur "-O2 --march=<prozessor> -fschedule-insns2 -fomit-frame-pointer" problemlos verwendbar. Bei allen anderen Flags muss man von Paket zu Paket entscheiden.
Flags in /etc/profile.local eintragen und exportieren.
Wenn Du rpm verwendest, ist es sinnvoller, /etc/rpmrc entsprechend zu modifizieren und dann in den Specfiles CFLAGS="$RPM_OPT_FLAGS" ./configure ..... zu verwenden. Aber Vorsicht! Manche Pakete ignorieren geflissentlich übergebene CFLAGS und setzten ihre eignen (selten aus gutem Grund).
Stell ich mir die Sache zu einfach vor?
Ja leider :( Im Endeffekt musst du dir doch jedes Paket ansehen und gegebenenfalls anpassen, zumal, wie ich schrieb, man von Paket zu Paket entscheiden muss, welche Optionen man evtl. noch zusätzlixh verwendet.
Bringt es Geschwindigkeitsvorteile oder lohnt der Aufwand nicht?
Teils ja, teils nein. Ein generelles Urteil ist da nicht möglich.
Philipp
--
Philipp Thomas
Am Fre, 07 Apr 2000 schrieben Sie:
* Waldemar Brodkorb (linux@netcologne.de) [20000406 22:51]:
CFLAGS= -O9 -funroll-loops -ffast-math -malign-double -mcpu=pentiumpro -march=pentiumpro -fomit-frame-pointer -fno-exceptions <ironie> Ich *liebe* solche Generalisierungen. </ironie> Meiner Erfahrung nach sind ab Pentium aufwärts generell nur "-O2 --march=<prozessor> -fschedule-insns2 -fomit-frame-pointer" problemlos verwendbar. Bei allen anderen Flags muss man von Paket zu Paket entscheiden.
Was mach ich dann falsch?? ich wollte das Kbase-Source-Paket neu kompilieren und hab das .spec-File angepasst. Folgendes erscheint: ----->Import-Begin:<----- checking for a C-Compiler... checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking how to run the C preprocessor... gcc -E checking for a C++-Compiler... checking for g++... g++ checking whether the C++ compiler (g++ -O2 --march=k6 -fschedule-insns2 -fomit-frame-pointer -DNDEBUG -s) works... no configure: error: installation or configuration problem: C++ compiler cannot create executables. Bad exit status from /var/tmp/rpm-tmp.79738 (%build) ----->Import-Ende:<----- Was hab ich uebersehen?? Mein Prozessor: AMD-K6 2/400 -- Gruss Dirk ---------------------- Reg.Linux-User #144171 ---------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Dirk Straub wrote:
checking whether the C++ compiler (g++ -O2 --march=k6 -fschedule-insns2 -fomit-frame-pointer -DNDEBUG -s) works... no configure: error: installation or configuration problem: C++ compiler cannot create executables.
Da fehlt irgend ein Paket. Genaueres kann man aber erst sagen , wenn man die letzten 10-15 Zeilen von config.log kennt . -- Markus Kossmann markus.kossmann@inka.de --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hallo, hier das komplette config.log: ----->Import-Begin:<----- This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. configure:611: checking host system type configure:632: checking target system type configure:650: checking build system type configure:704: checking for a BSD compatible install configure:757: checking whether build environment is sane configure:795: checking whether make sets ${MAKE} configure:841: checking for working aclocal configure:854: checking for working autoconf configure:867: checking for working automake configure:880: checking for working autoheader configure:893: checking for working makeinfo configure:943: checking for a C-Compiler configure:949: checking for gcc configure:1055: checking whether the C compiler (gcc -O2 --march=k6 -fschedule-insns2 -fomit-frame-pointer -DNDEBUG ) works configure:1071: gcc -o conftest -O2 --march=k6 -fschedule-insns2 -fomit-frame-pointer -DNDEBUG conftest.c 1>&5 cc1: Invalid option `-fmarch=k6' configure: failed program was: #line 1066 "configure" #include "confdefs.h" main(){return(0);} ----->Import-Ende:<---- Ich benutze SuSE 6.4. Da sollte das mit --march=k6 gehen. GCC-Version 2.95.2 Am Die, 11 Apr 2000 schrieben Sie:
Dirk Straub wrote:
checking whether the C++ compiler (g++ -O2 --march=k6 -fschedule-insns2 -fomit-frame-pointer -DNDEBUG -s) works... no configure: error: installation or configuration problem: C++ compiler cannot create executables.
Da fehlt irgend ein Paket. Genaueres kann man aber erst sagen , wenn man die letzten 10-15 Zeilen von config.log kennt . -- Markus Kossmann markus.kossmann@inka.de
-- Gruss Dirk ---------------------- Reg.Linux-User #144171 ---------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Dirk Straub wrote: [...]
configure:1055: checking whether the C compiler (gcc -O2 --march=k6 -fschedule-insns2 -fomit-frame-pointer -DNDEBUG ) works configure:1071: gcc -o conftest -O2 --march=k6 -fschedule-insns2 -fomit-frame-pointer -DNDEBUG conftest.c 1>&5 cc1: Invalid option `-fmarch=k6' configure: failed program was:
#line 1066 "configure" #include "confdefs.h"
main(){return(0);} ----->Import-Ende:<---- Ich benutze SuSE 6.4. Da sollte das mit --march=k6 gehen. GCC-Version 2.95.2 Laut gcc Info Seiten solltest du "-march=" und nicht "--march=" schreiben.
-- Markus Kossmann markus.kossmann@inka.de --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On Die, 11 Apr 2000, Dirk Straub wrote:
Meiner Erfahrung nach sind ab Pentium aufwärts generell nur "-O2 --march=<prozessor> -fschedule-insns2 -fomit-frame-pointer" problemlos verwendbar. Bei allen anderen Flags muss man von Paket zu Paket entscheiden.
Was mach ich dann falsch??
ich wollte das Kbase-Source-Paket neu kompilieren und hab das .spec-File angepasst. Folgendes erscheint:
----->Import-Begin:<----- checking for a C-Compiler... checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking how to run the C preprocessor... gcc -E checking for a C++-Compiler... checking for g++... g++ checking whether the C++ compiler (g++ -O2 --march=k6 -fschedule-insns2 -fomit-frame-pointer -DNDEBUG -s) works... no configure: error: installation or configuration problem: C++ compiler cannot create executables. Bad exit status from /var/tmp/rpm-tmp.79738 (%build) ----->Import-Ende:<-----
Was hab ich uebersehen?? Mein Prozessor: AMD-K6 2/400
Die Option -march=k6 funktioniert nur mit dem gepatchten GCC (PGCC) von der Pentium Compiler Group. Die URL habe ich momentan nicht, ist aber glaube ich bei www.goof.com zu finden. bye Bruno --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Bruno Semrau (bsemrau@netsurf.de) [20000411 21:10]:
Die Option -march=k6 funktioniert nur mit dem gepatchten GCC (PGCC) von der Pentium Compiler Group.
Falsch! -march=k6 ist spätestens seit gcc 2.95 möglich, in der CVS-Version
war er schon einige Zeit vorher vorhanden. pgcc setzt auf die egcs (jetzt
gcc) Sourcen auf, seit das Projekt vor ca. 3 Jahren ins Leben gerufen wurde.
Philipp
--
Philipp Thomas
* Dirk Straub (straub@nikocity.de) [20000411 16:00]:
Meiner Erfahrung nach sind ab Pentium aufwärts generell nur "-O2 --march=<prozessor> -fschedule-insns2 -fomit-frame-pointer" problemlos verwendbar. Bei allen anderen Flags muss man von Paket zu Paket entscheiden.
Was mach ich dann falsch??
configure: error: installation or configuration problem: C++ compiler
Sorry für die späte Antwort, aber ich war drei Tage in Brüssel auf einer
Linux-Messe.
Weil ich da einen Tippfehler hatte :( es muss -march=<prozessor> heissen.
Für -march=k6 brauchst Du mindestens gcc 2.95.
Philipp
--
Philipp Thomas
Hallo Waldemar! Waldemar Brodkorb schrieb am Donnerstag, den 06. April 2000:
Wäre folgendes möglich: Flags in /etc/profile.local eintragen und exportieren. Sourcen von verschiedenen Softwarepaketen installieren. (zum Beispiel: KDE-Packages) Und dann mit RPM neukompilieren: rpm -ba /usr/src/packages/SPECS/k....spec
Einfacher waere: rpm --rebuild /usr/src/packages/SRPMS/k...srpm find /usr/src/packages/SRPMS -name "*.srpm" -exec "rpm --rebuild {}" \; automatisiert das fuer alle srpms.
Und dann Paket updaten: rpm -U /usr/doc/packages/RPMS/i386/k.....rpm
Analog zu obigem find Aufruf.
Stell ich mir die Sache zu einfach vor?
Nein das muesste schon klappen.
Kann es zu unvorhergesehenen Komplikationen mit den optimierten Paketen kommen und wenn ja warum?
Ich denke nicht, es kann nur kontra produktiv sein wenn die Sourcen handoptimiert wurden, was bei den KDE Sachen aber sicher nicht der Fall ist. Das lohnt sich beim Kernel und bei allen Algos/Programmen die nur viel rechnen muessen (Raytracer, MP3 Encoder etc).
Bringt es Geschwindigkeitsvorteile oder lohnt der Aufwand nicht?
Ich kann mir nicht vorstellen dass sich der Aufwand lohnt. Schau mal auf Deinen Xosview bei normaler Arbeit: Deine CPU ist meistens Idle. Das lohnt sich nur bei Programmen die viel rechnen muessen, also bei den oben aufgezaehlten. GIMP waere evtl ein Kandidat bei dem es sich noch lohnen koennte, Betonung liegt auf koennte :-)
Thanks for any comments :-)
Ich habe es schon mehrfach mit "normaler" Software getestet, lohnt sich nicht. -- mfg Thomas Mueller - http://tmueller.home.pages.de --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Thomas Mueller schrieb in 1,8K (59 Zeilen): [Optimieren]
Das lohnt sich beim Kernel und bei allen Algos/Programmen die nur viel rechnen muessen (Raytracer, MP3 Encoder etc).
Wenn dein Programm 10% der Zeit im Kernel verbringt und du den Kernel um (unrealistische) 50% beschleunigen kannst, ist dein Programm 5% schneller. Das merkst du nicht. (und du musst abwaegen: Es geht etwas langsamer, oder es geht schneller --- kann aber auch boese, schwer zu findende Fehler generieren). -Wolfgang --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hallo Wolfgang! Wolfgang Weisselberg schrieb am Mittwoch, den 12. April 2000:
[Optimieren]
Das lohnt sich beim Kernel und bei allen Algos/Programmen die nur viel rechnen muessen (Raytracer, MP3 Encoder etc).
Wenn dein Programm 10% der Zeit im Kernel verbringt und du den Kernel um (unrealistische) 50% beschleunigen kannst, ist dein Programm 5% schneller. Das merkst du nicht.
Ja klar, aber mit dem Kernel haette ich dann auf einen Schlag alle Programme beschleunigt. Daher ist der Kernel ja auch Hand optimiert worden - ich glaube nicht dass das jemand aus purer langeweile getan hat :-)
(und du musst abwaegen: Es geht etwas langsamer, oder es geht schneller --- kann aber auch boese, schwer zu findende Fehler generieren).
Wenn ich nur z.B. reinen sauberen C Code schreibe darf eine Optimierung IMHO keine Fehler produzieren. Ich habe mich zwar bisher immer um die "Compiler Bau" Vorlesungen gedrueckt, aber ich kann mir nicht vorstellen warum der Compiler dann falsch uebersetzen sollte. Was denkbar ist, ist dass dann Fehler zum Vorschein kommen die bisher nicht entdeckt wurden, das sicherlich ja. Vor allem wenn Speicherverwaltung etc optimiert wird kann ein Pointer Fehler dann ploetzlich zum Crash fuehren der bisher eben nicht dazu gefuehrt hat. -- mfg Thomas Mueller - http://tmueller.home.pages.de for pgp key --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Thomas Mueller schrieb in 1,5K (42 Zeilen):
Wolfgang Weisselberg schrieb am Mittwoch, den 12. April 2000:
Wenn dein Programm 10% der Zeit im Kernel verbringt und du den Kernel um (unrealistische) 50% beschleunigen kannst, ist dein Programm 5% schneller. Das merkst du nicht.
Ja klar, aber mit dem Kernel haette ich dann auf einen Schlag alle Programme beschleunigt.
um 2-5%, maximal. Das hilft nur dann, wenn du dadurch etwas gerade schaffst, was du sonst ganz knapp verfehlst. Der Unterschied zwischen 100 und 105 km/h zaehlt nur bei ueberscharfen Radarfallen, schneller ankommen tust du nicht.
Daher ist der Kernel ja auch Hand optimiert worden - ich glaube nicht dass das jemand aus purer langeweile getan hat :-)
Ja, aber *das* ist was anderes: Hand-Optimierung bedeutet Engpaesse finden und durch einen besseren Algorithmus zu ersetzen ... und den dann CPU-freundlich zu coden. (In anderen Worten: Ein Pentium mit Quicksort in C oder bash oder Perl schlaegt eine Cray mit Bubblesort in Assembler, sobald die Datenmengen interessant werden).
(und du musst abwaegen: Es geht etwas langsamer, oder es geht schneller --- kann aber auch boese, schwer zu findende Fehler generieren).
Wenn ich nur z.B. reinen sauberen C Code schreibe darf eine Optimierung IMHO keine Fehler produzieren.
Kannst du "reinen sauberen C Code" garantieren? Bei einem handoptimierten Kernel, den du nicht geschrieben hast? Einem Kernel, der z.T. Bugs in gcc 2.7.2 ausnutzte?
Was denkbar ist, ist dass dann Fehler zum Vorschein kommen die bisher nicht entdeckt wurden, das sicherlich ja.
Zeig' mir einen fehlerfreien Compiler, und ich zeige dir einen 100% ehrlichen Politiker.
Vor allem wenn Speicherverwaltung etc optimiert wird kann ein Pointer Fehler dann ploetzlich zum Crash fuehren der bisher eben nicht dazu gefuehrt hat.
Oder wenn der Compiler falsche Annahmen bezueglich des Optimieren macht? (z.B. eine Variable in einer Schleife wird in dieser nicht geaendert --> "Konstante * Variable" ist konstant und kann vorher berechnet werden ... aber was, wenn ein Interrupt diese Variable via Pointer veraendert? (und damit aus der Endlosschleife keine Endlosschleife mehr macht?)) -Wolfgang --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hallo Wolfgang! Wolfgang Weisselberg schrieb am Donnerstag, den 13. April 2000:
Thomas Mueller schrieb in 1,5K (42 Zeilen):
Wolfgang Weisselberg schrieb am Mittwoch, den 12. April 2000:
Wenn dein Programm 10% der Zeit im Kernel verbringt und du den Kernel um (unrealistische) 50% beschleunigen kannst, ist dein Programm 5% schneller. Das merkst du nicht.
Ja klar, aber mit dem Kernel haette ich dann auf einen Schlag alle Programme beschleunigt.
um 2-5%, maximal. Das hilft nur dann, wenn du dadurch etwas gerade schaffst, was du sonst ganz knapp verfehlst. Der Unterschied zwischen 100 und 105 km/h zaehlt nur bei ueberscharfen Radarfallen, schneller ankommen tust du nicht.
Ja klar - ich halte auch nichts von dem Versuch hier irgendwas zu optimieren! Ich sagte nur dass es vollkommen unnoetig ist KDE neu zu kompilieren, WENN dann lohnt es sich z.B. beim Kernel. Oder eben zum Beispiel der Vergleich Lame - Gogo zeigt wieviel sich da rausholen laesst - aber das war eben nicht der Compiler sondern ein neu schreiben in Assembler.
Daher ist der Kernel ja auch Hand optimiert worden - ich glaube nicht dass das jemand aus purer langeweile getan hat :-)
Ja, aber *das* ist was anderes: Hand-Optimierung bedeutet Engpaesse finden und durch einen besseren Algorithmus zu ersetzen ... und den dann CPU-freundlich zu coden. (In anderen Worten: Ein Pentium mit Quicksort in C oder bash oder Perl schlaegt eine Cray mit Bubblesort in Assembler, sobald die Datenmengen interessant werden).
Wenn wir hier mal den Worst Case ausser acht lassen ;) Aber klar Du hast recht.
(und du musst abwaegen: Es geht etwas langsamer, oder es geht schneller --- kann aber auch boese, schwer zu findende Fehler generieren).
Wenn ich nur z.B. reinen sauberen C Code schreibe darf eine Optimierung IMHO keine Fehler produzieren.
Kannst du "reinen sauberen C Code" garantieren? Bei einem handoptimierten Kernel, den du nicht geschrieben hast?
Sicher nicht nein, beim Kernel schon gar nicht. Viel zu viel Assembler. Da wuerde ich die Finger weg lassen!
Einem Kernel, der z.T. Bugs in gcc 2.7.2 ausnutzte?
Bis wann?? Ich kompiliere den schon lange mit egcs - oder zumindest seit 2.0.34 oder sowas.
Was denkbar ist, ist dass dann Fehler zum Vorschein kommen die bisher nicht entdeckt wurden, das sicherlich ja.
Zeig' mir einen fehlerfreien Compiler, und ich zeige dir einen 100% ehrlichen Politiker.
Zeig mir ueberhaupt fehlerfreie Software, klar. Mit Standard Compiler Einstellungen wurde Software aber schon oft kompiliert und daher oft getestet.
Vor allem wenn Speicherverwaltung etc optimiert wird kann ein Pointer Fehler dann ploetzlich zum Crash fuehren der bisher eben nicht dazu gefuehrt hat.
Oder wenn der Compiler falsche Annahmen bezueglich des Optimieren macht? (z.B. eine Variable in einer Schleife wird in dieser nicht geaendert --> "Konstante * Variable" ist konstant und kann vorher berechnet werden ... aber was,
Der ist klar.
wenn ein Interrupt diese Variable via Pointer veraendert?
Das kann der Compiler aber doch problemlos ueberpruefen??
(und damit aus der Endlosschleife keine Endlosschleife mehr macht?))
-- mfg Thomas Mueller - http://tmueller.home.pages.de for pgp key --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Thomas Mueller schrieb in 3,5K (97 Zeilen):
Wolfgang Weisselberg schrieb am Donnerstag, den 13. April 2000:
Thomas Mueller schrieb in 1,5K (42 Zeilen):
Ja klar, aber mit dem Kernel haette ich dann auf einen Schlag alle Programme beschleunigt.
um 2-5%, maximal. Das hilft nur dann, wenn du dadurch etwas
Ja klar - ich halte auch nichts von dem Versuch hier irgendwas zu optimieren! Ich sagte nur dass es vollkommen unnoetig ist KDE neu zu kompilieren, WENN dann lohnt es sich z.B. beim Kernel.
Ich wuerde, wenn, dann KDE (zum optimieren) neu kompilieren. Wenn ich beim Kernel 50% und bei KDE 10% rausbekaeme, waeren die 10% besser (bei 10% der Zeit im Kernel ergibt das 5% gegen 9% ... fast doppelt so gut).
Oder eben zum Beispiel der Vergleich Lame - Gogo zeigt wieviel sich da rausholen laesst - aber das war eben nicht der Compiler sondern ein neu schreiben in Assembler.
Lame ist mehr auf Qualitaet aus als Gogo. Glaubst du, Gogo laesst sich noch warten?
Worten: Ein Pentium mit Quicksort in C oder bash oder Perl schlaegt eine Cray mit Bubblesort in Assembler, sobald die Datenmengen interessant werden).
Wenn wir hier mal den Worst Case ausser acht lassen ;)
Ein vernuenftiger Quicksort macht a) einen Test auf 'ist schon sortiert' (sein Worst Case) und/oder b) ein randomize auf die Datenordnung. Schliesslich ist Quicksort wohlbekannt.
Aber klar Du hast recht.
Siehst du.
Kannst du "reinen sauberen C Code" garantieren? Bei einem handoptimierten Kernel, den du nicht geschrieben hast?
Sicher nicht nein, beim Kernel schon gar nicht. Viel zu viel Assembler.
Da wuerde ich die Finger weg lassen!
Und bei Gogo? :-)
Einem Kernel, der z.T. Bugs in gcc 2.7.2 ausnutzte?
Bis wann?? Ich kompiliere den schon lange mit egcs - oder zumindest seit 2.0.34 oder sowas.
Bis in die fruehen 2.2er, IIRC. Ich habe frueher so manchen 'nix-da-Kernel' bei egcs gesehen.
Zeig' mir einen fehlerfreien Compiler, und ich zeige dir einen 100% ehrlichen Politiker.
Zeig mir ueberhaupt fehlerfreie Software, klar.
#! /usr/bin/perl -w print "Hello World\n";
Oder wenn der Compiler falsche Annahmen bezueglich des Optimieren macht? (z.B. eine Variable in einer Schleife wird in dieser nicht geaendert --> "Konstante * Variable" ist konstant und kann vorher berechnet werden ... aber was,
Der ist klar.
wenn ein Interrupt diese Variable via Pointer veraendert?
Das kann der Compiler aber doch problemlos ueberpruefen??
So? Das wird alles andere problemlos sein und ich bin mir ziemlich sicher, ein one-pass-compiler (C ist one pass, IIRC) kann das in vielen Faellen gar nicht abfangen _kann_. -Wolfgang --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hallo Wolfgang! Wolfgang Weisselberg schrieb am Samstag, den 15. April 2000:
Thomas Mueller schrieb in 3,5K (97 Zeilen):
Wolfgang Weisselberg schrieb am Donnerstag, den 13. April 2000:
Thomas Mueller schrieb in 1,5K (42 Zeilen):
Ja klar, aber mit dem Kernel haette ich dann auf einen Schlag alle Programme beschleunigt.
um 2-5%, maximal. Das hilft nur dann, wenn du dadurch etwas
Ja klar - ich halte auch nichts von dem Versuch hier irgendwas zu optimieren! Ich sagte nur dass es vollkommen unnoetig ist KDE neu zu kompilieren, WENN dann lohnt es sich z.B. beim Kernel.
Ich wuerde, wenn, dann KDE (zum optimieren) neu kompilieren. Wenn ich beim Kernel 50% und bei KDE 10% rausbekaeme, waeren die 10% besser (bei 10% der Zeit im Kernel ergibt das 5% gegen 9% ... fast doppelt so gut).
Der Wert gilt fuer die neu kompilierten Sachen. Wenn ich dann xmms unter KDE einsetze ... naja muessig darueber zu diskutieren. Das alles bringt vielleicht messbare Verbesserungen aber keine spuerbaren, daher IMHO alles Zeit Verschwendung.
Oder eben zum Beispiel der Vergleich Lame - Gogo zeigt wieviel sich da rausholen laesst - aber das war eben nicht der Compiler sondern ein neu schreiben in Assembler. Lame ist mehr auf Qualitaet aus als Gogo.
Lame ist eigentlich nur auf Qualitaet aus. Bei mir brauche ich zum Encoden einer kompletten CD um die 4h ... aber ich encode einmal und hoere mir das dann mehrfach an, daher encode ich auch mit Lame.
Glaubst du, Gogo laesst sich noch warten?
Nicht mit vertretbarem Aufwand.
Worten: Ein Pentium mit Quicksort in C oder bash oder Perl schlaegt eine Cray mit Bubblesort in Assembler, sobald die Datenmengen interessant werden).
Wenn wir hier mal den Worst Case ausser acht lassen ;)
Ein vernuenftiger Quicksort macht a) einen Test auf 'ist schon sortiert' (sein Worst Case) und/oder b) ein randomize auf die Datenordnung. Schliesslich ist Quicksort wohlbekannt.
b) habe ich noch nicht gesehen aber a) auf jeden Fall, ja.
Kannst du "reinen sauberen C Code" garantieren? Bei einem handoptimierten Kernel, den du nicht geschrieben hast?
Sicher nicht nein, beim Kernel schon gar nicht. Viel zu viel Assembler.
Da wuerde ich die Finger weg lassen!
Und bei Gogo? :-)
Wuerde ich auch nicht am Makefile drehen!!
Zeig' mir einen fehlerfreien Compiler, und ich zeige dir einen 100% ehrlichen Politiker.
Zeig mir ueberhaupt fehlerfreie Software, klar.
#! /usr/bin/perl -w print "Hello World\n";
Dein Code ist okay, aber der von Perl? Vom Kernel? ...
Oder wenn der Compiler falsche Annahmen bezueglich des Optimieren macht? (z.B. eine Variable in einer Schleife wird in dieser nicht geaendert --> "Konstante * Variable" ist konstant und kann vorher berechnet werden ... aber was,
Der ist klar.
wenn ein Interrupt diese Variable via Pointer veraendert?
Das kann der Compiler aber doch problemlos ueberpruefen??
So? Das wird alles andere problemlos sein und ich bin mir ziemlich sicher, ein one-pass-compiler (C ist one pass, IIRC) kann das in vielen Faellen gar nicht abfangen _kann_.
Hmm, das waere ziemlich uebel ... -- mfg Thomas Mueller - http://tmueller.home.pages.de for pgp key --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Thomas Mueller schrieb in 3,5K (100 Zeilen):
Wolfgang Weisselberg schrieb am Samstag, den 15. April 2000:
Thomas Mueller schrieb in 3,5K (97 Zeilen):
Ich wuerde, wenn, dann KDE (zum optimieren) neu kompilieren. Wenn ich beim Kernel 50% und bei KDE 10% rausbekaeme, waeren die 10% besser (bei 10% der Zeit im Kernel ergibt das 5% gegen 9% ... fast doppelt so gut).
Der Wert gilt fuer die neu kompilierten Sachen. Wenn ich dann xmms unter KDE einsetze ... naja muessig darueber zu diskutieren.
... dann kannst du die Fenster schneller verschieben. Und wenn xmms zuviel Rechenzeit braucht, willst du eh upgraden.
Das alles bringt vielleicht messbare Verbesserungen aber keine spuerbaren, daher IMHO alles Zeit Verschwendung.
Also eben nicht neu kompilieren (solange der Nutzen nicht nachgewiesen ist).
Lame ist eigentlich nur auf Qualitaet aus. Bei mir brauche ich zum Encoden einer kompletten CD um die 4h ...
P150 ?
Zeig mir ueberhaupt fehlerfreie Software, klar.
#! /usr/bin/perl -w print "Hello World\n";
Dein Code ist okay, aber der von Perl? Vom Kernel? ...
Der Code ist fehlerfrei. Perl ist fehlerfrei genug, um den Code sauber zu uebersetzen. Ich habe auch noch keine Kernel-Oopses bei Benutzung dieses Codes gesehen. :-) -Wolfgang --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hallo Wolfgang! Wolfgang Weisselberg schrieb am Sonntag, den 16. April 2000:
Thomas Mueller schrieb in 3,5K (100 Zeilen):
Wolfgang Weisselberg schrieb am Samstag, den 15. April 2000:
Thomas Mueller schrieb in 3,5K (97 Zeilen):
Ich wuerde, wenn, dann KDE (zum optimieren) neu kompilieren. Wenn ich beim Kernel 50% und bei KDE 10% rausbekaeme, waeren die 10% besser (bei 10% der Zeit im Kernel ergibt das 5% gegen 9% ... fast doppelt so gut).
Der Wert gilt fuer die neu kompilierten Sachen. Wenn ich dann xmms unter KDE einsetze ... naja muessig darueber zu diskutieren.
... dann kannst du die Fenster schneller verschieben. Und
Spitze!! Mein Compiler laeuft ;-)
wenn xmms zuviel Rechenzeit braucht, willst du eh upgraden.
Wahrscheinlich ja. Darauf koennen wir uns auch einigen: statt gross neu kompilieren oder optimieren einfach eine schnellere CPU nehmen ;-)
Das alles bringt vielleicht messbare Verbesserungen aber keine spuerbaren, daher IMHO alles Zeit Verschwendung.
Also eben nicht neu kompilieren (solange der Nutzen nicht nachgewiesen ist).
Na gut :-)
Lame ist eigentlich nur auf Qualitaet aus. Bei mir brauche ich zum Encoden einer kompletten CD um die 4h ...
P150 ?
P200 aber mit nice 18 ... egal, ich sitze ja nicht davor waehrend encoded wird.
Zeig mir ueberhaupt fehlerfreie Software, klar.
#! /usr/bin/perl -w print "Hello World\n";
Dein Code ist okay, aber der von Perl? Vom Kernel? ...
Der Code ist fehlerfrei. Perl ist fehlerfrei genug, um den Code sauber zu uebersetzen. Ich habe auch noch keine Kernel-Oopses bei Benutzung dieses Codes gesehen. :-)
Du hast sicher nicht intensiv genug getestet ;-) -- mfg Thomas Mueller - http://tmueller.home.pages.de for pgp key --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Thomas Mueller schrieb in 2,0K (63 Zeilen):
Wolfgang Weisselberg schrieb am Sonntag, den 16. April 2000:
wenn xmms zuviel Rechenzeit braucht, willst du eh upgraden.
Wahrscheinlich ja. Darauf koennen wir uns auch einigen: statt gross neu kompilieren oder optimieren einfach eine schnellere CPU nehmen ;-)
Und/oder mehr Speicher. Oder mehr CPUs ... und dann SMP.
Der Code ist fehlerfrei. Perl ist fehlerfrei genug, um den Code sauber zu uebersetzen. Ich habe auch noch keine Kernel-Oopses bei Benutzung dieses Codes gesehen. :-)
Du hast sicher nicht intensiv genug getestet ;-)
Hey, it compiles. SHIP IT! -Wolfgang --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Wolfgang Weisselberg wrote:
Thomas Mueller schrieb in 3,5K (97 Zeilen):
Zeig mir ueberhaupt fehlerfreie Software, klar.
#! /usr/bin/perl -w print "Hello World\n";
Dein Code zur Berechnung des sinus mit Hilfe der Taylorreihe enthält
noch Fehler.
SCNR,
Thorsten
--
Thorsten Jens
Hallo Wolfgang, Wolfgang Weisselberg schrieb :
Oder wenn der Compiler falsche Annahmen bezueglich des Optimieren macht? (z.B. eine Variable in einer Schleife wird in dieser nicht geaendert --> "Konstante * Variable" ist konstant und kann vorher berechnet werden ... aber was, wenn ein Interrupt diese Variable via Pointer veraendert? (und damit aus der Endlosschleife keine Endlosschleife mehr macht?))
chlechtes Beispiel... das müsste sogar schon bei -O2 Fehler verursachen. owas gehört als volatile gekennzeichnet. cu Michael --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Michael Stumpf schrieb in 0,7K (24 Zeilen):
Wolfgang Weisselberg schrieb :
Oder wenn der Compiler falsche Annahmen bezueglich des Optimieren macht? (z.B. eine Variable in einer Schleife
schlechtes Beispiel... das müsste sogar schon bei -O2 Fehler verursachen.
Ja, ebend.
sowas gehört als volatile gekennzeichnet.
Klar. Aber gehst du durch den ganzen Code und testest das? -Wolfgang --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hallo Wolfgang Weisselberg,
schlechtes Beispiel... das müsste sogar schon bei -O2 Fehler verursachen.
Ja, ebend.
sowas gehört als volatile gekennzeichnet.
Klar. Aber gehst du durch den ganzen Code und testest das?
Ist schon richtig, aber man sollte nicht pessimistisch sein. Die meisten Programme sind ohnehin mit -O2 übersetzt. Ich habe zur Zeit vom Kernel über die glibc, die bash +shutils, das xfree und kde durch den Compiler gejagt. Das alles läuft super und -O3 habe ich nur beim Kernel zu -O2 gemacht. -- Helmut --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Helmut Fahrion schrieb in 0,5K (24 Zeilen):
Klar. Aber gehst du durch den ganzen Code und testest das?
Ist schon richtig, aber man sollte nicht pessimistisch sein. Die meisten Programme sind ohnehin mit -O2 übersetzt.
Ja. -O3 bringt nicht immer was (kann sogar langsamer sein). -O2 ist Standard.
Ich habe zur Zeit vom Kernel über die glibc, die bash +shutils, das xfree und kde durch den Compiler gejagt. Das alles läuft super und -O3 habe ich nur beim Kernel zu -O2 gemacht.
Klingt soweit OK, nur wuerde ich mal testen, was -O3 denn *genau* bringt (z.B. bei der glibc). (Und abgesehen davon lauern die Fehler immer da, wo man sie nicht erwartet ... ) -Wolfgang --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Wolfgang Weisselberg (weissel@netcologne.de) [20000414 15:49]:
Klingt soweit OK, nur wuerde ich mal testen, was -O3 denn *genau* bringt (z.B. bei der glibc).
Da -O3 nur das automatische inlinen einschaltet, bringt es meist so gut wie
nichts, erst recht bei Paketen wie der glibc. Auf ix86 Maschinen kann die
vermehrte Verwendung von inline code sogar zu schlechterem Code führen, da
der Bedarf an Registern steigt. Und da ix86 Prozessoren nun nicht gerade
reichlich mit selbigen gesegnet sind, kann dieser erhöhte Bedarf zu
schlechterem Code führen.
Da sind Optionen wie -fschedule-insns2 ab Pentium aufwärts schon viel
sinnvoller.
Philipp
--
Philipp Thomas
Philipp Thomas schrieb in 0,9K (25 Zeilen):
Da -O3 nur das automatische inlinen einschaltet, bringt es meist so gut wie nichts, erst recht bei Paketen wie der glibc.
Ebend. Von daher: Benchmarks und nackte Zahlen.
Da sind Optionen wie -fschedule-insns2 ab Pentium aufwärts schon viel sinnvoller.
Welcher durch -O2 angeschaltet wird. -Wolfgang --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Wolfgang Weisselberg (weissel@netcologne.de) [20000415 03:19]:
Da sind Optionen wie -fschedule-insns2 ab Pentium aufwärts schon viel sinnvoller.
Welcher durch -O2 angeschaltet wird.
Njet. Schau mal wahlweise in "(gcc.info)Optimize Options"
oder in der gcc Quellcode, dann wirst du sehen, dass dem nicht so ist. An
der Stelle ist die Info-Doku weit weniger ausführlich als mir lieb ist.
Was dort fehlt ist IMO ein Absatz, der explizit angibt, welche Optionen
durch -O2 aktiviert werden. Vieleicht raffe ich mich ja doch noch mal auf
und schreibe eine solche Ergänzung.
Philipp
--
Philipp Thomas
Philipp Thomas schrieb in 0,9K (24 Zeilen):
* Wolfgang Weisselberg (weissel@netcologne.de) [20000415 03:19]:
Da sind Optionen wie -fschedule-insns2 ab Pentium aufwärts schon viel sinnvoller.
Welcher durch -O2 angeschaltet wird.
Njet. Schau mal wahlweise in "(gcc.info)Optimize Options"
The following options control specific optimizations. The `-O2' option turns on all of these optimizations except `-funroll-loops' `-funroll-all-loops', and `-fstrict-aliasing'. [...] `-fstrength-reduce' `-fthread-jumps' `-fcse-follow-jumps' [...] `-fdelayed-branch' `-fschedule-insns' `-fschedule-insns2' [...]
oder in der gcc Quellcode, dann wirst du sehen, dass dem nicht so ist.
-*-*-*-*-*-*-*-*-*-*-*-*-*-schnipp-*-*-*-*-*-*-*-*-*-*-*-*-*-*- $ cat /etc/SuSE-release SuSE Linux 6.4 (i386) VERSION = 6.4 $ rpm -q gcc gcc-2.95.2-19 $ tar -xzf urlview-0.7.tar.gz $ cd urlview-0.7/ $ ./configure [...] $ make CFLAGS="-O2 -DURLVIEW -Dunix" [...] $ md5sum urlview e2cf2dea9624b85c3f904ebeb69f500b urlview $ make clean [...] $ make CFLAGS="-O2 -fschedule-insns2 -DURLVIEW -Dunix" [...] $ md5sum urlview e2cf2dea9624b85c3f904ebeb69f500b urlview $ make clean [...] $ make CFLAGS="-O2 -fno-schedule-insns2 -DURLVIEW -Dunix" [...] $ md5sum urlview f059405786bc94fc8785efc9942b93c2 urlview -*-*-*-*-*-*-*-*-*-*-*-*-*-schnapp-*-*-*-*-*-*-*-*-*-*-*-*-*-*- Say again? -Wolfgang -- Finagle's First Law: If an experiment works, something has gone wrong. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
participants (11)
-
bsemrau＠netsurf.de -
hefa＠bitctrl.de -
heiner＠kijumfo.de -
linux＠netcologne.de -
Markus.Kossmann＠inka.de -
mlstumpf＠gmx.net -
pthomas＠suse.de -
straub＠nikocity.de -
thojens＠gmx.de -
tmm＠bigfoot.de -
weissel＠netcologne.de