# [Performance]Mia Gentoo vs una debian...

## codarin

Ciao a tutti,

per fare un corso Linux ho dovuto installare sul mio notebook una Debian (sarge) e con mio potente stupore e rammarico ho notato che sulla stessa macchina in cui ho la Gentoo (di produzione con cui lavoro) la Debian sembra essere molto più performante... soprattutto per quanto riguarda Gnome/kde... qualcosa di cui mi accorgo al volo proprio lavorando sulle finestre e su file-system (apertura applicazioni, ecc.).

I file system che uso sono assolutamente gli stessi... io ho compilato il tutto con queste flags: 

CFLAGS="-O3 -march=pentium-m -mtune=pentium-m -pipe -ftracer -fomit-frame-pointe

r -ffast-math -momit-leaf-frame-pointer -fforce-addr -fPIC -DPIC -falign-functions=64 -funroll-all-loops -fprefetch-loop-arrays -frename-registers"

LDFLAGS="-Wl,-O1 -Wl,--enable-new-dtags -Wl,--sort-common -s"

Che sia questa "personalizzata" la fonte dei miei casini?

Ciao

----------

## codarin

Tra l'altro e spero di non rispondermi da solo:

Questo è l'output in console del mio X.Org, forse sta male lui dopo l'ultima compilata... non so perchè mi cerca ipv6!

```

_XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6

_XSERVTransOpen: transport open failed for inet6/bellatrixoo.amm.uniud.it:0

_XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6

This is a pre-release version of the The X.Org Foundation X11.

It is not supported in any way.

Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.

Select the "xorg" product for bugs you find in this release.

Before reporting bugs in pre-release versions please check the

latest version in the The X.Org Foundation "monolithic tree" CVS

repository hosted at http://www.freedesktop.org/Software/xorg/

X Window System Version 6.8.1.901 (6.8.2 RC 1)

Release Date: 16 December 2004

X Protocol Version 11, Revision 0, Release 6.8.1.901

Build Operating System: Linux 2.6.10-gentoo-r1 i686 [ELF]

Current Operating System: Linux bellatrixoo.amm.uniud.it 2.6.10-gentoo-r1 #3 Tue Dec 28 19:52:52 Local time zone must be set--see zic manu i686

Build Date: 28 December 2004

        Before reporting problems, check http://wiki.X.Org

        to make sure that you have the latest version.

Module Loader present

Markers: (--) probed, (**) from config file, (==) default setting,

        (++) from command line, (!!) notice, (II) informational,

        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.

(==) Log file: "/var/log/Xorg.0.log", Time: Fri Dec 31 08:25:50 2004

(==) Using config file: "/etc/X11/xorg.conf"

Using vt 7

Could not init font path element /usr/share/fonts/local, removing from list!

Could not init font path element /usr/share/fonts/CID, removing from list!

Could not init font path element /usr/share/fonts/Speedo, removing from list!

Could not init font path element /usr/share/fonts/default, removing from list!

Could not init font path element /usr/share/fonts/ghostscript, removing from list!

xset:  bad font path element (#73), possible causes are:

    Directory does not exist or has wrong permissions

    Directory missing fonts.dir

    Incorrect font server address or syntax

startkde: Starting up...

QPixmap: Cannot create a QPixmap when no GUI is being used

QPixmap: Cannot create a QPixmap when no GUI is being used

QPixmap: Cannot create a QPixmap when no GUI is being used

QPixmap: Cannot create a QPixmap when no GUI is being used

kbuildsycoca running...

KWrited - Listening on Device /dev/pts/1

SetClientVersion: 0 8

>> running as realtime process now (priority 50)

ALSA lib pcm_hw.c:563:(snd_pcm_hw_start) SNDRV_PCM_IOCTL_START failed: Broken pipe

ALSA lib pcm_hw.c:563:(snd_pcm_hw_start) SNDRV_PCM_IOCTL_START failed: Broken pipe

ALSA lib pcm_hw.c:563:(snd_pcm_hw_start) SNDRV_PCM_IOCTL_START failed: Broken pipe

kdecore (KAction): WARNING: KAction::insertKAccel( kaccel = 0x81d6d00 ): KAccel object already contains an action name "del"

X Error: BadValue (integer parameter out of range for operation) 2

  Major opcode:  102

  Minor opcode:  0

  Resource id:  0x0

QPixmap: Cannot create a QPixmap when no GUI is being used

QPixmap: Cannot create a QPixmap when no GUI is being used

```

Ciao

----------

## fedeliallalinea

Beh le tue cflags sono molto aggressive dovresti provare con qualcosa di piu' generico

----------

## codarin

