[LINUX] hoe optimaliseer ik linux

[Verwijderd]

ik ben vrijwel een linux (dev)n00b, ik heb wel wat ervaring met linux als zijnde een workstation (tijden SUSE gebruikt al vanaf 7.0 die ik hier origineel op 6 of 7 discjes heb liggen)

nu is het zo dat ik graag een volledig geoptimaliseert systeem wil voor gebruik met mijn SETUP om zo de uiterste performance uit mijn pc te persen.

mijn specs:
AMD Opteron 165 (64bit dualcore @1800Mhz)
2GB OCZ Titanium in DC
Asrock 939Dual-Sata2
Nvidia GeForce 6800
1x IDE MAXTOR DIAMONDMAX PLUS 8 40GB
1x IDE MAXTOR MAXLINE III 250GB
Creative Soundblaster X-FI XtremeMusic *ik weet dat hier geen drivers voor zijn maar hij zit er dus wel in*

(belangrijkste info staat hier dacht ik maar er is meer info in sig)

het gaat dus een dualbootje worden om de reden dat ik ook nog regelmatig game (ik heb ook gehoord dat cedega of WineX een goede "windows emulator" is misschien ga ik zodra de soundblaster drivers goed geoptimaliseerd zijn wel helemaal over op linux)

nu heb ik mij een beetje ingelezen op de verschillende distros die er zijn en een van de distro's die volgens mij heel erg goed voldoet voor dit projectje is GENTOO, graag zou ik jullie mening hierover weten.

ook heb ik het een en ander gelezen over het optimaliseren van de compiler *GCC dacht ik* voor gebruik met bepaalde architecturen, dit is denk ik ook belangrijk, en zo ja wat moet ik hiervoor instellen?
ik heb alvast het een en ander uitgezocht aan extensies die mijn processor boven op de x86 extensies gebruikt ik weet niet of dit van toepassing is maar here goes nothing:
MMX (+)
3DNOW! (+)
SSE, SSE2 en SSE3
x86-64 *voor 64bit ondersteuning*
SMP *voor dualcore ondersteuning*

het mooiste zou zijn dat ik vanaf de kernel de boel zelf ga compileren met de juiste instellingen, maar ik heb geen flauw idee hoe. ook hier zou een beetje hulp op prijs gesteld worden.

ik heb al verscheidene websites bezocht over de installatie van linux maar daar wordt ik niet veel wijs uit:
www.linux.org
www.linuxfromscratch.org
http://www.gentoo.org/doc...l?catid=install#doc_chap2

ook heb ik mij rot gezocht op google en natuurlijk hier op GOT maar niet echt bevredigende antwoorden gevonden en ik dacht dat misschien meer mensen met deze vraag zouden zitten, dus vandaar dit topic.

[Cyphax]

Mwah, alles zelf compilen gaat geen revolutionaire snelheidswinst opleveren, behalve de kernel (en zelfs daarvoor geldt: alleen als je een ontzettend bloated kernel hebt is ie traag). Als je wel graag ter lering een systeem zelf helemaal from scratch op wil bouwen is Linuxfromscratch toch de mooiste keus, denk ik. Linuxfromscratch is goed gedocumenteerd trouwens, dus geef niet te snel op. Een andere optie is een distro als Slackware of Debian installeren en finetunen (dat doe ik zelf graag, met Slackware, en die is achterlijk snel te krijgen) maar dat kost ook een hoop tijd. Het is wel erg leuk trouwens.

Een kernel compilen is niet zo heel moeilijk (mits je echt weet wat voor hardware je hebt), maar kost wel redelijk wat tijd. Ik weet niet of Suse blij is met vanilla kernels, of dat je een gepatchte nodig hebt, maar in het eerste geval haal je een kernel bij een mirror van kernel.org (ftp.nluug.nl kijk ik meestal, ook voor andere software) en pak je zoiets erbij.

Overigens: verwacht niet al teveel van Wine en Cedega. Niet dat ze slecht werken (integendeel!) maar het is zo vervelend als je net je dualboot setup klaar hebt en heel enthousiast met je Linuxinstallatie bezig bent geweest om er vervolgens achter te komen dat je spel X en Y niet kunt spelen. Zolang je wilt blijven gamen moet je Windows nog even niet weggooien, helaas.

[ Voor 16% gewijzigd door Cyphax op 06-05-2006 03:04 ]

[Verwijderd]

Het is inderdaad grotendeels verloren moeite om alles zelf te compileren.
Ook aangezien je niet zo vertrouwd bent met linux, is het risico dat je dan uiteindelijk tragere binaries krijgt, wegens verkeerde gcc instellingen, redelijk groot.
De beste mogelijkheden die je hebt zijn:
alle software en libraries die je niet gebruikt verwijderen,
en zelf een eigen kernel bakken, volledig aangepast aan jouw systeem.
Deze laatste is natuurlijk wel een beetje "tricky", aangezien het voor een beginner moeilijk is om te weten wat juist noodzakelijk is en wat niet...
Het is maar al te makkelijk om een kritiek onderdeel van de kernel uit te schakelen,
met een systeem dat niet wil booten als gevolg.
Ik zou gewoon even beginnen met de basics van linux erg goed onder de knie te krijgen.
Kennis en ervaring doe je op in stapjes, je kan niet verwachten dat wij je een gouden tip of URL geven waardoor je opeens van noob naar held gaat

[Verwijderd]

Mijn inziens is Gentoo ook een goede optie om naar te kijken. Daar kan je effectief vanaf de compiler alles opbouwen met optimalisaties zoals jij wil. Daarbij komt dat de documentatie erg goed is zodat je gemakkelijker zal weten welke services uit te zetten (mijn inziens zeker zo belangrijk voor snelheid als de compilatie-optimalisatie).

