Ich habe auf einem K6-III die Suse 8.1 Startzeiten mit denen von Suse8.0 verglichen. Absolut identisch. Die getesteten Programme waren: kwrite, konqueror, abiword, openoffice, mozilla
Die Beschleunigungsfunktionen von glibc2.2.5(Suse 8.1) hatte Suse schon in die ältere glibc von Suse8.0 eingebaut. Bleibt der Effekt von Gcc3.2 und Optimierung auf i586. Davon merkt man auf obigem Rechner jedoch rein garnichts. Auf einem Notebook mit P3-850MHz kommen mir die Startzeiten von Programmen etwas kürzer vor. Vermutlich ist das aber nur eine Wunschvorstellung, die zur "Sinnestäuschung" führt...
Es ging ja auch um den gcc3.2, der angeblich merkbar schneller geworden sein soll. Die max. 10%, die der gcc3.2 gegenüber dem gcc2.95 zugelegt hat, merkt man aber ohne Stoppuhr nicht.
wahrscheinlich gibt es nicht ohne grund keine offizielle ankündigung? bei gentoo ist die glibc-2.3 noch nicht einmal maskiert... das redhat die ersten sind welche diese version unterstützen wundert mich nicht. schliesslich sind die amis ja dafür bekannt unfertige sachen zu distributen und nachher schelte einstecken zu müssen. solange da nix offizielles released ist, werde ich davon die finger lassen und es wie eine interne alpha-entwicklerversion betrachten.
Naja, waren die Typen mit den unfertigen Distris und nicht funktionierenden Updates nicht Deutsche? ;-)
Mal abgesehen von der glibc ist RedHat ja eher konservativ - ich sag' nur gcc. Bisher kann ich mich über diese Politik nicht beschweren, die Roten Hüte, die so installiert/geupdated habe funktionieren allesamt tadellos.
Also von mir aus können die auch eine nicht offizielle Version von irgendwas mit auf ihre CDs tun, wenn es ordentlich getestet ist und funktioniert ist es doch wurscht.
> Mal abgesehen von der glibc ist RedHat ja eher konservativ - ich sag' nur gcc.
Bitte was? Höchstens konservativ was ABI-Kompatibilität betrifft. Die haben doch gerade den damals aktuellsten gcc-Snapshot genommen, auf gcc 2.95.3 Kompatibilität getrimmt und als "gcc 2.96" verwendet. Wieviele Revisionen davon hat es gebraucht bis das Ding nicht mehr dauernd mit z.B. "internal compiler error" abgesemmelt ist und korrekten Code produziert hat?
kann deine meinung zum thema gcc unter redhat nur bedingt teilen. klar, ich bin auch kein freund davon, unfertige beta releases, die noch dazu zu inkompatibilität führen können, auf official release distributionen zu vertreiben. bei einem projekt, das ich bereits vor dem release termin ausführlich testen konnte, fiel ein programmierfehler nur (!) mit dem redhat gcc-2.96 der 7.0-er release auf. alle anderen unices, auf denen wir das projekt getestet haben (freebsd 4.x, debian 2.2 sparc und x86, redhat 6.2, solaris 2.6 - haben den sourcecode fehler ignoriert. der projektmaintainer meinte damals: das darf doch gar nicht sein, daß der gcc-2.95.3 hier nicht abbricht. so eindeutig war der fehler! soviel zum thema gcc-2.96.rh
Genauso wie sie ja auch ihre KDE-Leute gefragt haben... Bei RedHat gab es mit dem gcc-2.96 auch internen Protest, aber irgendjemand wollte unbedingt, dass er verwendet wird.
Hmm ich glaube RedHat benutzt die neue glibc jetzt schon, weil der Hauptentwickler Ulrich Drepper bei RedHat arbeitet? Für mich klingt diese Antwort plausibel
Wie kann man sich den vorstellen,das es noch schneller geht? Oder besser,warum ging es vorher so langsam,wenn es Dynamisch gelinkt war? Ist es nicht besser,wenn genügend RAM da ist einfach alle Bibliotheken im Speicher zu laden? Das müsste doch dann fix sein? Gruß Udo
in meinem /usr/lib sind fast 300mb, und ich habe weder gnome noch kde, ja nicht mal qt installiert. es ist mit ziemlicher sicherheit bei jedem zu wenig ram da, um _alle_ libs zu laden.
Dachte so an 2Giga Ram,wenn die Ram Preise weiter so Tendieren,dann hat jeder in seinen Desktop sowas. Ich habe ja jetzt schon in jedem meiner Rechner 1Gig,da ist es nicht mehr weit. Gruß Udo
Theoretisch kannst du das machen. Du wirst die neuen Features aber nicht voll ausnutzen können. Glibc-2.3 ist zwar binär abwärtskompatibel, aber dadurch sind die meisten deiner bestehenden Bibliotheken trotzdem nicht schneller.
Die Beschleunigungsfunktionen von glibc2.2.5(Suse 8.1) hatte Suse schon in die ältere glibc von Suse8.0 eingebaut. Bleibt der Effekt von Gcc3.2 und Optimierung auf i586. Davon merkt man auf obigem Rechner jedoch rein garnichts.
Auf einem Notebook mit P3-850MHz kommen mir die Startzeiten von Programmen etwas kürzer vor. Vermutlich ist das aber nur eine Wunschvorstellung, die zur "Sinnestäuschung" führt...
bis denn,
Martin
schneller?
Ich saß heute an RH8.0, und KDE3 war ziemlich lahm bei nem PIII 450.
Also als schnell habe ich RedHat8 nicht empfunden.
Bye
Stefan
bei gentoo ist die glibc-2.3 noch nicht einmal maskiert... das redhat die ersten sind welche diese version unterstützen wundert mich nicht. schliesslich sind die amis ja dafür bekannt unfertige sachen zu distributen und nachher schelte einstecken zu müssen.
solange da nix offizielles released ist, werde ich davon die finger lassen und es wie eine interne alpha-entwicklerversion betrachten.
Mal abgesehen von der glibc ist RedHat ja eher konservativ - ich sag' nur gcc. Bisher kann ich mich über diese Politik nicht beschweren, die Roten Hüte, die so installiert/geupdated habe funktionieren allesamt tadellos.
Also von mir aus können die auch eine nicht offizielle Version von irgendwas mit auf ihre CDs tun, wenn es ordentlich getestet ist und funktioniert ist es doch wurscht.
Bitte was? Höchstens konservativ was ABI-Kompatibilität betrifft. Die haben doch gerade den damals aktuellsten gcc-Snapshot genommen, auf gcc 2.95.3 Kompatibilität getrimmt und als "gcc 2.96" verwendet. Wieviele Revisionen davon hat es gebraucht bis das Ding nicht mehr dauernd mit z.B. "internal compiler error" abgesemmelt ist und korrekten Code produziert hat?
kann deine meinung zum thema gcc unter redhat nur bedingt teilen. klar, ich bin auch kein freund davon, unfertige beta releases, die noch dazu zu inkompatibilität führen können, auf official release distributionen zu vertreiben.
haben den sourcecode fehler ignoriert.
bei einem projekt, das ich bereits vor dem release termin ausführlich testen konnte, fiel ein programmierfehler nur (!) mit dem redhat gcc-2.96 der 7.0-er release auf. alle anderen unices, auf denen wir das projekt getestet haben (freebsd 4.x, debian 2.2 sparc und x86, redhat 6.2, solaris 2.6 -
der projektmaintainer meinte damals: das darf doch gar nicht sein, daß der gcc-2.95.3 hier nicht abbricht. so eindeutig war der fehler!
soviel zum thema gcc-2.96.rh
cat /gruss
klaus
der fontconfig-patch für mozilla ist noch nicht fertig und deshalb auch nicht mit drin, obwohl er mindestens so wichtig für rh8 ist, wie die glibc2.3
soviel zum thema unfertig
ronny
Bei RedHat gab es mit dem gcc-2.96 auch internen Protest, aber irgendjemand wollte unbedingt, dass er verwendet wird.
Du bist einfachn nur ein blödes Würstchen. Keine Ahnung aber immer eine grosse Klappe. Schlicht ein Troll.
/heavy flameware
fakten
http://sources.redhat.com/ml/libc-alpha/2002-10/msg00050.html
/fakten
Für mich klingt diese Antwort plausibel
regards Holger
http://sources.redhat.com/ml/libc-alpha/2002-10/msg00050.html
Ulrich Drepper hat nun wirklich nicht die RH-Brille auf...
Grüssli,
Jo
Und dazu empfiehlt der geneigte SMP-Fachmann was ? Nie neuen Threads von RedHat oder die Posixthread von IMB ?
Oder eine von beiden anstelle der glic-linuxthreads ? Oder doch beide und die glibc-linuxthreads ?
Blicke nicht mehr durch ...
vielleicht ?
ac
Oder besser,warum ging es vorher so langsam,wenn es Dynamisch gelinkt war?
Ist es nicht besser,wenn genügend RAM da ist einfach alle Bibliotheken im Speicher zu laden?
Das müsste doch dann fix sein?
Gruß Udo
Ich habe ja jetzt schon in jedem meiner Rechner 1Gig,da ist es nicht mehr weit.
Gruß Udo
gcc3.2 und glibc2.3 umzurüsten.
hans
Du wirst die neuen Features aber nicht voll ausnutzen können. Glibc-2.3 ist zwar binär abwärtskompatibel, aber dadurch sind die meisten deiner bestehenden Bibliotheken trotzdem nicht schneller.