# -Os: la soluzione (ignorata) a tanti mali?

## =DvD=

HO cercato -Os e non ho trovato niente, quindi apro questo tread:

Mi stavo lamentando mentalmente del fatto che per aprire firefox ci metto troppo, e pensa e ripensa ho notato che tutto il tempo che perde sento l'hd che macina e rimacina, quindi se l'eseguibile fosse piu piccolo avrei i seguenti vantaggi:

-I programmi fanno prima a partire

-La ram non mi si riempie subito (ho solo 256 Mb)

A fronte di quale svantaggio? Uso sostanzialmente il pc per navigare, non è che serva una ottimizazione estrema, serve invece che i programmi partano appena gli dico di farlo, e non 5 secondi dopo.

Uso ext3... che sia anch'esso la causa di tale lentezza?

A proposito di lentezza https://forums.gentoo.org/viewtopic-p-2193174.html#2193174 queste le ho fatte tutte come ho scritto li, ma non è cambiato molto.

----------

## .:deadhead:.

L'idea file piccolo, meno giri per l'hd per leggerselo unita ad un filesystem veloce con i file piccoli, potrebbe dare ottimi risultati.

Cmq siccome i vari -O1 2 3 s non sono formule tecnosciamaniche ma semplici "meta flags" che raggruppano diverse ottimizazioni. Invito pertanto a dare un occhio a http://gcc.gnu.org/onlinedocs/gcc-3.3.5/gcc/Optimize-Options.html#Optimize-Options [per il compilatore 3.3.5] così da avere un'idea precisa del cosa fanno le varie opzioni che inseriamo in /etc/make.conf

Spesso la corsa all'ultima opzione di ottimizazione rompe tutto o crea eseguibili ottimizzati solo per alcuni casi specifici.

Io con 

```
CFLAGS="-Os -march=pentium4 -pipe -ffast-math -fforce-addr"
```

 finora mi son sempre trovato d'un bene...

----------

## =DvD=

Allora anche te stai con -Os?!

Per quanto riguarda i vari -Ox mi sono letto il man, ovviamente, per sapere che fanno!

----------

## Panda

Anche io ho sempre usato -Os senza problemi...

----------

## Cazzantonio

io non ho mai notato differenza tra -Os e -O2.... ma nemmeno tra -march=i686 e -march=athlon-xp.....

forse ste stai lì pronto con il cronometro....

----------

## =DvD=

Io faccio questa prova, poi vi saprò ridire.

----------

## r_howie

Per mia esperienza, più la macchina è lenta più si sentono i benefici di -Os. Su un P3 450MHz ha perfettamente senso usare questo flag, su un P4 o equivalenti direi di no.

----------

## dappiu

Il filesystem in questo caso non conta molta. 

Sono passato da ReiserFS a Reiser4 e ti assicuro che applicazioni come mozilla, firefox, thunderbird e soprattutto openoffice non sono poi tanto più veloci.

Con la reiser4 ho visto dei tagli al tempo di esecuzione di "slocate -u" per esempio oppure nelle ricerce all'interno del portage con etcat, che sono diventate quasi istantanee.

Puoi provare con il prelink per avere un'avvio delle applicazioni più veloci. Mi sembra che firefox abbassi di un secondo o forse meno il tempo di apertura.

----------

## Lestaat

 *dappiu wrote:*   

> Il filesystem in questo caso non conta molta. 
> 
> Sono passato da ReiserFS a Reiser4 e ti assicuro che applicazioni come mozilla, firefox, thunderbird e soprattutto openoffice non sono poi tanto più veloci.
> 
> Con la reiser4 ho visto dei tagli al tempo di esecuzione di "slocate -u" per esempio oppure nelle ricerce all'interno del portage con etcat, che sono diventate quasi istantanee.
> ...

 

Ecco....i prelink mi sembra già una cosa ragionevole.

File piccoli= maggior velocità non mi sembra una relazione corretta.

