Gentoo Performance

[Verwijderd]

Ik heb gezocht op tweakers en met google, maar ik kan nergens vinden hoeveel sneller Gentoo is als bijvoorbeeld Debian. Er staat wel een vergelijking op de Gentoo site van Gentoo en Mandrake, maar dat vind ik niet echt een goede vergelijking omdat dat niet echt onafhankelijk is gedaan door een andere partij.

Ik zou graag willen weten wat jullie bevindingen zijn met Gentoo. Is het echt sneller?
Theoretisch zou ik denken dat het inderdaad sneller moet zijn, maar ik kan nergens echte feiten hierover vinden.

Zijn er misschien gebruikers die Debian en Gentoo geinstalleerd hebben? Zoja, zouden jullie dan een paar benchmarks kunnen doen. Hoe lang het opstarten duurt bijvoorbeeld van het OS en van verschillende programma's.

Ik heb Debian en Gentoo ook zitten vergelijken en het package systeem van Gentoo werkt ook ongeveer hetzelfde als Debian, maar die moet alleen alles nog compilen.
Of zie ik hier nog iets over het hoofd?

Kortom: ik zou graag jullie bevindingen met Gentoo willen horen! En dan niet alleen de voordelen, maar ook de nadelen die je ondervonden hebt.

[dawuss]

Tsja, in hoeverre architectuur-geoptimaliseerde binaries sneller zijn dan de standaard i386 binaries die ander distributies voor x86 (ik neem aan dat je dat draait) leveren, heb ik nooit echt geprobeerd.
Wat voor mij voldoende reden was om Gentoo te gaan draaien, was dat het package systeem erg goed werkt (en ja, ik kwam van debian af). Ze zijn heel snel met het updaten van de package tree, waardoor je altijd de meest nieuwe software kunt hebben (mits je "unstable" draait). Verder bevalt de Gentoo filosofie me wel: Maximum Customisability. Vooral het concept USE variabele staat me erg aan

[Wilke]

Definieer 'sneller'.


Maar de grootste kracht van Gentoo is w.m.b. niet (eventueel vermeende) snelheidswinst, maar het package management. Inderdaad moet je alles compilen dus dat kost veel extra tijd, maar je kunt bij alle pakketten dan wel weer precies aangeven wat er wel/niet meegecompileerd wordt (door middel van USE-flags). Bijvoorbeeld of KDE ook support moet hebben voor SMB (windows netwerken), of niet. Dat soort dingen. En dat kan AFAIK bij Debian dan weer niet.

