Snelheidsverschillen in distro's? Hoe?

[Passenger]

N.a.v. dit topic: [topic=442432]

Hoe kan het nou dat de ene distro sneller is dan de andere? Ik volg dat niet helemaal... Komt dat door verschillende compilers? Of andere structuur?
Het lijkt mij dat als je 2 distro's op ongeveer gelijke manier opbouwt (zelfde compilers, zelfde kernels, en eigenlijk alle software versies hetzelfde) het elkaar toch bijna niets zou moeten ontlopen? Of maak ik nou ergens een denkfout?

[Equator]

Ach, sommige distro's installeren een heleboel services die je eigenlijk niet nodig hebt.
En anderen laten die services achterwege.

Voorbeeld, Redhat (Ik ben volledig Redat fan, maar toch) installeerd in versie 7.2 een aantal services die je echt niet perse gebruikt. ISDN, PORTMAP, KUDZU, PCMCIA, etc.
Die services zijn voor sommige doeleinden wel makkelijk, maar voor een standaard install niet nodig.
Wellicht even, maar daarna niet meer, Kudzu is nl. de eerste paar keer wel makkelijk, maar daarna niet meer totdat je een nieuw stukkie hardware toevoegd.

Ik stop altijd alle services die ik niet nodig heb, en dan loopt het systeempie een stukkie vlotter.

[Verwijderd]

zelfs als je al alle distributies met de zelfde programma's installeerd dan is het nog zo dat in de ene distro dit op de ene manier wordt opgelost en in de andere distro op een andere manier. Hoe dan ook kun je alle distro's net zo snel maken
maar dat betekend dus op zijn minst je eigen kernel compilen
en dan zo goed mogelijk optimaliseren voor je hardware.
Je eigen programma's compilen die baad hebben bij de ze optimalisaties. Achtergrond processen die je niet of zelden gebruikt uit de bootsequence halen.
voor sneller samba reacatie is het bv aan te raden om smbd en nmbd niet vanuit de inetd te starten maar als losse deamons.
RedHat heeft een eigen kernel die heel erg geoptimaliseerd is en drivers bevat die in de standaard kernel niet zitten. Deze kernel is dus mischien wel sneller dan je eigen zelf gebakken kernel. Een default SuSE installatie zat vroeger zo vol met deamons, dat een bak gewoon trager reageerde dan wanneer er slackware op stond. Maar je komt als beginnende linux gebruiker er met SuSE mischien niet zo snel achter wat je precies wel en niet nodig hebt.

Maar diversietijd in opbouw levert dus diversietijd in snelheid

[Ronald]

Gentoo is alles zelf gecompileerd, dus voor jouw processor, een p3 of Athlon en met agressieve optimalisaties. Het voordeel van de aggressieve optimailsaties is een paar % snellere code, het kan echter 'makkelijker' vreemde problemen geven en daarom doen distro's het optimaliseren conservatiever, soms slechts voor 386!

Gentoo is standaard zeer kaal, je draait dus geen overbodige software. Mandrake is standaard zeer compleet en start ook veel software al op, als je ook maar aangegeven hebt mysql te willen wordt deze standaard gestart. Je kunt op je klompen aanvoelen dat dat scheelt.

Distro bakkers ontwikkelen ook zelf aan software. Vaak omdat ze niet tevreden zijn met functionailteit van software of om bugs te fixen. Deze ontwikkelingen geven ze welliswaar door 'upstream' (terug naar de ontwikkelaars) maar er zijn dus subtiele verschillen tussen ditros.
Een voorbeeld hiervan: SGI FAM. dit is een file alteration monitor door SGI geport vanaf de Irix en opensourced voor linux. Vanille doet polled deze voor veranderingen, vrij traag dus. (ik ga er hierbij vanuit dat de imom kernelpatch, die niet up to date is vanuit SGI niet gebruikt is) Redhat en Mandrake hebben een veel snellere versie hiervan die de dnotify functionaliteit van de kernel gebruikt.
Omdat nautilus FAM kan gebruiken kan dit enorme verschillen in snelheid geven. (tot een factor 10 las ik!)

[deadinspace]

Op woensdag 20 maart 2002 12:39 schreef nitenite het volgende:
Gentoo is alles zelf gecompileerd, dus voor jouw processor, een p3 of Athlon en met agressieve optimalisaties. Het voordeel van de aggressieve optimailsaties is een paar % snellere code, het kan echter 'makkelijker' vreemde problemen geven en daarom doen distro's het optimaliseren conservatiever, soms slechts voor 386!

Ja, maar het compilen voor je eigen CPU is overrated. Code gecompiled voor bijvoorbeeld een Athlon draait op een Athlon meestal niks of maar zeer weinig sneller dan code gecompiled voor een 80386 op een Athlon.
Fikse snelheidswinst zou in sommige gevallen mogelijk zijn door gebruik te maken van nieuwe instructies die nieuwere CPUs bieden (zoals mmx of sse), maar daar moet je programma speciaal voor geschreven zijn.

Omdat nautilus FAM kan gebruiken kan dit enorme verschillen in snelheid geven. (tot een factor 10 las ik!)

Ik denk niet dat Nautilus daar 10 keer sneller in gebruik van wordt. Niet op de laatste plaats omdat daar 100 andere factoren buiten files monitoren een rol in spelen.
Ik denk dat daar bedoeld was dat Nautilus mbv FAM 10 keer sneller veranderingen in files doorheeft (wat an sich ook prettig is, maar een stuk minder spectaculair).

[Ronald]

Op woensdag 20 maart 2002 17:58 schreef deadinspace het volgende:

[..]

Ja, maar het compilen voor je eigen CPU is overrated. Code gecompiled voor bijvoorbeeld een Athlon draait op een Athlon meestal niks of maar zeer weinig sneller dan code gecompiled voor een 80386 op een Athlon.
Fikse snelheidswinst zou in sommige gevallen mogelijk zijn door gebruik te maken van nieuwe instructies die nieuwere CPUs bieden (zoals mmx of sse), maar daar moet je programma speciaal voor geschreven zijn.
[..]

Mijn LFS gnome loopt toch echt soepeler dan debian deed
Om het over mozilla nog maar niet te hebben.

Ik denk niet dat Nautilus daar 10 keer sneller in gebruik van wordt. Niet op de laatste plaats omdat daar 100 andere factoren buiten files monitoren een rol in spelen.
Ik denk dat daar bedoeld was dat Nautilus mbv FAM 10 keer sneller veranderingen in files doorheeft (wat an sich ook prettig is, maar een stuk minder spectaculair).

Dat bedoelde ik. Als illustratie van dingen die per distro snelheids verschillen kunnen veroorzaken.

[Verwijderd]

afgezien van het feit dat je bepaalde services wel of niet hebt draaien, moet je gewoon je zut zelf compilen.. "scheelt dat ?" ja dus..