Se un file è piccolo significa che ci saranno + cose che verranno caricate in seguito rallentando l'uso del programma.

Il prelink invece, (sistema usato molto spesso in progetti di programmazione high lev) è sicuramente un metodo efficace per la velocità.

leggevo qualche tempo fa un articolo a proposito di un demonietto che man mano che si usa il pc lo rende più veloce proprio adattando automaticamente i prelink....

appena ritrovo l'articolo vi faccio sapere

----------

## =DvD=

 *Quote:*   

> Se un file è piccolo significa che ci saranno + cose che verranno caricate in seguito rallentando l'uso del programma. 

 

E chi l'ha detto? L'eseguibile piccolo è solo piu piccolo e meno ottimizzato verso il tempo (e più verso lo spazio)

Io prelinko dopo l'emerge -uD world, non ci vuole poi molto.

Però resta il fatto che per me il sistema è troppo lento a far partire i programmi.

Sarà mica che ho troppa poca ram?

----------

## n3m0

 *=DvD= wrote:*   

> Sarà mica che ho troppa poca ram?

 

Beh certo non è tanta  :Wink: 

Questo poi dipende dal WM che usi...ma se ricordo bene sei uno che si tiene leggero, giusto?

Cmq il discorso di -Os è giusto. Un eseguibile piccolo ti favorisce i tempi di loading, che per un applicazione come firefox son più importanti di qualsiasi ottimizzazione i vari -On possono dare a runtime.

Ovviamente i benefici di -Os si sentono di più su PC datati. 

Direi che nel tuo caso provare non sarebbe una cattiva idea.

Poi puoi provare anche una combo di -Os e prelink (ovviamente col prelink rendi di nuovo gli eseguibili leggermenti più grossi, ma non certo come la tua situa attuale).

----------

## =DvD=

Si, secondo come mi alzo vado di fluxbox o xfce.

Ho un 

```
gnunghino ~ # uname -a

Linux gnunghino 2.6.11-gentoo-r3 #1 Sun Mar 13 11:23:54 CET 2005 i686 AMD Athlon(tm) XP 1500+ AuthenticAMD GNU/Linux

```

.

Come è sta cosa che il prelink allarga gli eseguibili?

Se è così non prelinco!!

----------

## shev

Io da una vita uso -Os con estrema soddisfazione e senza alcun problema di sorta. Ai tempi feci passare tutte le varie cflags per poi stabilirmi su -Os; chiaramente non fa di un pII un processore da sala server della NSA, ma se la provi e ti trovi bene, usala (non la sala server, la flag -Os ovviamente  :Razz: ).

Poi come dice deadhead una bella lettura del link indicato e conseguente cognizione della reale utilità di certe flag non può che far bene. Sempre.

----------

## dappiu

 *=DvD= wrote:*   

> 
> 
> Come è sta cosa che il prelink allarga gli eseguibili?
> 
> Se è così non prelinco!!

 

Si aumenta leggermente di dimensione gli eseguibili.

Cmq hai provato con le LDFLAGS? Fanno la stessa cosa del prelink, in modo un po' più "trasparente" (non c'è bisogno di fare prelink ogni volta che aggiorni le librerie).

----------

## =DvD=

Ne ho letto ma non le ho ancora provate, volevo documentarmi un po' di piu su cosa fanno realmente.

Alla fine non ho capito una mazza nemmeno di quello che fa prelink, visto che non credevo aumentasse notabilmente la dimensione degli eseguibili...

(ovvio che se invece aumenta di qualche kb chi se ne frega!)

----------

## n3m0

 *=DvD= wrote:*   

> (ovvio che se invece aumenta di qualche kb chi se ne frega!)

 

Guarda che mica ti raddoppia la dimensione degli eseguibili  :Very Happy: 

Tutto dipende da quante lib usa l'eseguibile, ma cmq non è sta catastrofe.