Daarnaast is het zaak om een afgeslankte kernel te bouwen en (bij gentoo) enkel de USE-variabelen in te stellen die je echt nodig hebt.

Wel onthouden: performantie gaat niet om het sneller maken punt. Wel steeds om de verhouding van functionaliteit, opties, oogsnoep tegenover snelheid. Die zit voor elke distro ongeveer in dezelfde buurt denk ik, maar bij Gentoo kan je waarschijnlijk ongeveer het gemakkelijkst kiezen welke verhouding jij juist wil (en dit gaat soms erg ver ).

[Verwijderd]

Gentoo is een mooie keuze. Het gaat niet zozeer om snelheidswinst maar het idee dat alles wat je compileert ook echt alleen maar voor je eigen systeem gebouwd is. Wanneer je definitief voor Gentoo kiest installeer dan vanaf de LiveCD. Je installeert dan vanuit een Gnome sessie en hebt mooi alle internetinformatie bij de hand.

Voor veilige CFLAGS settings voor GCC kun je hier kijken.

[Ivo]

Veilige CFLAGS gebruik ik zelf ook altijd (-fomit-frame-pointer zet ik wel uit vanwege debugdoeleinden), maar als je het onderste uit de kan wil halen dan kun je ook aggressievere flags instellen. Op het moment dat je systeem onstabiel wordt dan ga je middels trial en error zoeken welke flag alles verpest (dit is natuurlijk ook package-specifiek). Ik zou in ieder geval voor -O3 gaan als je wilt gaan optimaliseren.

[dion_b]

Gentoo is verreweg de makkelijkste manier om alles zelf te optimaliseren voor je systeem. De Gentoo Handbook loodst je stap-voor-stap door het hele proces, de enige plekken waar je een beetje aan je eigen kennis wordt overgelaten is bij het instellen van de architectuur (wat voor bak heb je?) in CFLAGS en de USE-variable (maar dat laatste is juist de bedoeling...

Gelukkig heeft Gentoo niet alleen een Handbook, maar ook een Wiki - zie hier voor een lijst van CFLAGS optimalisaties voor alles vanaf een i386SX-16 tot en met Core Duo en (hier relevant) Opteron

Edit:
Damn, William was me voor

Mbt USE-flags:
Wat Harry_Hakbijl zegt over verhouding tussen snelheid en eye-candy klopt, maar er is een grote uitzondering die wel aardig wat snelheidswinst kan opleveren ongeacht hoeveel eye-candy je wilt: de software (en kernel) van vrijwel iedere 'kant-en-klaar' distro is gecompileerd met support voor de beide grote Desktop Environments, dus Gnome en KDE. Daaronder is er ook support voor zowel GTK als QT (de achterliggende libraries). Als je op voorhand al weet welke jij wilt hebben (of je revolutionair wilt doen en geen van beide neemt...), dan kun je support voor de ongebruikte zaken uitschakelen door "-qt -kde" of "-gtk -gnome" in USE te zetten. Dat kan bij grafische apps aardig schelen, met name voor de meer toeters-en-bellen georienteerde spullen.

Let trouwens wel op bij de libraries (QT en GTK), het kan zijn dat je er niet aan ontkomt beide te hebben. Zo gebruiken Mozilla en consorten GTK, maar Opera doet QT. WIl je beide, dan zul je beide libraries moeten gebruiken. Dat is trouwens nog niet erg, zolang je niet integratie in de rest van de DE meeneemt.

* dion_b is bijvoorbeeld xfce fan, heeft o.a. USE="-kde -gnome +qt +gtk +xfce" erin staan.

Edit2:

Slechts marginaal on-topic, maar misschien relevant om te weten: als je .wmv filmpjes wilt afspelen met Gentoo heb je niet alleen de "win32codecs" flag nodig maar ook "asf"

Ivo schreef op zaterdag 06 mei 2006 @ 14:15:
Veilige CFLAGS gebruik ik zelf ook altijd (-fomit-frame-pointer zet ik wel uit vanwege debugdoeleinden), maar als je het onderste uit de kan wil halen dan kun je ook aggressievere flags instellen. Op het moment dat je systeem onstabiel wordt dan ga je middels trial en error zoeken welke flag alles verpest (dit is natuurlijk ook package-specifiek). Ik zou in ieder geval voor -O3 gaan als je wilt gaan optimaliseren.

De meerwaarde van -O3 tov -O2 is nogal discutabel aangezien de binaries bij -O3 vaak merkbaar groter worden, wat laadtijden e.d. niet ten goede komt. Bovendien zijn er packages die met -O3 gewoon niet goed compileren (op x86 valt het trouwensmee, maar dan nog).

Wat wel enorm scheelt, maar dat is hier niet bepaald van toepassing, is om bij systemen waar hoeveelheid RAM de grootste bottleneck is (ik noem mijn sub-notebook waar niet meer dan 64MB op kan) de -Os flag te pakken. Dan worden de binaries op minimale grootte geoptimaliseerd. Als je bedenkt dat swappen naar harddisk duizenden malen trager is dan uit RAM lezen, snap je waarom de evt verliezen in execution time niet opwegen tegen de besparing in ruimte in dit soort systemen

[ Voor 29% gewijzigd door dion_b op 06-05-2006 16:07 ]

[Emielio]

Ook een optie om heel snel een snelle desktop in elkaar te knutselen is archlinux gebruiken.
Dit is dan niet 64 bits ofzo maar is wel 686 geoptimaliseerd en standaard SUPER slank.
Het voordeel tov gentoo is dat je niet compileren tot een dagelijkse bezigheid maakt.
Waarschijnlijk kun je het verschil tussen een arch of geoptimaliseerde gentoo niet eens waarnemen, terwijl het verschil met suse gigantisch is. Ik gebruik zelf in arch meestal xfce en kan in normaal desktop gebruik het verschil tussen 256 en 512 mb ram niet merken omdat ie simpelweg niet genoeg ram daarvoor gebruikt.
Arch linux installeer je in een minuut of 20, configureren duurt wel iets langer, en je moet je wel iets meer gaan verdiepen als je in suse moest doen!

[Verwijderd]

Euh redelijk wazige opmerking dion_b, waar haal je het dat een linux KERNEL kan gecompileerd zijn met support voor gnome en/of kde?
Voor Gnome/KDE/QT/GTK maakt het helemaal niet uit hoe de kernel geconfigureerd is.
By the way, kleine opmerking ivm gentoo:
hoe kan je het nou serieus nemen dat gentoo sneller is?
Je spendeert wekelijks enkele UREN om vanalles te compileren en hercompileren, terwijl sommige apps dan enkele microseconden sneller draaien, andere apps enkele seconden trager draaien (wegens het feit dat gcc nogal eens slechte code maakt bij al te agressieve optimalisaties) en nog andere apps helemaal niet meer willen draaien omdat je te agressieve CFLAGS hebt gebruikt...
Zelfs in de allerbeste situatie, kan de performance winst van het hercompileren nooit op tegen de (CPU)tijd, moeite en elektriciteit die je erin moet stoppen...
Maar ach, ieder zijn eigen smaak natuurlijk, er zullen altijd mensen zijn die graag zo'n grote opvallende spoiler op hun auto willen omdat ze dan sneller gaan enzo

[ Voor 90% gewijzigd door Verwijderd op 06-05-2006 17:33 ]

[Verwijderd]

Wat volgens mij ook 'n hoop kan schelen qua snelheid is een 32-bits distro nemen (ipv 64-bits). Ik heb me er niet in verdiept en geen snelheidsmetingen gedaan, maar ik heb het idee dat bij een 64-bits userland nog maar de helft van de pointers en native integers in je registers/caches past. (Correct me if I'm wrong.)