Het enige nadeel is dat je het dus niet op een traag systeem moet doen, en dat het veel tijd kan kosten om het te installeren (wel als je alles 'from scratch' gaat compilen iig - niet dat dit *moet* hoor, er zijn gewoon CD's te downloaden met binary pakketten).


Edit: hey dawuss, anders posten we even in dezelfde minuut een post met dezelfde strekking

[ Voor 7% gewijzigd door Wilke op 04-08-2004 11:38 ]

[Miki]

Tis moeilijk te zeggen hoe veel de performance is. Het is zo ie zo allemaal wat vlotter maar vergis je ook niet in het placebo effect. Daarnaast is de snelheids winst ook weer weg als je steeds uren moet compilen voor de laatste software, dus moet je zo ie zo snelle hardware hebben wil je er niet aan gaan ergeren. Ik heb een stage 3 install op een P233 met 96mb gedaan en was daarmee 18 uur kwijt. Op mijn p4 2.53ghz een kleine 6 uur met gnome, maar wel kaal voor de rest!

Persoonlijk vindt ik het wel de distro voor tweakers. Hoge vorm van vrijheid en een enorme community -> prima forum en documentatie. Je hoeft dus niet uren op google te zoeken naar het ene forum wat jou specifieke linux probleem verhelpt.

[ Voor 16% gewijzigd door Miki op 04-08-2004 11:46 ]

[dawuss]

Wilke schreef op 04 augustus 2004 @ 11:37:
Edit: hey dawuss, anders posten we even in dezelfde minuut een post met dezelfde strekking

* dawuss mompelt iets over great minds, die alike denken

Wampie: Heb je eigenlijk al op google gezocht naar performance benchmarks? Het lijkt me sterk dat deze niet bestaan.

Overigens, persoonlijk merk ik minder van de performance increase door het optimaliseren naar architectuur, dan van het gebruik van de "pre-emptible kernel" feature die in de 2.6 tree eindelijk mainstream is geworden

Niet dat je systeem er sneller van wordt, maar het reageert soepeler. (Best grappig om te zien hoe enorm goed je nog kunt browsen, coden en textverwerken terwijl je met 2 processen druk aan het compilen bent )

[ Voor 12% gewijzigd door dawuss op 04-08-2004 11:45 ]

[Wilke]

Als we gaan ouwedeuren over performance/snelheid, kunnen we dan ten minste even definieren waarover we het hebben?

I/O throughput? Latency? Tijd die het duurt tot een app op je scherm staat nadat je er op hebt geklikt? Hoe lang het duurt om een bepaalde ingewikkelde macro in openoffice uit te voeren? Hoe lang het duurt om een bepaalde kernel te compilen?

Het probleem is, dat het van zoveel dingen afhangt - hardware, kernel versie, compile flags, prelinking ja of nee, filesystem type - dingen die ook per distributie verschillen (per minor versie zelfs) en helemaal bij Gentoo.

_{dit is dus eigenlijk een subtiele manier om te zeggen dat dit IMHO een zinloze discussie is. Maar wat wel interessant is: voor welke doeleinden kies je - afgezien van performance - wel of niet voor het gebruik van Gentoo?}

[Bas!]

Hmm pre-empt belangrijk?
Niet meer, lees maar eens wat stukjes van andrew morton. Bovendien is pre-empt niet echt wenselijk. Het leidt in sommige gevallen tot onwenselijk gedrag. Met hyperthreading aan heb ik er vaag gedrag mee gezien hier.
De 2.6 heeft gewoon veel betere io en cpu schedulers. Dat is wat je merkt. Een pre-emptive kernel is niet zo belangrijk meer.

En on topic. Gentoo heeft een aantal features die wel handig zijn, zoals pre-linking. Daar houdt gentoo wat meer rekening mee dan bijvoorbeeld Debian en dat merk je soms bij het opstarten van programma's. Beschouw het als ms' prefetch functie in NT5.

[ Voor 28% gewijzigd door Bas! op 04-08-2004 11:57 ]

[Bananenplant]

hm, ik zal zelf niet zo snel weer gentoo gebruiken... ik heb een jaar terug gehad en ik moest op den duur 133 config files handmatig bijwerken. dan vind ik iets als debconf toch wel handig, up-to-date blijven vind ik prima, maar ik wil m'n systeem vooral gebruiken ipv dingen bij moet werken.

verder heb ik hier op debian ook eens een heleboel dingen zelf gecompileerd en over de binaries heengezet, het maakte geen reet uit

prelink heb ik ook... moet het alleen zelf doen

[ Voor 7% gewijzigd door Bananenplant op 04-08-2004 11:58 ]

[Mayco]

kijk, ik heb lang gentoo gebruikt, alles mooi, maar er ging vaak iets mis, dan keek je op het gentoo forum, en dan stond er wel een uitleg, in dat opzicht heb ik heel veel geleerd van linux. maar ik was het nogal beu om altijd aanpassingen te maken als er weer iets was dat niet goed was...
nu heb ik fedora core 2, wel wat aangepast, nieuwe kernel... en ik merk eigenlijk geen verschil kwa snelheid. Ik ben blij met fedora core 2 omdat ik nu eindelijk gewoon kan werken en alles werkt gewooon. toch ben ik ook blij om gentoo gebruikt te hebben, je leert er echt wel van, ook de structuur van je os word zo duidelijker, hoe start je pc op...

[BoAC]

Mayco schreef op 04 augustus 2004 @ 12:03:
maar ik was het nogal beu om altijd aanpassingen te maken als er weer iets was dat niet goed was...

Je hoeft ook niet elke week te updaten?
En bij andere distro's kan het updaten net zogoed fout gaan

toch ben ik ook blij om gentoo gebruikt te hebben, je leert er echt wel van, ook de structuur van je os word zo duidelijker, hoe start je pc op...

Agree

[dawuss]

ucchan schreef op 04 augustus 2004 @ 11:57:
hm, ik zal zelf niet zo snel weer gentoo gebruiken... ik heb een jaar terug gehad en ik moest op den duur 133 config files handmatig bijwerken.

Dan doe je toch echt iets niet goed.

Bij Gentoo wordt inderdaad bij alle configfile updates gevraagd wat je er mee wil. Dat wil lang niet in alle gevallen zeggen dat je er ook handmatig iets mee moet doen. Als het een configfile is die je zelf niet hebt aangepast, is het alvast heel eenvoudig: daarbij laat je je oude file vervangen door de nieuwere versie. Anders gaat het vaak om triviale wijzigingen, die je heel makkelijk met de "diff" interface kunt doorlopen. Mijn ervaring is bovendien dat het er gemiddeld niet meer dan 10 per maand zijn, dus zo veel tijd gaat er niet in zitten.
Het grote voordeel is hierbij dat de kennis over configfiles niet wordt verdoezeld door menu's, zoals het bij debian wel het geval is

Verder hebben de configfiles natuurlijk erg weinig met de snelheid van Gentoo te maken he

Om even terug on topic te komen: De snelheidswinst bij Gentoo zit hem niet per se in de optimalisaties bij het compilen (daarbij bedoel ik: compileren voor een specifieke architectuur, zoals de athlon-xp).

Een performance applicatie als mplayer of mencoder, wordt geschreven met het oog op moderne processoren. Instructiesetuitbreidingen als MMX, 3DNow! en SSE worden vanuit de software zelf ondersteund, maar de meeste binary distributies leveren de mplayer binaries zonder deze uitbreidingen, omdat die er vanuit gaan dat het ook op minimale hardware, zoals bijvoorbeeld een 386, moet kunnen draaien. In Gentoo is dit gewoon een USE flag, zodat dit automatisch meegecompileerd wordt.
_{Ja, ik weet dat mplayer met zijn runtime detection een slecht voorbeeld is voor wat ik probeer uit te leggen, maar ik kon zo vlug even geen beter voorbeeld verzinnen}

Overigens: Als de enige reden waarvoor je Gentoo wil draaien hardwareoptimalisatie is, kun je ook eens kijken naar Arch Linux

[Bananenplant]

sja, ik hou het fijn bij debian, dat het m'n eigen luiheid is van die config files bestrijd ik ook niet

[JaQ]

Wilke schreef op 04 augustus 2004 @ 11:50:.
_{dit is dus eigenlijk een subtiele manier om te zeggen dat dit IMHO een zinloze discussie is. Maar wat wel interessant is: voor welke doeleinden kies je - afgezien van performance - wel of niet voor het gebruik van Gentoo?}

offtopic:
Dit is dus precies de discussie die ik vorige week met een klant had: wat is performance. Performance is volgens mij gewoon een gevoel. Ja, het is meetbaar of iets sneller draait, maar uiteindelijk gaat het er om of het acceptabel is of niet. Of ik nou 5 minuten of 4.5 minuten op een proces moet wachten maakt me niet uit --> het duurt gewoon lang.

Terug naar de TS:

Echte performance winst door het zelf compileren van software kan variëren tussen de 2.5 en 15 procent (heb ik ooit ergens gelezen). Belangrijke randvoorwaarde: mits de juiste configuratie is gedefinieerd (dus denk aan je hints)

[irondog]

Performance is voor mij dat je 30 seconden na het inschakelen van je pc je desktop ziet. Ik denk dat gentoo daar niet de allerbeste in is. In deze situatie boeien optimalisaties in het build process echt niet (prelinken ff daargelaten).

Zo vind ik de gedachte dat ik 70 gig aan wave bestanden sneller naar mp3 om kan zetten omdat ik lame gecompileerd heb met bepaalde c-flags is leuk, maar echt niet meer dan dat: Je zet het net als een ellenlang compileer proces aan en kijkt er een dag niet meer naar om. Wat is je winst?

Om daar maar zelf antwoord op te geven:
- beetje meer inzicht in linux en meer tweakbaarheid (ik wil nix met arts te maken hebben, USE="-arts" vaarwel arts)
- een werkelijk gigantisch pakket aan beschikbare software (groter dan elke andere distrto).

[dawuss]

irondog schreef op 04 augustus 2004 @ 14:40:
Performance is voor mij dat je 30 seconden na het inschakelen van je pc je desktop ziet. Ik denk dat gentoo daar niet de allerbeste in is. In deze situatie boeien optimalisaties in het build process echt niet (prelinken ff daargelaten).

Ruwe performance meten aan opstarttijd van het besturingssysteem alleen vind ik heel erg kortzichtig. Als ik een systeem maak dat binnen 1 seconde opstart, maar er vervolgens wel 10 minuten over doet om bijvoorbeeld een mozilla window te openen, vind ik dat geen goede performance. Performance gaat in zijn ruimste definitie over het gevoel dat je hebt als je met het systeem werkt.

Zo vind ik de gedachte dat ik 70 gig aan wave bestanden sneller naar mp3 om kan zetten omdat ik lame gecompileerd heb met bepaalde c-flags is leuk, maar echt niet meer dan dat: Je zet het net als een ellenlang compileer proces aan en kijkt er een dag niet meer naar om. Wat is je winst?

Als je vaak dingen van dit kaliber doet, en het scheelt uren, is dat misschien best interessant. Dat is niet aan jou om te beoordelen
Ik ben het wel met je eens dat dit voor vrijwel niemand interessant is. Wat in mijn ogen veel interessanter is: Als je wekelijks gigabytes aan data moet encoderen, is het misschien wel fijn als je tegelijkertijd ook nog op die pc kan werken, in plaats van wachten tot de resources weer beschikbaar komen.

[Bananenplant]

dawuss, zeg je nu dat dat vooral ligt aan de binaries die op je systeem staan

de kernel doet toch al het schedulingwerk... en die geoptimaliseerd compileren is op geen enkele distro raar...

[irondog]

dawuss schreef op 04 augustus 2004 @ 14:48:
Ruwe performance meten aan opstarttijd van het besturingssysteem alleen vind ik heel erg kortzichtig.

Klopt, is het ook.

Als ik een systeem maak dat binnen 1 seconde opstart, maar er vervolgens wel 10 minuten over doet om bijvoorbeeld een mozilla window te openen, vind ik dat geen goede performance. Performance gaat in zijn ruimste definitie over het gevoel dat je hebt als je met het systeem werkt.

Daarin zullen grote verschillen te vinden zijn van distro tot distro, maar dat is dus precies het gebied waar je niets wint wanneer je een compileerproces gaat aanpassen op je hardware.

Als je vaak dingen van dit kaliber doet, en het scheelt uren, is dat misschien best interessant. Dat is niet aan jou om te beoordelen

Ik zou een keer zelf de bench moeten gaan doen met zip, tar, lame, unrar, mencoder enz. Als ik vanavond tijd heb...

Ik ben het wel met je eens dat dit voor vrijwel niemand interessant is. Wat in mijn ogen veel interessanter is: Als je wekelijks gigabytes aan data moet encoderen, is het misschien wel fijn als je tegelijkertijd ook nog op die pc kan werken, in plaats van wachten tot de resources weer beschikbaar komen.

We zijn het dus in grote lijnen eens, maar op het laatste heb ik nog wat te zeggen:
Het doen van dagelijkse dingen zou vrijwel niet mogen lijden onder het compileren op de achtergrond als je de gentoo-sources gebruikt (dat claimen ze zelf).

Nu komt het: de stable gentoo sources (kernel 2.4) geven me nu juist alles behalve een desktop die goed reageert terwijl je iets aan het builden bent. Het schokt het hapert, het reageert slecht, het bouwt een stock kernel en komt nooit meer terug op mijn systeem.

[dawuss]

ucchan schreef op 04 augustus 2004 @ 15:25:
dawuss, zeg je nu dat dat vooral ligt aan de binaries die op je systeem staan

de kernel doet toch al het schedulingwerk... en die geoptimaliseerd compileren is op geen enkele distro raar...

Yup, dat scheduling van groot belang is voor je performance is helemaal waar, maar je kunt op iedere distributie wel zelf een kernel bakken.

Wat je bij Gentoo doet, is de binaries zelf optimaliseren voor je architectuur. Als je daar benieuwd naar bent, kun je daarover genoeg vinden op gentoo.org

[BoAC]

dawuss schreef op 04 augustus 2004 @ 15:31:
[...]

Yup, dat scheduling van groot belang is voor je performance is helemaal waar, maar je kunt op iedere distributie wel zelf een kernel bakken.

Wat je bij Gentoo doet, is de binaries zelf optimaliseren voor je architectuur. Als je daar benieuwd naar bent, kun je daarover genoeg vinden op gentoo.org

Wat bij andere distro's niet kan is het uitschakelen van bijvoorbeeld OpenGL. Deze wordt gewoon meegebouwd. Dit is bij gentoo uit te schakelen dmv de USE variabelen. Hierdoor wordt de distro minder 'log' dan bijv. SuSE
Zie use flags

[irondog]

JA, daar heb ik gisteren op mijn lanparty-server dankbaar gebruik van gemaakt:
emerge amercas-army (dat is een cross platform fps game) gaf me een waslijst dependancies waaronder Xfree.

USE="-opengl" emerge amercas-army installeerde een niet speelbare server editie. Om dit soort redenen wil je Gentoo, en dan is het echt sneller: ga dit spel maar eens met je browser zoeken en downloaden, laat mij maar wachten!

[Verwijderd]

dawuss schreef op 04 augustus 2004 @ 15:31:
Wat je bij Gentoo doet, is de binaries zelf optimaliseren voor je architectuur. Als je daar benieuwd naar bent, kun je daarover genoeg vinden op gentoo.org

En 99% van je applicaties zit de hele dag op user input te wachten, dus dat maakt echt zoveel uit in performance, he? Ik ben het met Wilke eens, dat gedeelte van de discussie is zinloos. Qua X libs, libc en kernel (vooral je kernel!) maakt het ietsje uit, maar voor de rest boeit het totaal niet. Gentoo is niet sneller dan eenzelfde prebuilt distributie met dezelfde configuratie. Het zal je overigens vast wel opgevallen zijn dat distributies als RedHat i686-optimized binaries van je kernel en libc meeleveren. Daarom dus. .

Gentoo is wel nuttig voor:
• leren hoe je OS in elkaar steekt
• custom distro / build flags
• etc.
Maar dan herhaal ik slechts wat hierboven al 10x eerder is gezegd.

[Bananenplant]

dawuss schreef op 04 augustus 2004 @ 15:31:
[...]

Yup, dat scheduling van groot belang is voor je performance is helemaal waar, maar je kunt op iedere distributie wel zelf een kernel bakken.

Wat je bij Gentoo doet, is de binaries zelf optimaliseren voor je architectuur. Als je daar benieuwd naar bent, kun je daarover genoeg vinden op gentoo.org

ik weet ook wel dat gentoo zelfgebouwde binaries gebruikt, maar het lijkt mij dus niet de taak van de binaries zelf om te zorgen dat de resources van je systeem goed verdeeld worden, daarom kwam ik met die kernel scheduler

[dawuss]

ucchan schreef op 04 augustus 2004 @ 16:22:
[...]


ik weet ook wel dat gentoo zelfgebouwde binaries gebruikt, maar het lijkt mij dus niet de taak van de binaries zelf om te zorgen dat de resources van je systeem goed verdeeld worden, daarom kwam ik met die kernel scheduler

Ik denk ook wel dat die van grotere invloed is dan optimised binaries hoor, maar vandaar deze discussie

[Niek]

Er hier al wel eens een soortgelijk topic geweest aantal jaar terug, en daar replyde ik dit: The_Surfer in "wie heeft hier gentoo linux en wat vind ..."
Ik ben het er nog steeds mee eens In mijn ervaring zijn mijn zelf gecompileerde packages in Gentoo toch echt een stuk sneller dan dezelfde i386 precompiled packages in Debian (unstable).
Komt nog bij dat met bijvoorbeeld de komst van NPTL of GCC 4.4 het in Gentoo erg makkelijk is over te stappen. Je recompiled even glibc, of je doet (in het geval van een ABI incompatible GCC release) emerge -e world en klaar.
Portage is erg goed, alleen begint het ATM wel een beetje uit zijn voegen te groeien. Ik ga binnenkort eens spelen met een server-side versie ervan (PHP/MySQL backend, emerge queried gewoon de server dus geen sync meer nodig, razendsnel zoeken etc).

[AlterEgo]

The_Surfer schreef op 04 augustus 2004 @ 16:55:
... met bijvoorbeeld de komst van [...] GCC 4.4 ...

offtopic:
Heftig

Bedoel je deze methode van mysql/portage combineren? Heb je ervaringen, want hij staat op mijn lijstje om te proberen, en in dat topique is men niet laaiend over de snelheidswinst.

Om nog een beetje aan te haken met "performance", en de zaak ingewikkelder te maken:
Ik heb een machine met bijna identieke Gentoo x86 en FC1 installaties draaien (beiden 2.6 kernel). Qua response/snelheidsgevoel geven ze elkaar weinig toe, totdat de load toeneemt. Bij een load > 2 ofzo wint Gentoo met twee vingers in de neus.

[ Voor 12% gewijzigd door AlterEgo op 04-08-2004 17:13 . Reden: foutjes enzo ]

[BoAC]

AlterEgo schreef op 04 augustus 2004 @ 17:09:
[...]
Om nog een beetje aan te haken met "performance", en de zaak ingewikkelder te maken:
Ik heb een machine met bijna identieke Gentoo x86 en FC1 installaties draaien (beiden 2.6 kernel). Qua response/snelheidsgevoel geven ze elkaar weinig toe, totdat de load toeneemt. Bij een load > 2 ofzo wint Gentoo met twee vingers in de neus.

Zou je misschien de CFLAGS en CXXFLAGS van beide distro's moeten vergelijken.
Misschien zit daar de snelheidswinst wel op. FC1 moet tenslotte ook op machines draaien zonder processor optimalisaties
Kwa kernel config zullen ze beiden wel niet zoveel verschillen, tenminste ik neem aan dat je voor FC1 zelf de kernel hebt gebakken

[ Voor 12% gewijzigd door BoAC op 04-08-2004 17:17 ]

[Niek]

AlterEgo schreef op 04 augustus 2004 @ 17:09:
[...]

offtopic:
Heftig

Ehm ja.. 3.4 dus

Bedoel je deze methode van mysql/portage combineren? Heb je ervaringen, want hij staat op mijn lijstje om te proberen, en in dat topique is men niet laaiend over de snelheidswinst.
(...)

Om eerlijk te zijn was dat topic me nog niet opgevallen. Het lijkt een beetje op wat ik van plan was te maken (niet helemaal, ik wil alle ebuilds in de DB opslaan en niet alleen de structuur zoals dit ding), ik zal er eens naar kijken hoe dit werkt. Zeker met dingen als emerge -S (wat nu tot vele minuten duurt) kunnen dan in een mum van tijd (lees: < een seconde).

[AlterEgo]

Als emerge -s te lang duurt is er een betere actie denkbaar: psyco is een klein mirakel.

Typfouten in /etc/portage/<whatever> kunnen emerge -s ook enorm vertragen (vandaar mijn reactie in dat topique).

[ Voor 14% gewijzigd door AlterEgo op 04-08-2004 20:47 . Reden: edit ]

[Bananenplant]

sorry dat ik misschien even wat onnodig schop... maar zou gentoo een goeie distro zijn voor m'n lapflap? ik draai er nu debian unstable op, maar de beeldopbouw is gewoon ongelofelijk traag, heb al allerlei trucjes uitgehaald met DRI enzo.

het is een toshiba celeron 1GHz met een cyberblade grafische kaart, ik kan me niet voorstellen dat zo'n machine trager moet zijn dan een duron 650 die ik zelf een tijdje terug had. als ik met gentoo het ding wat werkbaarder kan krijgen doe ik het graag, distcc kan .

[Niek]

ucchan schreef op 11 augustus 2004 @ 11:58:
sorry dat ik misschien even wat onnodig schop... maar zou gentoo een goeie distro zijn voor m'n lapflap? ik draai er nu debian unstable op, maar de beeldopbouw is gewoon ongelofelijk traag, heb al allerlei trucjes uitgehaald met DRI enzo.

het is een toshiba celeron 1GHz met een cyberblade grafische kaart, ik kan me niet voorstellen dat zo'n machine trager moet zijn dan een duron 650 die ik zelf een tijdje terug had. als ik met gentoo het ding wat werkbaarder kan krijgen doe ik het graag, distcc kan .

Ik denk dat het iets meer voor dit topic is: Welk OS (bv. Linux distro) moet ik nemen? Part 3

Maar om even op je vraag in te gaan: XFree / XOrg geoptimaliseerd compilen helpt absoluut in je performance, maar verwacht geen wonderen. Je grafische kaart heeft gewoon geen goede support/drivers (als je een nieuwe videokaart wilt: nVidia heeft de beste drivers, die van ATi zijn redelijk en de rest telt eigenlijk niet mee).
Conclusie: je kan het proberen, schelen zal het wel maar zolang die Cyberblade kaartjes niet goed ondersteund zijn zal het nooit echt snel worden.

[BoAC]

ucchan schreef op 11 augustus 2004 @ 11:58:
sorry dat ik misschien even wat onnodig schop... maar zou gentoo een goeie distro zijn voor m'n lapflap? ik draai er nu debian unstable op, maar de beeldopbouw is gewoon ongelofelijk traag, heb al allerlei trucjes uitgehaald met DRI enzo.

het is een toshiba celeron 1GHz met een cyberblade grafische kaart, ik kan me niet voorstellen dat zo'n machine trager moet zijn dan een duron 650 die ik zelf een tijdje terug had. als ik met gentoo het ding wat werkbaarder kan krijgen doe ik het graag, distcc kan .

In de Gentoo Forums is wel het een en ander daarover te vinden. Ligt er wel aan wat voor een type Cyberblade je hebt

[Bananenplant]

code:

0000:01:00.0 VGA compatible controller: Trident Microsystems CyberBlade XPAi1 (rev 82)

ik had zelf al een vluchtige kijk op de gentoo-fora, zal iets beter kijken dan

en sja, als er een andere kaart inkon deed ik het, m'n gkracht in m'n desktop gaat als een trein

ik had ook iets gelezen in deze draad wat er gebeurt bij meer load, bij meer load wordt dit ding nogal traag, ik hoop dat er ook mee te winnen eigenlijk

[ Voor 23% gewijzigd door Bananenplant op 11-08-2004 12:39 ]

[odysseus]

Het wordt misschien nogal beroerd van reclame voorzien, maar Debian kan ook al een eeuwigheid dit soort dingen - al is het nog niet perfect . Stel dat je een speciaal gebouwde OpenOffice wilt hebben, dan draai je gewoon het volgende commando:

code:

DEB_BUILD_OPTIONS="kdeicons lang=nl ccache" apt-get source -b openoffice.org

Helaas zijn er maar weinig opties gestandaardiseerd, dus het vereist wat zoekwerk om de beste switches mee te geven. Als je niet dit soort specifieke dingen nodig hebt maar gewoon wilt optimaliseren voor je processor, dan zijn er tools als pbuilder die dat automatisch voor je doen - gewoon even apt-get install pbuilder draaien, instellen welke compilatieopties er vereist zijn en vervolgens wordt een 'apt-get source -b xfree86' automatisch geoptimaliseerd voor jouw processor .

[Bananenplant]

mja, ik heb apt-build geinstalleerd, maar xfree86 opnieuw bouwen heeft niet echt veel geholpen

naja, ik zal ophouden dit topic verder te vervuilen, ookal zou ik je eeuwig dankbaar zijn als je me kon vertellen hoe ik distcc in dit verhaal bij debian gebruik

[Verwijderd]

Er is een tooltje dat de beste optimalisaties bepaalt voor je architectuur, genaamd Acovea (zoek maar eens op de Gentoo forums, staat het wel in ).

Zo kun je een beetje bepalen wat het beste is (CFLAGS/CXXFLAGS), maar er is wel een nadeel, het duurt langgg

Home van Acovea
Linkje met wat overzichten van vlaggetjes.

[odysseus]

ucchan schreef op 11 augustus 2004 @ 13:55:
naja, ik zal ophouden dit topic verder te vervuilen, ookal zou ik je eeuwig dankbaar zijn als je me kon vertellen hoe ik distcc in dit verhaal bij debian gebruik

Technisch zou de mooiste oplossing zijn om de te gebruiken compiler mee te geven aan apt-get - daar ken ik geen specifieke variabele voor, maar de kans is aanwezig dat het wordt opgepikt als je gewoon de standaardvariabele CC gebruikt. Je krijgt dan iets als 'CC=distcc' voor je normale commando.

Mocht dat niet werken dan kan je het op de vuile manier doen:

code:

mv /usr/bin/gcc /usr/bin/gcc.real ##of een andere naam, als gcc.real al bestaat
touch /usr/bin/gcc

En dan verwijs je in gcc.real naar distcc, waarbij je er wel nog even op moet letten dat je ook alle argumenten netjes doorgeeft. Hoe dat precies moet is wel ergens te vinden in een voorbeeldversie van zo'n doorverwijsscriptje: ik meen dat pbuilder hetzelfde trucje uithaalt, dus misschien dat je het daar kan vinden.

Om distcc te laten werken moet je natuurlijk wel nog wat configureren: IBM heeft daar een duidelijke uitleg over .

[deadinspace]

Verwijderd schreef op 04 augustus 2004 @ 11:32:
Ik heb gezocht op tweakers en met google, maar ik kan nergens vinden hoeveel sneller Gentoo is als bijvoorbeeld Debian. Er staat wel een vergelijking op de Gentoo site van Gentoo en Mandrake, maar dat vind ik niet echt een goede vergelijking omdat dat niet echt onafhankelijk is gedaan door een andere partij.

Ik zou graag willen weten wat jullie bevindingen zijn met Gentoo. Is het echt sneller?
Theoretisch zou ik denken dat het inderdaad sneller moet zijn, maar ik kan nergens echte feiten hierover vinden.

Ik heb gebruikers horen zeggen dat ze andere distro's sneller vonden dan Gentoo (gevoelssnelheid). Ik heb ook een benchmark gezien waarin Gentoo er trager uit kwam dan de twee andere geteste distro's (objectieve snelheid). Van beiden heb ik uiteraard ook tegenovergestelde meningen/resultaten gezien.

Source compilen voor je eigen CPU kan inderdaad iets schelen, maar het is meestal procentenwerk, omdat de instructies voor die ene CPU dan net wat handiger geordend kunnen worden, of er een extra instructie beschikbaar is om 1 cycle van een loop-iteratie af te schaven, dat soort dingen. Baanbrekende verschillen zijn er zelden. Die theorie sluit ook aan bij mijn praktijk-ervaring met optimized compilen met gcc.

Een van de redenen dat Gentoo er in benchmarks slechter van af kan komen is verkeerd gebruik van optimalisaties. -O3 bijvoorbeeld kan trager zijn dan -O2, zeker op moderne CPU's. Mensen die "zomaar wat doen" met die optimalisaties kunnen inderdaad zeer goed eindigen met tragere binaries dan goed gecompilede binary distro's.

Bas! schreef op 04 augustus 2004 @ 11:53:
En on topic. Gentoo heeft een aantal features die wel handig zijn, zoals pre-linking.

Mja, alsof dat een Gentoo-only feature is.

dawuss schreef op 04 augustus 2004 @ 13:23:
Een performance applicatie als mplayer of mencoder, wordt geschreven met het oog op moderne processoren. Instructiesetuitbreidingen als MMX, 3DNow! en SSE worden vanuit de software zelf ondersteund, maar de meeste binary distributies leveren de mplayer binaries zonder deze uitbreidingen, omdat die er vanuit gaan dat het ook op minimale hardware, zoals bijvoorbeeld een 386, moet kunnen draaien. In Gentoo is dit gewoon een USE flag, zodat dit automatisch meegecompileerd wordt.
_{Ja, ik weet dat mplayer met zijn runtime detection een slecht voorbeeld is voor wat ik probeer uit te leggen, maar ik kon zo vlug even geen beter voorbeeld verzinnen}

Er zijn maar weinig programma's die van SIMD instructies gebruik maken, om de eenvoudige reden dat deze door de programmeur zelf in assembly moeten worden ingevoerd (nouja, tegenwoordig heeft gcc er experimentele support voor, maar de performance daarmee is om te huilen). Vaak zit er dan ook detectie-code bij.

Als er geen detectie-code bij zit, dan worden er doorgaans meerdere packages gemaakt voor binary distro's. Één met en één zonder MMX bijvoorbeeld. Minder elegant, dat wel, maar je krijgt je MMX-instructies heus wel.

irondog schreef op 04 augustus 2004 @ 15:51:
USE="-opengl" emerge amercas-army installeerde een niet speelbare server editie. Om dit soort redenen wil je Gentoo, en dan is het echt sneller: ga dit spel maar eens met je browser zoeken en downloaden, laat mij maar wachten!

Ook hier geldt: voor zulk soort dingen worden meestal meerdere packages gemaakt.

The_Surfer schreef op 04 augustus 2004 @ 16:55:
Er hier al wel eens een soortgelijk topic geweest aantal jaar terug, en daar replyde ik dit: The_Surfer in "wie heeft hier gentoo linux en wat vind ..."
Komt nog bij dat met bijvoorbeeld de komst van NPTL of GCC 4.4 het in Gentoo erg makkelijk is over te stappen. Je recompiled even glibc, of je doet (in het geval van een ABI incompatible GCC release) emerge -e world en klaar.

En hoe is dat makkelijker overstappen dan binary distro's? Binary distro's releasen gewoon nieuwe versies danwel losse packages gecompiled met een nieuwe GCC, of met NPTL support.

ucchan schreef op 11 augustus 2004 @ 11:58:
sorry dat ik misschien even wat onnodig schop... maar zou gentoo een goeie distro zijn voor m'n lapflap? ik draai er nu debian unstable op, maar de beeldopbouw is gewoon ongelofelijk traag, heb al allerlei trucjes uitgehaald met DRI enzo.

DRI heeft daar weinig mee te maken

Maar, hoe traag, en op welke manier? Het zou een driver probleem kunnen zijn, en met een brakke driver is het traag in elke distro.

[Verwijderd]

ucchan schreef op 11 augustus 2004 @ 13:55:
mja, ik heb apt-build geinstalleerd, maar xfree86 opnieuw bouwen heeft niet echt veel geholpen

naja, ik zal ophouden dit topic verder te vervuilen, ookal zou ik je eeuwig dankbaar zijn als je me kon vertellen hoe ik distcc in dit verhaal bij debian gebruik

Tja, Google...
Ik heb het niet uitgeprobeerd, maar het leek wel redelijk betrouwbaar :
http://www-106.ibm.com/de...nux/library/l-distcc.html

[Verwijderd]

ucchan schreef op 11 augustus 2004 @ 13:55:
mja, ik heb apt-build geinstalleerd, maar xfree86 opnieuw bouwen heeft niet echt veel geholpen

distcc is voor developers die dezelfde source tree vele keren bouwen. Voor source-building end users heeft het weinig zin.

ucchan schreef op 11 augustus 2004 @ 12:38:

code:

0000:01:00.0 VGA compatible controller: Trident Microsystems CyberBlade XPAi1 (rev 82)

ik had ook iets gelezen in deze draad wat er gebeurt bij meer load, bij meer load wordt dit ding nogal traag, ik hoop dat er ook mee te winnen eigenlijk

Die trident driver zuigt gewoon zwaar. Xv support is bagger instabiel en crasht bij het minste of geringste je systeem, en in vorige X versies was window moving niet eens accelerated. Dat is gewoon funest voor performance, no matter hoe mooi je compiler is. In de laatste X versies is dat ietsje beter, maar het blijft bagger. Daarnaast geen 3D support... Gentoo zal hier niet helpen, vrees ik.

[ Voor 55% gewijzigd door Verwijderd op 12-08-2004 04:45 ]

[silentsnake]

Verwijderd schreef op 12 augustus 2004 @ 04:43:
[...]


distcc is voor developers die dezelfde source tree vele keren bouwen. Voor source-building end users heeft het weinig zin.


[...]


Die trident driver zuigt gewoon zwaar. Xv support is bagger instabiel en crasht bij het minste of geringste je systeem, en in vorige X versies was window moving niet eens accelerated. Dat is gewoon funest voor performance, no matter hoe mooi je compiler is. In de laatste X versies is dat ietsje beter, maar het blijft bagger. Daarnaast geen 3D support... Gentoo zal hier niet helpen, vrees ik.

Maar is dat specefiek iets van XFree86 of heeft Xorg daar ook last van? Of gebruiken ze allebei dezelfde drivers?

[_Squatt_]

Verwijderd schreef op 12 augustus 2004 @ 04:43:
distcc is voor developers die dezelfde source tree vele keren bouwen. Voor source-building end users heeft het weinig zin.

Het scheelt bij mij toch aanzienlijk als ik distcc gebruik om de andere pc's in het netwerk mee te laten helpen. Wellicht in de war met ccache? Dat heeft pas zin als je meerdere malen dezelfde tree bouwt.

Die trident driver zuigt gewoon zwaar.

Weinig aan toe te voegen. Op mijn laptop zit ik er ook mee opgescheept .

silentsnake schreef op 12 augustus 2004 @ 11:31:
Maar is dat specifiek iets van XFree86 of heeft Xorg daar ook last van? Of gebruiken ze allebei dezelfde drivers?

Gebruiken vrijwel dezelfde driver. Ik denk niet dat overstappen naar Xorg spectaculaire verbeteringen zal opleveren.

[Bananenplant]

ik ga toch gentoo eens proberen... goeie flags voor een coppermine celeron worden gewaardeerd natuurlijk, hoewel ik natuurlijk zelf kan zoeken .

is denk ik de enige manier om erachter te komen... ik lees genoeg pagina's van lui die tevreden linux draaien op een vergelijkbare laptop als de mijne, dus er zal vast wel eea te winnen zijn .

(nu nog zoeken naar floppy images )

overigens heb ik idd al zelf m'n xfree opnieuw gebouwd, maar bij debian source trees heb je een Debian/rules file waarin heel veel opties weer overridden worden, dus ik vraag me af in hoeverre dat zinvol is geweest, hopelijk doen ebuilds dat niet

[ Voor 26% gewijzigd door Bananenplant op 12-08-2004 13:16 ]

[Wilke]

Verwijderd schreef op 12 augustus 2004 @ 04:43:
distcc is voor developers die dezelfde source tree vele keren bouwen. Voor source-building end users heeft het weinig zin.

Je bent denk ik in de war met 'ccache'. distcc heeft wel degelijk enorm veel zin voor source-building users.

[psyBSD]

ik heb zelf Gentoo gedraaid, en IMHO werkt het wel stabiel, maar hetzelfde is te zeggen van elke goed-geconfigureerde distro. Een voordeel van Gentoo is dat je niet hoeft te zoeken naar je source-code als je een beetje wilt gaan 'spelen'. doe gewoon emerge -f en je krijgt enkel de sourcecode.

Ik ben nu een beetje aan het spelen met debian en wat ik hiervan zie bevalt me ook wel. alleen staan er wel erg veel trage boot-scripts in . daar moet ik nog even naar kijken.

[Bananenplant]

hmm, wel vervelend dat er geen bootfloppies ipv cd's zijn, ik kan atm niet branden

naja, eens even zoeken, maar het enige wat ik tot nu toe tegengekomen ben zijn problemen die je hebt als je niet vanaf cd kunt booten

[Verwijderd]

Gentoo is naar mijn mening niet geschilkt om ingezet te worden voor bedrijven.
Ik zelf werk het liefst met RHEL en SLES.
Ik heb ook bijna alle andere distro's geprobeerd, Slackware, Debian, Gentoo en FreeBSD.
En toch weer terug naar Red Hat en SUSE, omdat dit commerciele bedrijfskritische verantwoorde distro's zijn.

Ik denk niet dat Linux baat heeft bij de vele distro's en hun eigen eigenschappen.
Misschien hebben sommige distro's wel nut als test om bepaalde nieuwe technieken uit te proberen en later toe te passen in versies als RHEL en SLES.
Fedora is een goed voorbeeld.

[psyBSD]

Verwijderd schreef op 12 augustus 2004 @ 15:08:
Gentoo is naar mijn mening niet geschilkt om ingezet te worden voor bedrijven.
Ik zelf werk het liefst met RHEL en SLES.
Ik heb ook bijna alle andere distro's geprobeerd, Slackware, Debian, Gentoo en FreeBSD.
En toch weer terug naar Red Hat en SUSE, omdat dit commerciele bedrijfskritische verantwoorde distro's zijn.

Ik denk niet dat Linux baat heeft bij de vele distro's en hun eigen eigenschappen.
Misschien hebben sommige distro's wel nut als test om bepaalde nieuwe technieken uit te proberen en later toe te passen in versies als RHEL en SLES.
Fedora is een goed voorbeeld.

Wat betreft je standpunt over SuSE en Red Hat ben ik het met je eens, maar deze twee distros zijn niet enorm geschikt voor developers. De kracht van linux is juist dat je het kunt aanpassen tot het voldoet aan 'jouw' eisen.

Om de slogan van LFS erbij te pakken: 'Your distro, your rules'.

Elke distro heeft zijn eigen(-)aardigheden, het hangt gewoon af van wat de gebruiker verlangt van het systeem.

_{FreeBSD is GEEN linux-distro! (het is een compleet ander OS)}

[Wilke]

Verwijderd schreef op 12 augustus 2004 @ 15:08:
Gentoo is naar mijn mening niet geschilkt om ingezet te worden voor bedrijven.

Op zich ging de draad daar ook helemaal niet over, maar ik ben toch wel benieuwd naar argumentatie?

Ik zelf werk het liefst met RHEL en SLES.

Dat mag, ieder zijn smaak natuurlijk

Ik heb ook bijna alle andere distro's geprobeerd, Slackware, Debian, Gentoo en FreeBSD.
En toch weer terug naar Red Hat en SUSE, omdat dit commerciele bedrijfskritische verantwoorde distro's zijn.

FreeBSD is geen linux distro, maar wordt overigens wel veel gebruikt voor kritische applicaties (bv. als mail of DNS-server, waar je niet blij van wordt als ze plat gaan).

De grote ISP's draaien meestal ook grotendeels op Linux/BSD-varianten, en ik betwijfel ten zeerste of dat in meerderheid de versies zijn die jij noemt. Ik denk namelijk dat ze vooral Slackware, Debian en FreeBSD gebruiken.

Tweakers.net draait trouwens ook volledig op Slackware.


Ik neem aan dat je met 'bedrijfskritisch verantwoord' zoiets bedoelt als 'je kunt er applicaties of services op draaien die onder geen beding plat mogen gaan; en als dat toch gebeurt wil je binnen 4 uur (ofzo) vendor support hebben', right?

Dat is prima, maar als een paar procent van de systemen bij een doorsnee bedrijf in die cagegorie valt is het veel (denk ik). Op alle andere zou je dus sowieso prima 'niet-bedrijfskritisch geschikte' distributies kunnen draaien, lijkt me.


Kortom, volgens mij is het tamelijk loos om in het algemeen te zeggen 'distro X is niet geschikt voor bedrijven'.

[deadinspace]

silentsnake schreef op 12 augustus 2004 @ 11:31:
Maar is dat specefiek iets van XFree86 of heeft Xorg daar ook last van? Of gebruiken ze allebei dezelfde drivers?

Xorg is XFree86.

Of, om precies te zijn, Xorg is een fork van de laatste versie van XFree86 onder de oude XFree86 license (4.3.99nogwat ofzo). Ze zijn dus exact hetzelfde, alleen zal de meeste ontwikkeling vanaf nu plaatsvinden in Xorg, en XFree86 ziet eruit alsof het tot vergetelheid gedoemd is.

ucchan schreef op 12 augustus 2004 @ 13:15:
is denk ik de enige manier om erachter te komen... ik lees genoeg pagina's van lui die tevreden linux draaien op een vergelijkbare laptop als de mijne, dus er zal vast wel eea te winnen zijn .

Gebruik je niet stiekem de vesa driver ipv de trident driver? Dat zou nog erger kunnen zijn nml. Of misschien boek je met de vesa driver juist meer succes.

[Verwijderd]

ucchan schreef op 12 augustus 2004 @ 13:15:
is denk ik de enige manier om erachter te komen... ik lees genoeg pagina's van lui die tevreden linux draaien op een vergelijkbare laptop als de mijne, dus er zal vast wel eea te winnen zijn .

Mjah, post de relevante gedeeltes uit je XF8Config file eens? .

Wilke schreef op 12 augustus 2004 @ 13:19:
Je bent denk ik in de war met 'ccache'. distcc heeft wel degelijk enorm veel zin voor source-building users.

Woeps, te weinig slaap. Excuses voor de verwarring. .

psyBSD schreef op 12 augustus 2004 @ 15:27:
Wat betreft je standpunt over SuSE en Red Hat ben ik het met je eens, maar deze twee distros zijn niet enorm geschikt voor developers.

Valt wel mee... Ieder z'n eigen favo distro, zou ik zeggen.

[ Voor 21% gewijzigd door Verwijderd op 13-08-2004 01:18 ]

[Verwijderd]

Performance is denk ik gewoon hoe snel je programma's opstarten, en uuuh hoe snel games draaien ennuuuuh dat is het wel denk ut.

Neem glxgears bijv., daar kanje wel een beetje mee testen
Red Hat 8 was 1090 frames
Gentoo Linux was 1360 frames dacht ik

Ik had dan ook zelfde drivers gebruikt, zelfde resolutie gedraait. Alleen wel andere kernel (2.4 stock in RH8, 2.6 compileerd voor mezelf in Gentoo), wat de performance wel beinvloed.

Maja ik vind het wel best.

[Bananenplant]

Verwijderd schreef op 13 augustus 2004 @ 01:15:
[...]

Mjah, post de relevante gedeeltes uit je XF8Config file eens? .

code:

Section "Module"
        Load    "GLcore"
        Load    "bitmap"
        Load    "dbe"
        Load    "ddc"
        Load    "dri"
        Load    "extmod"
        Load    "freetype"
        Load    "glx"
        Load    "int10"
        Load    "record"
        Load    "speedo"
        Load    "type1"
        Load    "vbe"
EndSection

[...]

Section "Device"
        Identifier      "Generic Video Card"
        Driver          "trident"
        Option          "ShadowFB"
        Option          "CyberShadow"
        Videoram        16384 # in kilobytes klopt dit idd
EndSection

[...]

Section "DRI"
        Mode    0666
EndSection

verder draait ie 1024x768x24bpp, ik heb er al veel over gezocht en daar m'n settings weggehaald, maar ik heb niemand horen reppen over een onwerkbaar trage machine, ik hoop dus dat gentoo me kan helpen (en met hulp van m'n xp2500+ moet het compileren ook wel te doen zijn )

[deadinspace]

ucchan schreef op 13 augustus 2004 @ 19:57:
Section "Device"
Identifier "Generic Video Card"
Driver "trident"
Option "ShadowFB"
Option "CyberShadow"
Videoram 16384 # in kilobytes klopt dit idd
EndSection

Je kunt proberen die ShadowFB uit te zetten, en evt die CyberShadow ook. Misschien werkt de vesa driver juist beter dan de trident driver (maar misschien ook niet). 16 bpp ipv 24 wil misschien ook helpen.

ik hoop dus dat gentoo me kan helpen

Zelf compilen scheelt echt niet van "onwerkbaar" naar "snel" hoor. Sowieso is het niet normaal als het onwerkbaar is, maar is er iets fout

[Verwijderd]

ucchan schreef op 13 augustus 2004 @ 19:57:

code:

[..]
        Load    "GLcore"
[..]

Dat doet X dus in software, dat wordt nogal traag. Haal dit eens weg?

Dit is de mijne overigens:

code:

Section "Module"
        Load  "dbe"
        Load  "extmod"
        Load  "fbdevhw"
        Load  "glx"
        Load  "record"
        Load  "freetype"
        Load  "type1"
        Load  "dri"
EndSection