Secondo me la combo succitata da me potrebbe dare i suoi frutti, perchè con quel poco di eseguibile in più cmq risparmi sulla fase di linking che è bella pesante quando si tratta di apps C++ soprattutto.

Cmq, direi di iniziare a passare a -Os  :Wink: 

----------

## =DvD=

Continuare vuoi dire!! =D 

Ho iniziato oggi.. domattina do un bel emerge -e system o forse world, dipende come mi gira!

La mia cartella /usr/lib/Mozilla-firefox/ è di 28 mega

----------

## Danilo

 *shev wrote:*   

> lags per poi stabilirmi su -Os; chiaramente non fa di un pII un processore da sala server della NSA, ma se la provi e ti trovi bene, usala (non la sala server, la flag -Os ovviamente ).
> 
> 

 

Mi passi anche le altre flags che usi oltre a Os?

----------

## randomaze

 *=DvD= wrote:*   

> -La ram non mi si riempie subito (ho solo 256 Mb)

 

Questo é falso.

Se un programma parte e si alloca 40M lo farà a prescindere dalle flag utilizzate.

----------

## mrfree

 *randomaze wrote:*   

>  *=DvD= wrote:*   -La ram non mi si riempie subito (ho solo 256 Mb) 
> 
> Questo é falso.
> 
> Se un programma parte e si alloca 40M lo farà a prescindere dalle flag utilizzate.

 

Quello che tu dici è vero ma =DvD= ha ragione nel senso che un binario per essere eseguito deve essere caricato in memoria, di conseguenza un binario compilato con le ottimizzazioni in -Os occuperà anche meno memoria rispetto ad uno compilato con le -O3 oltre che a meno spazio sull'hdd.

Il discorso della memoria allocata dal programma è un'altro e prescinde dalla dimensione del binario stesso.

 *.:deadhead:. wrote:*   

> Io con
> 
> Codice:
> 
> CFLAGS="-Os -march=pentium4 -pipe -ffast-math -fforce-addr"
> ...

 

-ffast-math "rompe" i binari  :Smile:  (certo che il termine break avrebbe avuto tutto un altro effetto)