Ciao,

cosa piazzeresti di "più generico"?

Io ero dubbioso su:

```

-funroll-all-loops

-fprefetch-loop-arrays

```

....

----------

## fedeliallalinea

Questo e' quello che ho io

```
CFLAGS="-O2 -march=i686 -pipe -fomit-frame-pointer"
```

----------

## Dece

@codarin

Hai usato acovea per settare le cflag? forse è qualche flag di -O3 che rallenta, prova ad utilizzare -O2: io utilizzo -O1 più altre flag, dato che alcune in -O2 avevano dato un punteggio basso nel benchmark... 

Inoltre prova a togliere ffast-math, avevo letto che era una flag da non usare perchè da sicuri problemi: infatti mi sembra che l'errore di X sia un'errore di calcolo e non ipv6:

```
X Error: BadValue (integer parameter out of range for operation) 2 
```

Ciao

----------

## =DvD=

Io uso gentoo perchè mi torna molto portage, mi tornano le use flags, mi torna come sono organizzati gli script di init; *non* per le ottimizzazzioni -O435434 che a mio avviso sui processori di oggi sono inutili o deleteri ( e questo post lo conferma).

Ho le cflags come fedeli, ma avendo un solo pc con gentoo uso atholon-xp invece di i686  :Smile: 

----------

## Cazzantonio

Anche io dopo tanti smanettamenti sono arrivato alla conclusione che queste

```
CFLAGS="-O2 -march=athlon-xp -mmmx -msse -m3dnow -fomit-frame-pointer -pipe -frename-registers"
```

 sono più che sufficienti.

In più di fedeli uso solo march=miaarichitettura (più le flag per le estensioni varie che non ho mai capito se siano comprese o meno nel "march")

In futuro penso che passerò comunque a compilare tutto con 

```
-O2 march=i686 -mmmx -msse -m3dnow -fomit-frame-pointer -pipe -frename-registers 
```

Comunque è vero che talvolta i binari precompilati sono molto più veloci (un esempio è openoffice-bin vs openoffice) anche senza andare a cercare distribuzioni diverse

Non so come questo accada... magari utilizzano compilatori diversi dal gcc e magari più ottimizzati; c'è chi dice che il compilatore intel sia più veloice del 30% rispetto al gcc....

----------

## codadilupo

non vorrei dire castronerie, ma il fatto che la debian sia da sempre compilata per i386 credo la renda anch particolarmente snella...

Coda

----------

## randomaze

 *Cazzantonio wrote:*   

> Comunque è vero che talvolta i binari precompilati sono molto più veloci (un esempio è openoffice-bin vs openoffice) anche senza andare a cercare distribuzioni diverse

 

Il punto é che talvolta le orrimizzazioni ottimizzano, altre invece peggiorano qualcosa. 

Un binario compilato con O3 é piú grosso e cimpiega piú tempo a caricare di uno compilato con Os. Ma dovrebbe essere piú veloce dopo...

In realtá non c'é una formula universale per le CFLAGS che soddisfi qualsiasi esigenza  :Wink: 

 *Quote:*   

> Non so come questo accada... magari utilizzano compilatori diversi dal gcc e magari più ottimizzati; c'è chi dice che il compilatore intel sia più veloice del 30% rispetto al gcc....

 

Il compilatore Intel é closed.... credo che se vai da un debianista a chiedergli se usa ICC per la distro "una risata ti seppellirá"  :Rolling Eyes: 

 *codadilupo wrote:*   

> non vorrei dire castronerie, ma il fatto che la debian sia da sempre compilata per i386 credo la renda anch particolarmente snella... 

 

...espandi il tuo pensiero perché non ho capito cosa vuoi dire.

----------

## Dece

@=DvD=

Anche io ho sempre usato le flag come fedeli, e tuttora le uso sul portatile: ho fatto un "esperimento" sul pc fisso giusto per curiosità: in fondo gentoo va già veloce di suo, anche facendo le ottimizzazioni giuste si guadagna poco...  :Rolling Eyes:  si fa solo per il gusto di smanettare un po e vedere se il tutto funziona  :Wink: 

@codadilupo

si probabilmente è più snella, ma comunque le prestazioni dovrebbero maggiori con gentoo, perchè la compilazione è ottimizzata: è sufficiente usare un po kde prima su gentoo e poi su debian, la differenza si vede   :Smile: 

----------

## kandalf

io vido la sincerà verità...come prestazione debian a me è sempre andata meglio di gentoo...xo' come funzionamento generale uso gentoo xchè nn dà nessun problema in qualsiasi situazione, con emerge trovo tutti i programmi immaginabili...diciamo che la uso per la solidità...nn mi tradisce mai