[XTerm]

Verwijderd schreef op zaterdag 06 mei 2006 @ 17:31:
Wat volgens mij ook 'n hoop kan schelen qua snelheid is een 32-bits distro nemen (ipv 64-bits). Ik heb me er niet in verdiept en geen snelheidsmetingen gedaan, maar ik heb het idee dat bij een 64-bits userland nog maar de helft van de pointers en native integers in je registers/caches past. (Correct me if I'm wrong.)

Ehm... Als je 64 bits binaries op een 64 bits CPU gaat draaien, de naam zegt het zelf al, zijn de registers ook wel 64 bits groot

Wat *wel* zo is, is dat 64 bits binaries iets groter durven zijn && meer RAM geheugen gebruiken omdat de pointers en integers groter zijn. Dus, voor 64 bit mag je toch wel iets meer RAM rekenen. Snelheidsverschil is wel goed merkbaar.

[Verwijderd]

XTerm schreef op zaterdag 06 mei 2006 @ 17:41:
[...]


Ehm... Als je 64 bits binaries op een 64 bits CPU gaat draaien, de naam zegt het zelf al, zijn de registers ook wel 64 bits groot

Wat *wel* zo is, is dat 64 bits binaries iets groter durven zijn && meer RAM geheugen gebruiken omdat de pointers en integers groter zijn. Dus, voor 64 bit mag je toch wel iets meer RAM rekenen. Snelheidsverschil is wel goed merkbaar.

Snelheid is echt onzin, tenzij je echt specifieke apps hebt die profiteren van 64 bit is het compleet nutteloos om de moeite te nemen alles in 64 bit te doen, 32 bit is makkelijker en zo nu en dan zelfs sneller ook.
Zie bijvoorbeeld:
http://www.osnews.com/story.php?news_id=5768&page=1

[Verwijderd]

bedankt voor jullie geweldige reacties!!!

ik heb dus bij deze voor gentoo gekozen omdat dit pakket het vanaf de grond af aan toe staat het systeem te optimaliseren.

ik doe dit om de simpele reden dat ik mij graag wat meer wil gaan verdiepen in het linux gebruik en hoe kan je beter beginnen dan met het vanaf de grond aan compileren van linux???

ik ben er op dit moment alleen nog niet uit hoe ik een kernel kan gaan optimaliseren en compileren???
wat heb ik bijvoorbeeld minimaal hier voor nodig???
en kan ik dit ook vanuit windows compileren of raden jullie mij echt aan om dit vanaf een live cd te doen.

om het geheugen hoef ik het trouwens niet te laten om met de aggresiefste switch *O3?* te gaan compileren en wat ik ook niet hieruit opmaak is of hij dan automatisch 64bit en SMP gecompileerd word...

en hoe stel ik dit standaard in voor gcc?? want daar kom ik dus nog steeds niet uit....

[ Voor 6% gewijzigd door Verwijderd op 06-05-2006 19:03 ]

[moto-moi]

Verwijderd schreef op zaterdag 06 mei 2006 @ 19:02:
ik doe dit om de simpele reden dat ik mij graag wat meer wil gaan verdiepen in het linux gebruik en hoe kan je beter beginnen dan met het vanaf de grond aan compileren van linux???

Door het te doen volgens de LFS manier zoals hierboven staat, gentoo staat voor veel gebruikers niet meer dan 'lang compileren voordat je iets installeerd', en da's meestal zonde van je tijd