Quando ho avuto a che fare con acovea (c'è un mio post sul forum inglese se ti interessa) uno sviluppatore gentoo mi ha detto qualcosa tipo  *Quote:*   

> ... non ti azzardare a postare un bug report dopo aver utilizzato -ffast-math tra le tue CFLAGS ...

 

La maggior parte del software ti funziona perchè semplicemente parecchie ottimizzazioni "pericolose" vengono filtrate negli ebuilds

Personalmente sto utilizzando una variabile CFLAGS da tre righe ottenuta da giorni di test con acovea, in generale il sistema è stabile ma a volte ho grossi problemi con software multimediale tipo ffmpeg e cose del genere.

----------

## randomaze

 *mrfree wrote:*   

> Quello che tu dici è vero ma =DvD= ha ragione nel senso che un binario per essere eseguito deve essere caricato in memoria, di conseguenza un binario compilato con le ottimizzazioni in -Os occuperà anche meno memoria rispetto ad uno compilato con le -O3 oltre che a meno spazio sull'hdd.

 

Vero ma non stiamo parlando di quantitativi di memoria tali da saturare 256M... anche supponendo che un binario che con -Os occupi un tot. e compilando con -O3 sia grande il doppio ne devi lanciare una marea prima di avere differenze da quel punto di vista....

Per come la ha detta =DvD= mi sembrava si riferisse al consumo in memoria globale e non a quello delle istruzioni.

----------

## gutter

 *mrfree wrote:*   

> 
> 
> Personalmente sto utilizzando una variabile CFLAGS da tre righe ottenuta da giorni di test con acovea, in generale il sistema è stabile ma a volte ho grossi problemi con software multimediale tipo ffmpeg e cose del genere.

 

Io sono dell'opinione che CFLAGS eccessivamente spinte hanno senso solo su determinati pacchetti. E anche in questo caso devono essere scelte con oculatezza.

----------

## n3m0

 *randomaze wrote:*   

> Se un programma parte e si alloca 40M lo farà a prescindere dalle flag utilizzate.

 

Se un programma ha una sezione dati di 40MB, rimarrà di 40MB sempre. Lo stesso non si può dire della sua sezione testo (il codice). Quindi, anche se non in maniera eccessivamente visibile, può capitare che qualche pagina di memoria la risparmi per qualche processo  :Wink: 

EDIT: mentre postavo questo, son stati postati altri tre messaggi -_-

----------

## mrfree

 *randomaze wrote:*   

> Vero ma non stiamo parlando di quantitativi di memoria tali da saturare 256M... anche supponendo che un binario che con -Os occupi un tot. e compilando con -O3 sia grande il doppio ne devi lanciare una marea prima di avere differenze da quel punto di vista...

 

Bhe compilando l'intero sistema con un occhio di riguardo alla dimensione dei binari... risparmia 500KB qui 20KB la, alla fine qualche bel mega di memoria lo risparmi  :Smile: 

Considera poi che non ci vuole "niente" a riempire 256MB di ram, è lo stesso quantitativo che ho sul mio notebook: con gnome 2.10 e qualche altra cosetta devo dire che l'uso dello swap si fa sentire (negativamente è ovvio); dal punto di vista della memoria ram quindi, un minore utilizzo della stessa implica anche un minore utilizzo dello swap e di conseguenza del disco (vera pecca soprattutto nei sistemi portatili).

Non ho dati precisi tra le mani (penso sia difficile fare una stima precisa in merito, ma in rete si trovano dati che pur non fornendo valori assoluti permettono comunque di fare confronti) ma sicuramente la minore ottimizzazione che porta ad un esecuzione del binario "più lenta" rispetto magari al tempo che si otterrebbe utilizzando delle ottimizzazioni più spinte, è molto meno percepibile dall'utente che un accesso in più sul disco.

----------

## =DvD=

Ovviamente parlavo di grandezza del codice, non di memoria allocata per task.

Cmq ho notato che firefox fa -O2 a -Os mi è sceso di circa 700k, che non sono gran che.

----------

## shev

 *Danilo wrote:*   

> Mi passi anche le altre flags che usi oltre a Os?

 

Certo, anche se non sono nulla di particolare:

- su ppc uso queste: 

CFLAGS="-mcpu=7450 -Os -pipe -maltivec -mabi=altivec -mpowerpc-gfxopt -fsigned-char -falign-functions=4 -falign-jumps=4"

- su x86:

CFLAGS="-mcpu=QUELLO_CHE_HAI -Os -pipe -fsigned-char -falign-functions=4 -falign-jumps=4"

Mi ci trovo bene e problemi non ne ho mai avuto, le avevo scelte dopo aver fatto qualche prova in passato e aver letto un bell'articolo a riguardo (passato sulle vecchie GWN), in cui cflags tipo queste erano risultate a sorpresa un ottimo compromesso per prestazioni/stabilità.

----------

## .:chrome:.

 *Cazzantonio wrote:*   

> io non ho mai notato differenza tra -Os e -O2.... ma nemmeno tra -march=i686 e -march=athlon-xp.....

 

-march=athlon-xp implica -march=i686.

volendo fare le cose per bene dovresti specificare 

```
-march=i686 -mcpu=athlon-xp
```

 e magari aggiungere anche un 

```
-mmmx -m3dnow
```

----------

## randomaze

 *k.gothmog wrote:*   

> -march=athlon-xp implica -march=i686.
> 
> volendo fare le cose per bene dovresti specificare 
> 
> ```
> ...

 

Non per essere cattivo ma se limitassimo la discussione alla specifica -Os vs -O2 vs -O3? Di thread con CFLAGS e arch ne abbiamo un bel pò  :Wink: 

----------

