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