en kan ik dit ook vanuit windows compileren of raden jullie mij echt aan om dit vanaf een live cd te doen.

livecd ? Linux installeer je gewoon op een partitie op je hardeschijf hoor

[Raven]

moto-moi schreef op zaterdag 06 mei 2006 @ 19:04:
[...]

Door het te doen volgens de LFS manier zoals hierboven staat, gentoo staat voor veel gebruikers niet meer dan 'lang compileren voordat je iets installeerd', en da's meestal zonde van je tijd


[...]

livecd ? Linux installeer je gewoon op een partitie op je hardeschijf hoor

volgensmij lees je zijn vraag niet goed, lees nog maar es

[Ybox]

Verwijderd schreef op zaterdag 06 mei 2006 @ 19:02:
bedankt voor jullie geweldige reacties!!!

ik heb dus bij deze voor gentoo gekozen omdat dit pakket het vanaf de grond af aan toe staat het systeem te optimaliseren.

ik doe dit om de simpele reden dat ik mij graag wat meer wil gaan verdiepen in het linux gebruik en hoe kan je beter beginnen dan met het vanaf de grond aan compileren van linux???

ik ben er op dit moment alleen nog niet uit hoe ik een kernel kan gaan optimaliseren en compileren???
wat heb ik bijvoorbeeld minimaal hier voor nodig???
en kan ik dit ook vanuit windows compileren of raden jullie mij echt aan om dit vanaf een live cd te doen.

om het geheugen hoef ik het trouwens niet te laten om met de aggresiefste switch *O3?* te gaan compileren en wat ik ook niet hieruit opmaak is of hij dan automatisch 64bit en SMP gecompileerd word...

en hoe stel ik dit standaard in voor gcc?? want daar kom ik dus nog steeds niet uit....

De beste manier is om het ff zelf uit te zoeken , zo werkt het heel vaak bij linux. Dus zelf redzaamheid is wel een pre
Opzich is de gentoo handbook vrij compleet, iig de oudere. Persoonlijk ben ik van mening dat het beste leerd door gewoon te beginnen, en dan langzamerhand optimalisaties in te voeren.

[Verwijderd]

Verwijderd schreef op zaterdag 06 mei 2006 @ 19:02:
ik heb dus bij deze voor gentoo gekozen omdat dit pakket het vanaf de grond af aan toe staat het systeem te optimaliseren.

ik doe dit om de simpele reden dat ik mij graag wat meer wil gaan verdiepen in het linux gebruik en hoe kan je beter beginnen dan met het vanaf de grond aan compileren van linux???

Als je het écht van de grond af wilt opbouwen is er maar 1 optie: Linux From Scratch. Maar die stap is wellicht te groot als je tot nu toe alleen wat met Linux gespeeld hebt. Dan kan je beter eerst een Gentoo-sessie doorlopen, gewoon om te zien hoe het opbouwen van een Linux systeem in zijn werk gaat. Vooral door hun uitstekende handleidingen en uitgebreide forum leer je daar enorm veel van. Heb je er dan nog geen genoeg van en wil je nog meer uit je systeem wringen, dan kan je altijd nog LFS gaan proberen.

ik ben er op dit moment alleen nog niet uit hoe ik een kernel kan gaan optimaliseren en compileren???

Dat leggen ze je in het Gentoo handboek haarfijn uit... stelt niet zoveel voor eigenlijk.

wat heb ik bijvoorbeeld minimaal hier voor nodig???
en kan ik dit ook vanuit windows compileren of raden jullie mij echt aan om dit vanaf een live cd te doen.

Het beste en makkelijkste is om dit vanaf de live-cd van Gentoo te doen. Alles wat je nodig hebt om een werkend systeem te bouwen staat hier op.
Vanuit Windows linux compileren??? Hoe had je je dat voorgesteld?

om het geheugen hoef ik het trouwens niet te laten om met de aggresiefste switch *O3?* te gaan compileren en wat ik ook niet hieruit opmaak is of hij dan automatisch 64bit en SMP gecompileerd word...

Over gcc optimalisaties zijn fora en websites volgeschreven, een simpel antwoord op de vraag 'welke CFLAGS moet ik gebruiken' is niet te geven. Er zijn enorm veel opties voor optimalisaties die elkaar ook nog eens beinvloeden. Ook hangt het er van af wat voor systeem (processor vooral natuurlijk) je hebt. Veel googlen is het beste advies dat ik je kan geven.

Alle GCC opties
GCC optimalisatie opties

Op deze site is ook veel te vinden, onder meer van de Opteron zijn er benchmarks gedaan met diverse instellingen.

Over het algemeen geldt dat -O3 vaak net iets té is, compileren duurt veel langer, binaries worden een stuk groter (waardoor ze trager worden geladen) en de extra optimalisaties die erin zitten werken vaak contra-produktief. Door de bank genomen kun je het best -O2 gebruiken, je ziet vaak ook dat pakketten die je vanaf source compileert (GCC zelf ook trouwens!) die standaard al toepassen.

Een belangrijke optie is -march=cputype (GCC manual: Generate instructions for the machine type cpu-type. The choices for cpu-type are the same as for -mtune. Moreover, specifying -march=cpu-type implies -mtune=cpu-type). Voor cputype moet je dan in jouw geval opteron invullen (GCC manual: cpu-type: k8, opteron, athlon64, athlon-fx : AMD K8 core based CPUs with x86-64 instruction set support. (This supersets MMX, SSE, SSE2, 3dNOW!, enhanced 3dNOW! and 64-bit instruction set extensions.) )