----------

## codadilupo

 *randomaze wrote:*   

> Il compilatore Intel é closed.... credo che se vai da un debianista a chiedergli se usa ICC per la distro "una risata ti seppellirá" 

 

risata é un grosso armadio a due ante, debianista, e campione pesi massimi, ovviamente   :Rolling Eyes: 

 *randomaze wrote:*   

>  *codadilupo wrote:*   non vorrei dire castronerie, ma il fatto che la debian sia da sempre compilata per i386 credo la renda anch particolarmente snella...  
> 
> ...espandi il tuo pensiero perché non ho capito cosa vuoi dire.

 

intendo dire che, siccome debian ha la pretesa di essere utilizzata su macchine ultra-datate (386, per l'appunto), in teoria é molto prestante su macchine recenti, tipo 686. Ma é solo una supposizione: é ovvio, poi, che incide molto di piu' una cattiva compilazione, sulla lentezza di gentoo, che non una alta retro-compatibilità sulla velocità di debian  :Wink: 

Coda

----------

## randomaze

 *codadilupo wrote:*   

> intendo dire che, siccome debian ha la pretesa di essere utilizzata su macchine ultra-datate (386, per l'appunto), in teoria é molto prestante su macchine recenti, tipo 686. Ma é solo una supposizione: é ovvio, poi, che incide molto di piu' una cattiva compilazione, sulla lentezza di gentoo, che non una alta retro-compatibilità sulla velocità di debian 

 

IMHO la vera variabile é la piú o meno corretta configurazione e la versione delle applicazioni.

----------

## =DvD=

[possibili sciocchezze]Penso anche che se un programma (grande) è scritto per essere compilato per i386, compilandolo per i686 puo essere che abbia delle perdite di prestazioni.

Se le maggiori distro compilano per i386 forse qualcuno la fuori scrive codice pensando che sarà compilato a questo modo![/possibili sciocchezze]

Cmq ho avuto la stessa impressione con una slak... pareva schizzare kde rispetto al mio...   :Rolling Eyes: 

----------

## silverhand

Punto uno del mio pensiero da semi-niubbo: Se del codice viene ottimizzato per i386 è naturale che sia in alcuni casi più lento di uno per i868 perchè:

Prendiamo un esempio: Con l'evoluzione dei tempi nei processori si introducono nuove funzioni quindi:

nell'i386 possiamo supporre che non ci sia stata la funzione che calcola la radice quadrata, e se ci capita una richiesta del genere il processore la faceva con la tecnica delle divisioni successive impiegando quindi un fattore 20 in + rispetto ad un i686 che ha la funzione innata e la calcola al volo.

Problema delle ottimizzazioni, tirando le ottimizzazioni si crea codice più lungo che "può" occupare più page di memoria, questo significa che devo fare la somma tra due numeri e i due dati sono su page memory differenti da quella dell'istruzione mi becco 3 pagefault con relativi tempi di accesso alla memoria per il cambio di pagina, risultato:

A volte del codice i386 (che magari stà tutto in una pagina) è più veloce del codice i686 (che però è più veloce).

Dipende tutto dalle situazioni

----------

## stuart

scusate, ma da un programma binario non c'è proprio modo di sapere con che ottimizzazioni è stato compilato?

anche a me alcuni programmi tipo firefox quando ho fatto il confronto il binario scheggiava più del compilato

----------

## silian87

 *Quote:*   

> scusate, ma da un programma binario non c'è proprio modo di sapere con che ottimizzazioni è stato compilato?
> 
> anche a me alcuni programmi tipo firefox quando ho fatto il confronto il binario scheggiava più del compilato

 

mi sembra che se ne era prlato, ma non ricordo esattamente dove   :Confused: 

----------

## =DvD=

Mumble... forse il codice più ottimizzato è quello più piccolo come eseguibile alla fine... devo fare un po' di prove...

----------

## Sasdo

beh io ho passato giorni interi a ricompilare il firefox (l'ho usato come benchmark   :Wink:  ) e alla fine ho tirato fuori questo:

```

CFLAGS="-s -O2 -mtune=i686 -pipe -ffast-math -fforce-addr -fomit-frame-pointer -fno-cprop-registers -finline-functions -funsafe-math-optimizations -ffinite-math-only"

CHOST="i686-pc-linux-gnu"

CXXFLAGS="${CFLAGS}"

LDFLAGS="-Wl,-O1"

```

con Gcc 3.4

e ottengo le medesime prestazioni del precompilato.

----------

## randomaze

 *=DvD= wrote:*   

> [possibili sciocchezze]Penso anche che se un programma (grande) è scritto per essere compilato per i386, compilandolo per i686 puo essere che abbia delle perdite di prestazioni.
> 
> Se le maggiori distro compilano per i386 forse qualcuno la fuori scrive codice pensando che sarà compilato a questo modo![/possibili sciocchezze]

 

Direi che quel possibili nelle parentesi quadre lo puoi eliminare.

Il programma é scritto per essere compilato. Punto.

Le ottimizzazioni, a livello di codice macchina, le fa il compilatore, sistemando le varie sequenze di operazioni in maniera piú vantaggiosa.

É sempre il compilatore che decide che un addizione bisogna farla usando un istruzione sse, piuttosto che mmx o 3dnow. O usando il solito 387

E nel caso il compilatore posizioni le istruzioni "a caso" ottenendo frequenti page fault, tale compilatore é bacato o mal funzionante.

Poi anche i processori hanno funzioni studiate per velocizzare l'esecuzione ma questa é un'altra storia....

Questo tranne (ormai) rarissimi casi in cui il programmatore certosino fa un fine tuning del tutto sporcandosi le mani con l'assembler.

----------

## =DvD=

 *randomaze wrote:*   

> Questo tranne (ormai) rarissimi casi in cui il programmatore certosino fa un fine tuning del tutto sporcandosi le mani con l'assembler.

 

Quando ho detto programmi grandi mi riferivo a questo: Una funziona che viene chiamata Spessissimo ci sta che la faccia in asm qualcuno (vedi i motori grafici  :Wink:  )

----------

## akiross

Solitamente le applicazioni grafiche vengono fatte con delle basi di basso livello adattate ad ogni piattaforma: quindi avremmo codice assembly per ogni architettura che sfrutta le migliori opzioni per ognuna.

In ogni caso a me sembra logico che se un programma e' compilato per i686 su un i686 sara' piu' performante di un i386 su un i686. E' ovvio: se e' compilato per l'architettura i686 sfruttera' le opzioni _milgiori_ che i686 offre e i386 no. Insomma, se non fosse cosi' perche' dovrebbe esistere gentoo?

E comunque non mi farei troppe menate sulle flag come qui si e' fatto: la velocita' di esecuzione e' determinata da molti fattori che neanche si pensano.

Esempio: debian usava il preloader? A volte non ci si pensa, ma se una distro lo auto-include non ci sono cavoli, sara' piu' veloce con kde.

Anche ammettendo che non ci fosse preloader, debian e' piu' veloce in tutto? DMA e' attivo? La memoria disponibile in debian e' la stessa disponibile in gentoo (intendo: quando lanci gentoo se ci sono 10 demoni aperti e in debian ce ne' 1... ho capito che e' la stessa macchina, ma non e' la stessa distro)? E il kernel? Com'e' compilato quello di debian? E quello di gentoo?

In ogni caso:

-O3 -> Alcune architetture hanno problemi... consiglio -O2 nel dubbio

-ffast-math ->  :Very Happy:  LoL La libreria fastmath va usata solo per la grafica!

-fPIC -> Program Indipendent Code produce codice "lento"...

Le altre flag non le conosco tutte/bene quindi mi astengo... in ogni caso spero che tu abbia letto bene il man gcc prima di metterle, e spero ci sia un motivo valido per farlo (visto che qualcuna e' davvero da suicidio)  :Smile: 

Ciao!

----------

## n3m0

 *codarin wrote:*   

> Io ero dubbioso su:
> 
> ```
> 
> -funroll-all-loops
> ...

 

Dubbioso? Sono da evitare come la peste  :Very Happy: 

Più di tutte -funroll-all-loops. Già srotolare i loop ingrossa l'eseguibile, ma srotolarli tutti (anche quelli di lunghezza non predeterminabile) è un suicidio.

----------

## akiross

Quelli di lunghezza non determinabile non vengono srotolati. Come si potrebbe farlo?

----------

## n3m0

 *akiross wrote:*   

> Quelli di lunghezza non determinabile non vengono srotolati. Come si potrebbe farlo?

 

Ho usato un'espressione troppo forte: "non determinabile".

Mentre andava scritto: "non determinabile in modo certo".

Ma le cose non cambiano di molto.

 *man gcc wrote:*   

> -funroll-all-loops
> 
> Unroll all loops, even if their number of iterations is uncertain when the loop is entered. This usually makes programs run more slowly.

 

 *man gcc unofficial-ita wrote:*   

> -funroll-all-loops
> 
> Srotola tutti i cicli, anche quelli il cui numero di iterazioni è incerto quando si entra nel ciclo. Questo di solito causa un esecuzione più lenta dei programmi.

 

----------

## akiross

 :Shocked:  Come esecuzione piu' lenta?? Arrghhh io ero convinto che fosse lento in compilazione ma veloce in esecuzione (secondo logica questo mi sembra gisusto!)

Arghhh!

----------

## n3m0

 *akiross wrote:*   

>  Come esecuzione piu' lenta?? Arrghhh io ero convinto che fosse lento in compilazione ma veloce in esecuzione (secondo logica questo mi sembra gisusto!)Arghhh!

 

Allora.

Lo srotolamento dei loop in teoria apporta dei benefici all'esecuzione dei programmi perchè non si effettuano più i test e gli inc(dec)rementi tipici dei loop.

Questo pero' vale per i loop di cui si può determinare il numero di iterazioni.

Per i loop di cui non si può determinare il numero di iterazioni con esattezza, anche teoricamente il loop unrolling non giova.

Quanto appena detto implicherebbe allora che: 

-funroll-loops possa essere tranquillamente usata

-funroll-all-loops invece non debba essere usata

A questo punto pero' ci tocca fare il passaggio dalla teoria alla pratica.

Nella pratica il loop unrolling ingrandisce la dimensione dell'eseguibile, con conseguente allungamento dei tempi di caricamento dello stesso.

Resta il fatto che potrebbe essere più performanente in esecuzione.

A questo punto bisogna valutare quanto è il guadagno prestazionale rispetto alla perdita sui tempi di loading.

Nella maggior parte dei casi, col software che usiamo abituamelmente (che non sono di solito applicazioni di calcolo massivo messe lì a girare per un bel po' di tempo, ma, anzi, sono applicazioni interattive), il gioco non vale la candela, quindi anche -funroll-loops andrebbe evitata.

Come anche man gcc dice: 

 *man gcc about -funroll-loops wrote:*   

> This option makes code larger, and may or may not make it run faster.

 

----------

## akiross

Umm no in effetti nelle CFLAG ho -unroll-loops, di spicco credo che ci sia -mmmx, -fmove-all-movables (che secondo me e' utile: toglie il codice che non cambia dai loops, cosi' da evitare ripetizioni inutili) e -finline-functions che come si sa le funzioni inline sono piu' efficienti

Ciauz

----------

## n3m0

 *akiross wrote:*   

> Umm no in effetti nelle CFLAG ho -unroll-loops, di spicco credo che ci sia -mmmx, -fmove-all-movables (che secondo me e' utile: toglie il codice che non cambia dai loops, cosi' da evitare ripetizioni inutili) e -finline-functions che come si sa le funzioni inline sono piu' efficienti

 

fmove-all-movables ce l'ho anche io. E' intelligente e non ingrossa il codice.

Su -finline-functions hai ragione, ma e' sempre teoria.

[IMHO]

Flag come -finline-functions e come anche quella di loop-unrolling basilare non danno abbastanza beneficio rispetto al fatto che ingrossano il codice.

Ne darebbero su applicazioni batch di calcolo, non su applicazioni interattive di uso quotidiano.

[/IMHO]

----------

## wildancer

 *silverhand wrote:*   

> Punto uno del mio pensiero da semi-niubbo: Se del codice viene ottimizzato per i386 è naturale che sia in alcuni casi più lento di uno per i868 perchè:
> 
> Prendiamo un esempio: Con l'evoluzione dei tempi nei processori si introducono nuove funzioni quindi:
> 
> nell'i386 possiamo supporre che non ci sia stata la funzione che calcola la radice quadrata, e se ci capita una richiesta del genere il processore la faceva con la tecnica delle divisioni successive impiegando quindi un fattore 20 in + rispetto ad un i686 che ha la funzione innata e la calcola al volo.
> ...

 

Concordo.... Alla fine ragazzi come importanza la la grandezza di un eseguibile e la sua ottimizzazione sono paragonabili, ma proviamo a far girare bin i386 e i686 su un p4 con 1 giga di ram... a quel punto forse la grandezza dell'eseguibile diventa trascurabile... Uno dovrebbe tenere presente molto i requisiti di sistema! ovviamente imho... sono solo un povero chimico!   :Embarassed: 

----------

## X-Drum

 *=DvD= wrote:*   

> Io uso gentoo perchè mi torna molto portage, mi tornano le use flags, mi torna come sono organizzati gli script di init; *non* per le ottimizzazzioni -O435434 che a mio avviso sui processori di oggi sono inutili o deleteri ( e questo post lo conferma).
> 
> Ho le cflags come fedeli, ma avendo un solo pc con gentoo uso atholon-xp invece di i686 

 

quoto in pieno, la uso per portage e quanto scritto sopra, l'ottimizzazione estrema e/o eccessiva nn mi interessa...anche perche' spesso è emerso che non da i risultati sperati...

----------

## tomasino

correggetemi se sbaglio, ma mi pare che l'efficienza del -funroll-loops dipenda dall'efficienza della branch prediction: se la branch prediction c'azzecca, lo strotolamento del loop è codice inutile, in caso contrario mi evito uno svuotamento della pipeline. Ho letto da più fonti che attualmente i proc vantano ottime branch prediction(per fortuna  :Smile: ) -> unroll-loops spesso evitabile

----------

## tomasino

Per quel che riguarda l'ottimizzazione del codice di alto livello: ha senso parlarne solo di fronte ad architetture molto differenti(ix86 vs PPC, non i686 vs athlon), e si tratta cmq di ottimizzazioni minime. Per poter fare di queste ottimizzazioni devi cmq conoscere l'architettura e il comportamento del compilatore.

Caso a parte è l'unità altivec: per poterla sfruttare è necessario spesso ricorrere proprio ad algoritmi diversi (un gran casino  :Sad: , guardate i 10 semplici passi per vettorizzare il codice http://penguinppc.org/dev/#altivec)

----------

## Apetrini

NOn capisco perche tutti si lamentano delle prestazioni della gentoo compilata, io ho notato che è la piu veloce in assoluto e non ho neanche flag spinte:

"-O2 -march=pentium-m -fomit-frame-pointer". è piu veloce di slackware sicuramente, ma anche di distro come yoper(il target di questa distro è avere piu performance possibili, mi pare che di default usa reiser4, anche se è gia precompilata)...per non parlare di Debian che reputo infinitamente lenta.

Poi se la gente crede di compilare tutto il sistema e da qui avere il top delle performance si sbaglia, entrano in gioco un sacco di fattori quali: il tuning del kernel, filesystem, tuning degli Hard-disk, DMA, scheduling e per non parlare delle varie librerie che magari vengono richiamate dai singoli programmi al momento d'esecuzione, poi dipende anche che tipo di librerie si usano, se si usa prelink kde sarà velocissimo all'avvio, se usiamo NPTL avremo ancora piu performance etc...

In sostanza credo che gentoo sia la distro piu performante, ovviamente non essendo come "le altre" tutte queste belle cose non sono attivate di default, uno si deve arrangiare e fare alune scelte da solo. Quindi è inutile confrontare una distribuzione che di default usa certi "hacks" (permettetemi il termine), se poi in gentoo non li attiviamo. Amo gentoo perche mi da la piu completa libertà di scelta, da qui per forza deve essere la piu performante se no ho sbagliato nel fare alcune scelte. Quello che voglio dire è che gentoo è "LIBERTA' DI SCELTA", da qui al massimo posso dire che gentoo potrà essere "uguale" alle altre come performance, ma mai inferiore!! Se uno adotta TUTTI i stratagemmi(ricordate la libertà di scelta) che sono stati effettuati nell'altra ditro , avrà al meno un sistema che "corre" come l'altra distro.

----------

## ---willy---

quoto in pieno Apetrini.

io sul mio fisso avevo (m'è scoppiato l'alimentatore e ho perso l'hd!  :Crying or Very sad:  ) slackware e gentoo. appena installata la gentoo, vado tutto contento a farla partire, ma dopo poco m'accorgo subito che era visibilmente (molto) più lenta della slack. rimango così:  :Shocked:  ....poi dopo un po' di giochini con le CFLAGS (tutti tesi a semplificarle anzichè complicarle), mi ritrovo più o meno con le stesse prestazioni. sono sicuro che se c'era Patrick Volkdering al posto mio, il mio computer prendeva il volo!!  :Very Happy: 

----------

## =DvD=

Arch linux a me va più veloce di gentoo.

uso -O2 e la solita roba classica.

----------

## Kernel78

 *Apetrini wrote:*   

> Poi se la gente crede di compilare tutto il sistema e da qui avere il top delle performance si sbaglia, entrano in gioco un sacco di fattori quali: il tuning del kernel, filesystem, tuning degli Hard-disk, DMA, scheduling e per non parlare delle varie librerie che magari vengono richiamate dai singoli programmi al momento d'esecuzione, poi dipende anche che tipo di librerie si usano, se si usa prelink kde sarà velocissimo all'avvio, se usiamo NPTL avremo ancora piu performance etc... 

 

Oltre a questo la gente che riscontra la maggior lentezza è composta da quelli che pensano che dando un'occhiata alle opzioni di ottimizzazioni si possa capire al volo quali facciano "volare" gentoo e non si rendono conto che bisognerebbe studiare l'architettura della propria macchina, il funzionamento del compilatore e aver chiaro il funzionamento dei programmi che usano.

IMHO una -O3 è più utile, per esempio, per blender e per chi lo lascia in rendering per giorni ma se uno usa l'ambiente grafico e il browser (magari aprendoli e chiudendoli più volte al giorno) noterà solo la lentezza nel caricamento (a meno che magari abbia usato prelink).

----------

## kaosone

...probabilmente per il prelink.... mi pare che su debian sia automatico..

----------

## Apetrini

 *kaosone wrote:*   

> ...probabilmente per il prelink.... mi pare che su debian sia automatico..

 

Ecco ... risolta la "magia" della velocità...

----------

## pistodj

scusate la mia ignoranza ma cos'è il prelink? si può attivare anche in gentoo??

----------

## gutter

 *pistodj wrote:*   

> scusate la mia ignoranza ma cos'è il prelink? si può attivare anche in gentoo??

 

Una buona guida la trovi qui.

----------

## Kernel78

 *gutter wrote:*   

>  *pistodj wrote:*   scusate la mia ignoranza ma cos'è il prelink? si può attivare anche in gentoo?? 
> 
> Una buona guida la trovi qui.

 

Oppure qui in italiano

----------

## thewally

 *codadilupo wrote:*   

> non vorrei dire castronerie, ma il fatto che la debian sia da sempre compilata per i386 credo la renda anch particolarmente snella...

 

Confido nella tua esperienza... Ma... mi e' capitato di installare anche sarge  :Rolling Eyes:   (oltre all'attuale gentoo:D ) sul mio portatile (ASUS D1 512Mb RAM, Pentium4 2,4 GHz), ed ho potuto notare che e' notevolmente lenta.  :Evil or Very Mad: 

Stesso risultato l'ho ottenuto su Celeron 1,7 GHz 384 MB RAM.

IMHO Debian e' lentissima....

----------

## thewally

 *codarin wrote:*   

> 
> 
> CFLAGS="-O3 -march=pentium-m -mtune=pentium-m -pipe -ftracer -fomit-frame-pointe
> 
> r -ffast-math -momit-leaf-frame-pointer -fforce-addr -fPIC -DPIC -falign-functions=64 -funroll-all-loops -fprefetch-loop-arrays -frename-registers"
> ...

 

Ci hai dato pesantino eh ?!  :Laughing: 

Presupposto questo:

```

wally@nemo ~ $ cat /proc/cpuinfo 

processor       : 0

vendor_id       : GenuineIntel

cpu family      : 15

model           : 2

model name      : Intel(R) Pentium(R) 4 CPU 2.40GHz

stepping        : 7

cpu MHz         : 2400.285

cache size      : 512 KB

fdiv_bug        : no

hlt_bug         : no

f00f_bug        : no

coma_bug        : no

fpu             : yes

fpu_exception   : yes

cpuid level     : 2

wp              : yes

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid

bogomips        : 4751.36

```

Ti faccio dare un'occhiata alle mie:

```

wally@nemo ~ $ cat /etc/make.conf|grep FLAGS

CFLAGS="-march=pentium4 -O2 -pipe -fomit-frame-pointer -fstrength-reduce -fthread-jumps -floop-optimize" 

CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"

```

E gia' molti considererebbero le mie eccessive...  :Laughing: 

Per ora non ho avuto alcun problema, gira tutto molto fluido...

----------

## comio

posso dare un mio parere? 

secondo me bisogna sempre mettere sul piatto le cflags che si hanno e l'applicazione che si vuol compilare. Per esempio, se l'applicazione nel 90% del tempo non fa nulla... allora è molto meglio compilarla con -Os. Contrariamente una applicazione che porta il processore a palla per molto tempo conviene compilarla con -O3 (per esempio, ma immaginate tante flags esotiche).

Quindi, il concetto è questo: su gentoo si tende a mettere delle conf. di compilazioni uguali per tutti i programmi, mentre nelle distro precompilate, sono i singoli manteiner dei pacchetti a scegliere le opzioni più idonee (che comunque normalmente sono le più comuni).

Questo è il mio modesto e comunque umano parere.

ciao

----------

## jesus_was_rasta

 *comio wrote:*   

> 
> 
> ...
> 
> Quindi, il concetto è questo: su gentoo si tende a mettere delle conf. di compilazioni uguali per tutti i programmi, mentre nelle distro precompilate, sono i singoli manteiner dei pacchetti a scegliere le opzioni più idonee (che comunque normalmente sono le più comuni).
> ...

 

Ecco finalmente chi ha saputo dare una risposta intelligente (e definitiva, IMO) a questa annosa questione.  :Idea: 

Quoto al 1000%.  :Very Happy: 

Non può che essere così, non vi pare?

Il manteiner del pacchetto conoscerà come le sue tasche il funzionamento dello stesso, e quindi tenderà a compilarlo con le flags che più esalteranno la bontà del codice. 

Pretendere di trovare flags generiche che vadano bene per tutti i programmi è utopia...

Io personalmente ho installato in questo ultimo periodo 3 macchine; tutte Gentoo, e tutte "tirate su" col CD del progetto Jackass!

E ne sono pienamente soddisfatto!  :Very Happy: 

Consiglio a chi volesse reinstallare una Gentoo da capo di seguire il loro metodo, tanto per provare.

A me ha soddisfatto sia come velocità di installazione che come performance finali.

Un ultima cosa: molta importanza hanno anche le flag use: inutile rincorrere le ottimizzazione delle cflags quando si hanno 70-80 use flags...

Infine voglio associarmi con coloro che amano Gentoo non per le ottimizzazioni tanto "pubblicizzate", ma per la flessibilità di Portage, per la comunità che la circonda, per la natura didattica della manutenzione e per quel quid di follia che ci fa passare ore a compilare...  :Laughing: 

Ciao!  :Cool: 

@comio

[OT]Viva la Raffo![/OT]

Io sono di Lucera, quanta ne ho bevuta!  :Laughing: 

----------

## Apetrini

A proposito delle USE volevo chiedere un consiglio.

Di solito io per fare l'emerge dei pacchetti uso porthole e lo faccio solo perche mi permette di selezionare al volo molte USE senza dover scrivere lunghissime righe sulla shell. Ma perche non mettere gia tutte le use in make.conf vi chiederete voi! Be perche alcune USE le voglio solo su certi programmi 

e su altri no.

Quindi di solito faccio che ogni volta che faccio l'emerge di un pacchetto mi seleziono le USE che voglio per quel pacchetto di volta in volta. Metto nel file make.conf solo quelle piu generiche (infatti avrò ora come ora circa 15 USE).

Secondo voi questo è un uso improprio del portage e può portare a situazioni anomali? se si quali...

Grazie.

----------

## jesus_was_rasta

 *Quote:*   

> 
> 
> Secondo voi questo è un uso improprio del portage e può portare a situazioni anomali? se si quali...
> 
> 

 

No, credo anzi che il tuo modo di fare sia quello più idoneo alla filosofia delle USE.

Il consiglio sarebbe però quello di elencare tutti i tuoi pacchetti "personalizzati" in /etc/portage/packege.use, con le loro specifiche flag.

Questo file esiste apposta!

Inoltre credo che Porthole (correggimi se sbaglio) produca dei comandi tipo USE="pinco pallino -togigio" emerge -vp cartonianimati.

Questo è un modo di fare valido ma deprecato, visto che poi al prossimo emerge dovresti di nuovo specificare le flag.

Ciao!  :Very Happy: 

----------

## thewally

 *jesus_was_rasta wrote:*   

> [
> 
> Inoltre credo che Porthole (correggimi se sbaglio) produca dei comandi tipo USE="pinco pallino -togigio" emerge -vp cartonianimati.
> 
> 

 

Togigio ?! Pinco pallino ?!.... Altro che quid di follia  :Laughing: 

----------

## Mr.Evolution

 *codadilupo wrote:*   

> non vorrei dire castronerie, ma il fatto che la debian sia da sempre compilata per i386 credo la renda anch particolarmente snella..
> 
> Coda

 

Debian è compilata per 486 da Sarge

Il supporto a 386 è stato tolto da questa release.

----------

## jesus_was_rasta

[OT]

 *thewally wrote:*   

>  *jesus_was_rasta wrote:*   [
> 
> Inoltre credo che Porthole (correggimi se sbaglio) produca dei comandi tipo USE="pinco pallino -togigio" emerge -vp cartonianimati.
> 
>  
> ...

 

Quel togigio doveva essere topogigio...  :Laughing: 

Dici che non calzava l'esempio?  :Razz: 

[/OT]

----------

## thewally

 *Mr.Evolution wrote:*   

>  *codadilupo wrote:*   non vorrei dire castronerie, ma il fatto che la debian sia da sempre compilata per i386 credo la renda anch particolarmente snella..
> 
> Coda 
> 
> Debian è compilata per 486 da Sarge
> ...

 

Allora posso aspettarmi prestazioni da Slackware ?

----------

