Mailinglist Archive: opensuse-de (4451 mails)

[tmm@xxxxxxxxxx (Thomas Mueller)]

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@xxxxxxxx
For additional commands, e-mail: suse-linux-help@xxxxxxxx