Ook nuttig:
-pipe : versnelt het compileren, omdat ie de tussenresultaten via pipes doorgeeft i.p.v. via temp-files
-fomit-frame-pointer : maakt een extra registertje vrij, altijd nuttig, maar je kan niet meer debuggen. Maar als je stript kan het toch al niet meer.
-s : strip binaries van debuginformatie, als je niet gaat debuggen heb je die rommel niet nodig en de binaries worden er een stuk kleiner van (en dus sneller geladen). Eigenlijk hoort deze thuis in LDFLAGS, maar ik zet hem voor de zekerheid ook maar in CFLAGS, kwaad kan het niet. Makefiles van pakketten zijn niet allemaal even netjes en consequent. Soms wordt de linker aangeroepen met alleen LDFLAGS, soms CFLAGS, soms allebei. gcc ziet zelf wel dat ie alleen voor de linker is bedoeld.

Deze kom je het meest tegen, er zijn er uiteraard nog véél meer, soms nuttig, soms niet, soms werkt het zelfs averechts. Veel lezen zou ik zeggen...
Gentoo Wiki
Thread over CFLAGS op Gentoo forum - zeer interessant

Je zou dus kunnen beginnen met CFLAGS="-march=opteron -O2 -s -pipe -fomit-frame-pointer" in je Gentoo make.conf bestandje te zetten.

en wat ik ook niet hieruit opmaak is of hij dan automatisch 64bit en SMP gecompileerd word...

64 bits doet gcc automatisch (vanwege -march=opteron, daarmee activeert ie ook -m64)
'SMP' is een instelling die je kan zetten in de kernel-configuratie. Gewoon selecteren en klaar.
Maar jij bedoelt waarschijnlijk dat je parallel wilt compileren, dat beide cores aan het werk gezet worden? Dat doe je d.m.v. 'make -jn' , waarbij n het aantal jobs is dat gelijktijdig wordt uitgevoerd. Je kan daarvoor het best het aantal cores + 1 invullen, dus als je een dual-core cpu hebt, doe je 'make -j3'. Onder Linux kan je dat als default instellen d.m.v de environment variabele MAKEFLAGS. Bij Gentoo noemen ze dat geloof ik MAKE_OPTS (geen idee waarom, CFLAGS en LDFLAGS zijn wel standaard?).

[dion_b]

Verwijderd schreef op zaterdag 06 mei 2006 @ 17:27:
Euh redelijk wazige opmerking dion_b, waar haal je het dat een linux KERNEL kan gecompileerd zijn met support voor gnome en/of kde?
Voor Gnome/KDE/QT/GTK maakt het helemaal niet uit hoe de kernel geconfigureerd is.

OK, misschien had ik de "(en kernel)" stuk moeten weglaten

By the way, kleine opmerking ivm gentoo:
hoe kan je het nou serieus nemen dat gentoo sneller is?
Je spendeert wekelijks enkele UREN om vanalles te compileren en hercompileren, terwijl sommige apps dan enkele microseconden sneller draaien, andere apps enkele seconden trager draaien (wegens het feit dat gcc nogal eens slechte code maakt bij al te agressieve optimalisaties) en nog andere apps helemaal niet meer willen draaien omdat je te agressieve CFLAGS hebt gebruikt...

Snelheid van installatie/compilatie is totaal iets anders als snelheid van executie. Ja, Gentoo installeren duurt *veel* langer dan vrijwel elk ander OS (muv ArchLinux, die op vergelijkbare principes werkt). Dat is inherent aan het concept. Maar installatie is iets wat je zeer zelden doet en daarom nauwelijks relevant is voor beoordeling van het gebruik van een OS. NetBSD installeert bijvoorbeeld zeer snel. Maakt dat het het beste OS Nee, het is een goed OS, maar dat heeft er geen zak mee te maken

Bovendien moet ik nog een app tegenkomen die niet draait bij "safe" CFLAGS zoals in de Gentoo wiki aangegeven

Zelfs in de allerbeste situatie, kan de performance winst van het hercompileren nooit op tegen de (CPU)tijd, moeite en elektriciteit die je erin moet stoppen...

Nee, dat is pertinent niet waar. Op een vrij modern desktop is de winst misschien discutabel (zo die er is komt het hooguit door het niet meeinstalleren van alle bloat, iets wat je bij Debian of Slack ook niet doet), maar ik kan uit eigen ervaring het verschil melden tussen Debian en Gentoo op mijn arme 64MB-limited notebook. Gewoon kernel + simpele windowmaker X omgeving kunnen ze allebei even goed, maar als je bijvoorbeeld een geheugenslurper als Firefox laadt merk je terdege het verschil tussen een -Os optimalisatie bij Gentoo en een -O2 optimalisatie zoals bij Debian gehanteerd wordt. Hij begint bij Debian veel eerder, veel meer en veel langer te swappen, gewoon omdat de binaries groter zijn en dus sneller die beperkte RAM volgooien.

En mbt verspilde CPU cycles en electriciteit: 90% van PCs doet 90% van de tijd niets anders dan uit hun digitale neus vreten. Sinds er desktopPCs zijn met Cool&Quiet maakt het misschien wat uit, maar op ouder spul dat toch niet terugclockt bij idle-toestanden kun je net zo goed die cycles ergens voor gebruiken als dat ze nutteloos staan te niksen. Muv de eerste install doe je alles namelijk gewoon in de background achter het werk waar het je echt om gaat

Maar ach, ieder zijn eigen smaak natuurlijk, er zullen altijd mensen zijn die graag zo'n grote opvallende spoiler op hun auto willen omdat ze dan sneller gaan enzo

Tss, elk z'n smaak idd, maar aangezien nettoresultaat van Gentoo meestal is dat je minder hebt dan anders, niet meer, is de vergelijking met de spoiler beetje mank. Als je een denigrerende vergelijking wilt maken, doe het dan met iemand die met een vijl de overtollige grammen af probeert te halen ofzo

[moto-moi]

dion_b schreef op zondag 07 mei 2006 @ 01:50:
Snelheid van installatie/compilatie is totaal iets anders als snelheid van executie. Ja, Gentoo installeren duurt *veel* langer dan vrijwel elk ander OS (muv ArchLinux, die op vergelijkbare principes werkt).

ArchLinux installeerd ook gewoon binaries hoor De installatie daarvan duurt +/- 20 minuten.

[XTerm]

Verwijderd schreef op zaterdag 06 mei 2006 @ 18:15:
[...]


Snelheid is echt onzin, tenzij je echt specifieke apps hebt die profiteren van 64 bit is het compleet nutteloos om de moeite te nemen alles in 64 bit te doen, 32 bit is makkelijker en zo nu en dan zelfs sneller ook.
Zie bijvoorbeeld:
http://www.osnews.com/story.php?news_id=5768&page=1

Interessant artikel. Mogelijke verklaring is dat gcc niet echt gebruik gaat maken van de 64 bits instructies. De performance winst zou moeten onstaan uit Instruction Level parallelism. Aan de andere kant blijkt vaak dat het transport van geheugen naar CPU de bottleneck is en dan zijn de grotere data hoeveelheden natturlijk nadelig.

Ik denk dat ik zelf eens wat benchmarkjes ga runnen op m'n AMD64 om te kijken of dit klopt

[Verwijderd]

Cyphax schreef op zaterdag 06 mei 2006 @ 03:02:
Een andere optie is een distro als Slackware of Debian installeren en finetunen (dat doe ik zelf graag, met Slackware, en die is achterlijk snel te krijgen) maar dat kost ook een hoop tijd. Het is wel erg leuk trouwens.

Wat tune jij precies aan Slackware, en hoeveel sneller wordt dat dan tov een standaard-installatie?

[Creepy]

Verwijderd schreef op zaterdag 06 mei 2006 @ 18:15:
[...]


Snelheid is echt onzin, tenzij je echt specifieke apps hebt die profiteren van 64 bit is het compleet nutteloos om de moeite te nemen alles in 64 bit te doen, 32 bit is makkelijker en zo nu en dan zelfs sneller ook.
Zie bijvoorbeeld:
http://www.osnews.com/story.php?news_id=5768&page=1

Deze benchmark gaat over een sparc. Niet over de nieuwere AMD 64 architectuur (die intel nu ook nadoet). De AMD64 heeft in 64 bits mode bijv. de beschikking over meer registers waardoor software op een andere manier geoptimaliseerd kan worden. Hierdoor kan het draaien van een 64 bits kernel met 32 bnits software al een snelheids winst opleveren (kan, ik zeg niet dat het zo is).
Als je het echt wilt weten, zoek dan een benchmark op die op een intel based 64 bit processor is gedaan (bijv. de AMD64), of benchmark zelf

[Verwijderd]

In de nieuwe IX magazine staat een lang artikel enkel over Linux optimalisatie.

[Cyphax]

Verwijderd schreef op zondag 07 mei 2006 @ 14:12:
[...]

Wat tune jij precies aan Slackware, en hoeveel sneller wordt dat dan tov een standaard-installatie?

Alle overbodige daemons uitzetten, veel met de bootscripts klooien zodat het allemaal op maat is voor mij. Dat is met namen bij het booten veel sneller (nu in pak 'm beet 30 seconden boot ie wel, en 't is een PC van enkele jaren oud).
Verder geen libraries laden die niet nodig zijn, dan neemt je OS wat minder geheugen in beslag, dat hou je over voor applicaties. Minder swappen is leuker.
Mijn voorkeur gaat er altijd naar uit om in eerste insantie een vrij minimale install te doen, en dan daarna de rest erbij installeren (Gnome, KDE, dat soort dingen)

[_JGC_]

Verwijderd schreef op zaterdag 06 mei 2006 @ 18:15:
[...]


Snelheid is echt onzin, tenzij je echt specifieke apps hebt die profiteren van 64 bit is het compleet nutteloos om de moeite te nemen alles in 64 bit te doen, 32 bit is makkelijker en zo nu en dan zelfs sneller ook.
Zie bijvoorbeeld:
http://www.osnews.com/story.php?news_id=5768&page=1

De enige snelheid die 64bit geeft tov 32bit is bij gebruik van 64bit functies van je CPU die je niet op 32bit hebt. Een daarvan is het adresseren van meer dan 896MB geheugen zonder gore workarounds zoals dat gare pageframe wat ze "HIGHMEM" noemen op 32bit linux. Doet me meteen denken aan EMM386 en EMS op de 486 in DOS destijds

Nadelen aan een 64bit desktop zijn er ook:
- al je software moet geschikt zijn, inclusief non-free rotzooi zoals flashplugin
- je hebt een 32bit environment nodig wat niet altijd lekker samenwerkt met je 64bit environment (een 32bit flashplugin gaat dus niet werken in een 64bit firefox)

IMHO heeft AMD64 alleen veel nut op dingen als databaseservers, waar je enorme brokken geheugen direct wilt kunnen adresseren.

[Verwijderd]

Verwijderd schreef op zaterdag 06 mei 2006 @ 19:02:
ik ben er op dit moment alleen nog niet uit hoe ik een kernel kan gaan optimaliseren en compileren???
wat heb ik bijvoorbeeld minimaal hier voor nodig???
en kan ik dit ook vanuit windows compileren of raden jullie mij echt aan om dit vanaf een live cd te doen.

Kernel compileren zou ik echt gewoon vanuit linux doen, misschien kan het ook wel vanuit windows met enig kunst- en vliegwerk maar makkelijk/praktisch zal het niet zijn.

Om je eigen kernel te compileren heb je allereerst compilers nodig en die zijn meestal standaard onderdeel van de linux installatie (iig wel bij gentoo). Daarnaast heb je natuurlijk de sources van de kernel nodig. Die vind je oa op www.kernel.org. Pak de sources uit in een map (meest voor de hand liggend is /usr/src/linux-<kernelversie>), ga in de map staan waar alles instaat en tik "make menuconfig". Je komt dan in een scherm waar je voor alle onderdelen kan kiezen of je ze in de kernel wil opnemen. Dat is wel een werkje, doe dit zorgvuldig en lees de help pagina's bij alle opties goed, en zorg dat je exact weet wat voor hardware in je pc hebt, en hou ook goed in je achterhoofd wat je allemaal wil gaan doen met je pc. Ondersteuning voor hardware die je niet hebt kun je weglaten, features die je niet nodig gaat hebben ook. Maar let op. er zijn van die opties waarvan je zou kunnen denken "die heb ik niet nodig" maar die toch wel essentieel zijn, zeker als je wil optimizen. Goed lezen dus. Dingen die je niet altijd nodig hebt kun je als modules compileren, zodat ze alleen ruimte innemen als je ze ook daadwerkelijk gebruikt. Als je alles geconfigd hebt kun je de kernel en modules gaan compileren, bijv dmv "make dep && make bzImage && make modules && make modules_install" (er gaan meerdere wegen naar rome). Daarna zul je nog de kernel in je bootloader moeten opnemen (LILO of Grub). Je kan meerdere kernels in je bootloader opnemen, zorg er altijd voor dat je een werkende kernel hebt waar je op terug kan vallen, want het zal ongetwijfeld een keer gebeuren dat je een foutje hebt gemaakt waardoor je versgebakken kernel niet (goed) opstart.

Ik zou je willen aanraden om de kernel howto (wel wat verouderd, er is ook genoeg andere documentatie) goed door te nemen, daar staat het veel uitgebreider in. Verder is het gewoon een kwestie van vallen en opstaan en veel lezen en experimenteren, succes!

[Verwijderd]

thnx dit was informatie waar ik mij rot naar heb zitten zoeken... kon het eigenlijk ook niet vinden in de gentoo handleiding....

tis alleen momenteel heel erg vreemd... mijn X start op want ik heb een grafische login en kan ik inloggen... ook heb ik gnome geinstalleerd, maar zodra hij de kicker gaat laden lijkt de hele pc vast te lopen... wel de standaard balk boven en onder ( ze blijven wel leeg) en een werkende muis maar het toetsenbord lijkt ook niets meer te doen want als ik numlock of capslock of scrolllock indruk doet et ledje op men toetsenbord ook niets...

dus voor het laden van de windowmanager heb ik een werkende X, na het inloggen wat gewoon lukt via het toetsenbord doet ie niets meer...

ook de failsafe kernel doet niets...

[_JGC_]

Let je er trouwens wel even op dat je al je Gentoo compiles op een aparte partitie doet ipv op je rootfs of je /usr? Alle evt snelheidswinst die je zou kunnen boeken met een "geoptimaliseerd" systeem spoel je zo door de WC dankzij de enorme fragmentatie die het veelvuldige compilen met zich meebrengt.

[Wilke]

_JGC_ schreef op woensdag 17 mei 2006 @ 09:49:
Let je er trouwens wel even op dat je al je Gentoo compiles op een aparte partitie doet ipv op je rootfs of je /usr? Alle evt snelheidswinst die je zou kunnen boeken met een "geoptimaliseerd" systeem spoel je zo door de WC dankzij de enorme fragmentatie die het veelvuldige compilen met zich meebrengt.

Hmm. Heb je cijfers die laten zien dat door veelvuldig compilen inderdaad fragmentatie ontstaat? Volgens mij worden de bestanden daarna namelijk weer gewist en is de ruimte die gebruikt werd gewoon weer vrij. Zou wel mee moeten vallen met fragmentatie denk ik.

Ook daar heb ik geen cijfers voor om het te laten zien, maar om speciale acties te ondernemen vanwege een vermeend probleem dat misschien helemaal niet bestaat, tja...beetje overbodig misschien.

Hetzelfde geldt overigens voor al die CFLAGS-ellende in Gentoo. Je kunt daar het best gewoon van af blijven. De kracht van Gentoo zit 'm in het portage-systeem, gecombineerd met USE-flags. Bij de meeste andere distributies zijn bepaalde opties simpelweg wel of niet meegecompileerd, en daar heb je het dan maar mee te doen. Bij Gentoo kun je het veel meer zelf bepalen door USE-flags te gebruiken. Wil je LDAP support in applicaties die het ondersteunen? Zet de +ldap-vlag. Wil je dat helemaal niet (bv. omdat het onnodig ruimte gebruikt, of omdat je denkt dat het niet veilig is)? Zet die vlag dan niet en de support wordt gewoon niet eens geinstalleerd.

Zie ook dit artikel voor dingen waarin Gentoo uitblinkt.

Om hetzelfde met binary distributies te bereiken, zou je een praktisch ontelbaar aantal binary packages moeten hebben (voor elke zinvolle combinatie van useflags een package).

Een nadeel van de Gentoo-aanpak is natuurlijk wel dat niet elke combinatie misschien door evenveel mensen gebruikt wordt en dus niet altijd volledig getest is. Resultaat is dat (zeker in de Unstable tree) je soms wel combinaties kunt veroorzaken waardoor het geheel bv. niet eens compileert, of wel compileert maar niet werkt. Maar ik moet zeggen dat ik dat in de praktijk nog maar zelden heb gehad; misschien wel omdat ik meestal niet zo ver van de gebaande paden afwijk.

Anyway, Gentoo geeft dus veel controle en je kunt bovendien veel leren over hoe het hele systeem in elkaar zit. Echter, de meeste distributies hebben ook vrij redelijke defaults dus als je bereid bent de standaard-paden van de door jou gebruikte distributie te volgen (iets wat mij vaak mateloos irriteert, omdat die installers vaak config-files wijzigen, overschrijven, vernaggelen etc.) dan scheelt het wel veel moeite - laten we dat vooral niet ontkennen

[_JGC_]

Wilke schreef op woensdag 17 mei 2006 @ 11:03:
[...]
Hmm. Heb je cijfers die laten zien dat door veelvuldig compilen inderdaad fragmentatie ontstaat? Volgens mij worden de bestanden daarna namelijk weer gewist en is de ruimte die gebruikt werd gewoon weer vrij. Zou wel mee moeten vallen met fragmentatie denk ik.

Ook daar heb ik geen cijfers voor om het te laten zien, maar om speciale acties te ondernemen vanwege een vermeend probleem dat misschien helemaal niet bestaat, tja...beetje overbodig misschien.

Zelf ben ik package maintainer van archlinux en compileer ik dus redelijk veel zooi op mijn systeem. Ik gebruik hiervoor een losse partitie met daarin een chroot systeem om te zorgen dat compiles redelijk schoon zijn.

Ik kan gewoon merken dat bepaalde operaties (package installeren, package updaten, sources uitpakken, etc) na verloop van tijd meer tijd gaan vreten, en dan heb ik een 10K RPM disk in mijn bouw-bak zitten.

[eghie]

Verwijderd schreef op woensdag 17 mei 2006 @ 09:38:
thnx dit was informatie waar ik mij rot naar heb zitten zoeken... kon het eigenlijk ook niet vinden in de gentoo handleiding....

tis alleen momenteel heel erg vreemd... mijn X start op want ik heb een grafische login en kan ik inloggen... ook heb ik gnome geinstalleerd, maar zodra hij de kicker gaat laden lijkt de hele pc vast te lopen... wel de standaard balk boven en onder ( ze blijven wel leeg) en een werkende muis maar het toetsenbord lijkt ook niets meer te doen want als ik numlock of capslock of scrolllock indruk doet et ledje op men toetsenbord ook niets...

dus voor het laden van de windowmanager heb ik een werkende X, na het inloggen wat gewoon lukt via het toetsenbord doet ie niets meer...

ook de failsafe kernel doet niets...

Kun je daarvoor niks in de logs terug vinden dan?

[Wilke]

_JGC_ schreef op woensdag 17 mei 2006 @ 11:22:
Ik kan gewoon merken dat bepaalde operaties (package installeren, package updaten, sources uitpakken, etc) na verloop van tijd meer tijd gaan vreten, en dan heb ik een 10K RPM disk in mijn bouw-bak zitten.

Hmm, interessant wel. Hangt natuurlijk ook af van partitiegrootte, hoeveelheid vrije ruimte (weinig vrij = sneller fragmentatie) en, vooral niet te vergeten, gebruikt filesystem type.

Ben wel benieuwd welke je gebruikt(e) op het moment dat je deze problemen opmerkte?

[Verwijderd]

Voor embedded systemen is het zelf compileren van kernels essentiëel, maar in een normale bedrijfsomgeving moet je het niet overschatten. (ik zou het niet doen, de prestatie winst is minimaal)
Ook met het statisch linken van kernelmodules win je hooguit 1 of 2% terwijl het systeem in sommige gevallen zelfs langzamer kan worden.

Nog wat demonen die je evt. uit zou kunnen zetten bij gebruik na een server

apmd (power management)
autofs (hoe vaak mount je nou iets nieuws op een server?)
cpuspeed (stuurt variabele klokfrequentie, niet nodig op een server)
cups (printserver functies voor UNIX. is bejaard. mag uit)
gpm (muisondersteuning op teksmode console. niet nodig)
isdn (eh tsja..waarschijnlijk niet nodig)
kudzu (de plug and play van linux. niet nodig op servers)
pcmcia (neem aan dat het geen laptop betreft)
rawdevices (Alleen nodig voor bepaalde software, oracle bijv)
sendmail (indien geen mailserver....)
xfs (font server voor X, neem aan dat de server geen desktop start....)

[Z-Dragon]

Variabele klokfrequentie niet nodig op een server?! Dat is juist een van de mooiste dingen die er zijn om een zuinig servertje te maken!

[moto-moi]

Ligt eraan waar je de server voor nodig hebt, voor een thuisservertje kan het bijvoorbeeld prima, maar ik zou niet graag onze servers ermee uitrusten, dat levert meer ellende dan voordeel op

[Verwijderd]

Z-Dragon schreef op vrijdag 19 mei 2006 @ 16:48:
Variabele klokfrequentie niet nodig op een server?! Dat is juist een van de mooiste dingen die er zijn om een zuinig servertje te maken!

Nou, ik heb het niet zelf bedacht maar goed gejat.
Het staat in "Tuning Red Hat Enterprise Linux" uit de IBM Redpaper van 15 juli 2005 voor het configureren van IBM xSeries Servers geschreven door Eduardo Ciliendo IT specialist binnen IBM.
Het staat ok in IX magazine (prof. magazine) van Mei dit jaar op pagina 21