# Centrino Duo e Gentoo... quale ottimizzazione.

## gioi

Ciao ragazzi, 

sono da qualche giorno fortunato possessore di un portatile con Cenrino Duo T2330 da 1,67GHz, e, naturalmente non ho perso tempo ed ho immediatamente sostituito al pessimo Winsozz XP HE, la mia distro preferita!

Devo dire che sono piuttosto soddisfatto dell'acquisto, ed installando ho avuto modo di sperimentare il riusltato di più emerge in parallelo (monitorando sia temperatura che carico delle due cpu con gkrellm).

Vista la tecnologia piuttosto recente, ed in assenza di uno specifico FLAG, ho optato per la march=centrino, ma mi chiedevo se non ci fosse un qualche altro flag da abilitare per bilanciare meglio il carico. Certo, sono consapevole che anche i più avanzati sistemi HPC hanno i loro grattacapi per quanto riguarda il bilanciamento del carico, e non cerco nulla di automatico... mi chiedevo solo se qualcuno fosse a conoscenza di una qualche procedura per lo scheduling dei task (più che dei thread) sui singoli core...

Non so se mi sono spiegato...

----------

## gioi

Ovviamente, dimenticavo che nel MAKEOPTS ho rispettato la solita regola "-J(1+numero di Cpu)"...

----------

## .:chrome:.

la cosa più ragionevole da fare è usare march=pentium-m con i compilatori che lo supportano.

non pensare però che questo ti cambierà la vitaLast edited by .:chrome:. on Sat May 13, 2006 3:56 pm; edited 1 time in total

----------

## Onip

 *gioi wrote:*   

> Devo dire che sono piuttosto soddisfatto dell'acquisto, ed installando ho avuto modo di sperimentare il riusltato di più emerge in parallelo (monitorando sia temperatura che carico delle due cpu con gkrellm).

 

Molto, molto, ma molto rischioso....

----------

## Luca89

quoto, lanciare più emerge in parallelo può provocare la corruzione del sistema.

----------

## gioi

Vero... ma mica lanciavo in parallelo gnome e kde...

Ho lanciato in parallelo iptables e cpufreqd per esempio che non hanno dipendenze in comune, oppure laptop-mode-tools e nmap...

----------

## .:chrome:.

 *gioi wrote:*   

> Vero... ma mica lanciavo in parallelo gnome e kde...
> 
> Ho lanciato in parallelo iptables e cpufreqd per esempio che non hanno dipendenze in comune, oppure laptop-mode-tools e nmap...

 

e quindi...? gli emerge paralleli sono rischiosi per le possibili interazioni che possono avere, non perché ci possono essere dipendenze comuni

----------

## gioi

 *k.gothmog wrote:*   

>  *gioi wrote:*   Vero... ma mica lanciavo in parallelo gnome e kde...
> 
> Ho lanciato in parallelo iptables e cpufreqd per esempio che non hanno dipendenze in comune, oppure laptop-mode-tools e nmap... 
> 
> e quindi...? gli emerge paralleli sono rischiosi per le possibili interazioni che possono avere, non perché ci possono essere dipendenze comuni

 

Ovviamente, ma se non vanno a toccare nulla "in comune" come fanno ad interagire... alla fine, esaurita la fase di config, non sono altro che una serie di compilazioni in parallelo... certo la fase finale di "installazione" potrebbe accedere a risorse comuni (penso soprattutto alle librerie), ma con un poco di attenzione si evita di far boiate... è ormai dala 2004.x che "emergo" in parallelo e non ho mai avuto un problema.

Certo, se emergessi in parallelo qt e kdelibs oppure gtk e metacity, siamo d'accordo che è come fare un salto nel buio, ma dubito fortemente che emergendo openoffice-bin e gimp ci sia qualche iterazione pesante (il primo alla fine è un tar-gunzip, mentre il secondo compila alcune librerie)....

----------

## Cazzantonio

 *gioi wrote:*   

> Ovviamente, ma se non vanno a toccare nulla "in comune" come fanno ad interagire... alla fine, esaurita la fase di config, non sono altro che una serie di compilazioni in parallelo... certo la fase finale di "installazione" potrebbe accedere a risorse comuni (penso soprattutto alle librerie), ma con un poco di attenzione si evita di far boiate... è ormai dala 2004.x che "emergo" in parallelo e non ho mai avuto un problema.
> 
> Certo, se emergessi in parallelo qt e kdelibs oppure gtk e metacity, siamo d'accordo che è come fare un salto nel buio, ma dubito fortemente che emergendo openoffice-bin e gimp ci sia qualche iterazione pesante (il primo alla fine è un tar-gunzip, mentre il secondo compila alcune librerie)....

 

I casi sono due... o sei assolutamente sicuro di quello che fai (ovvero conosci a menadito i programmi che installi e il relativo ebuild) oppure ti prendi i tuoi rischi e tenti la fortuna   :Wink:  Il fatto che la possibilità che qualcosa vada male sia ridotta (specialmente se si fa attenzione) non significa che sia nulla e la vita ci insegna che se qualcosa può andare male prima o poi lo farà   :Rolling Eyes:   :Wink: 

----------

## gioi

Non credo di essere uno sprovveduto in tal senso, sono quasi dieci anni che lavoro (e paciocco) su linux, quando ancora i vari yum ed apt-get (ed i conseguenti repository) erano ben lungi dall'essere così diffusi, per cui molti programmi andavano installati a mano (ricordo ancora Mozilla-mozilla in versione alpha che sul mio misero k6-2 impiegava un'eternità a compilare)... sebbene il mio approccio a gentoo sia moolto più recente (Maggio 2004) non ho mai riscontrato problemi di sorta (giusto un paio di configurazioni di rete, ma la sono scemo io, perchè se uppo la rete ma non configuro i dns...  :Razz: ) e bene o male conosco il sw che vado ad installare (e relative librerie)... quindi sono sempre andato abbastanza sul sicuro...

Certo non mi sognerei mai di lanciare in parallelo l'emerge di gcc e glibc... per fare un esempio (ed in generale nulla in parallelo a glibc)...

Cmq, ritornando IN-TOPIC

quali ottimizzazioni suggerite per il centrino duo?

----------

## .:chrome:.

 *gioi wrote:*   

> quali ottimizzazioni suggerite per il centrino duo?

 

ancora?

 *k.gothmog wrote:*   

> -march=pentium-m

 

è l'unica possibile con gli attuali compilatori, ed è l'architettura che più si avvicina a quella del core duo

poi ovviamente dovrai inserire nel kernel l'uso delle routines HyperThreading

----------

## gioi

 *k.gothmog wrote:*   

>  *gioi wrote:*   quali ottimizzazioni suggerite per il centrino duo? 
> 
> ancora?
> 
>  *k.gothmog wrote:*   -march=pentium-m 
> ...

 

Ok mi sono spiegato male io...

Non intendevo ottimizzazioni di compilazione... quelle già fatte tutte (anche nel kernel gentoo-sources compilato "a mano")

intendevo eventuali pacchetti (anche non disponibili nel portage) che permettano di "spremere" in maniera ottima le cpu... 

So che sullo scheduling dei task si può intervenire solo a livello di policy (e non scrivere, ad esempio policy ad hoc), ma quali strumenti permettono la scelta di tali policy?

----------

## eddy89

Mi pare che gimp abbia una USE smp, nn so bene a cosa serva ma dovrebbe sfruttare un pochetto di più quando fai operazioni grafiche.. 

Non saprei dire nient'altro..

----------

## Luca89

 *gioi wrote:*   

> intendevo eventuali pacchetti (anche non disponibili nel portage) che permettano di "spremere" in maniera ottima le cpu... 
> 
> So che sullo scheduling dei task si può intervenire solo a livello di policy (e non scrivere, ad esempio policy ad hoc), ma quali strumenti permettono la scelta di tali policy?

 

Visto che sei su un portatile di consiglio di abilitare il cpu scaling in modo da risparmiare energia.

----------

## earcar

 *k.gothmog wrote:*   

> è l'unica possibile con gli attuali compilatori, ed è l'architettura che più si avvicina a quella del core duo
> 
> poi ovviamente dovrai inserire nel kernel l'uso delle routines HyperThreading

 

Non mi sembra che i centrino duo siano anche hyperthreading  :Rolling Eyes: 

----------

## .:chrome:.

 *earcar wrote:*   

>  *k.gothmog wrote:*   è l'unica possibile con gli attuali compilatori, ed è l'architettura che più si avvicina a quella del core duo
> 
> poi ovviamente dovrai inserire nel kernel l'uso delle routines HyperThreading 
> 
> Non mi sembra che i centrino duo siano anche hyperthreading 

 

no, è vero. però l'architettura è del tutto assente anche nel GCC-4.x, e la coppia 2-way SMP e HyperThreading, su pentium-M, sono la cosa che più si avvicina all'architettura reale.

@gioi:

perdonami, non avevo capito  :Smile: 

da quel punto di vista, non dovresti porti il problema, perché è compito dello scheduler quello di distribuire i processi tra le diverse unità di elaborazione. quello che è necessario è che il kernel sappia su che tipo di processore sta girando.

poitresti anche fare delle prove usando diversi scheduler (anche per l'IO) e valutare quello che ti sembra migliore.

come siano messi allo stato attuale non so, ma i ck-sources fino a poco tempo fa sostituivano lo scheduler O(1) con lo staircase, che in alcuni contesti dava risultati interessanti.

----------

## earcar

 *k.gothmog wrote:*   

>  *earcar wrote:*    *k.gothmog wrote:*   è l'unica possibile con gli attuali compilatori, ed è l'architettura che più si avvicina a quella del core duo
> 
> poi ovviamente dovrai inserire nel kernel l'uso delle routines HyperThreading 
> 
> Non mi sembra che i centrino duo siano anche hyperthreading  
> ...

 

Scusami ma proprio non capisco  :Rolling Eyes: 

I core duo sono dei normali dual core, quindi bisogna abilitare solo SMP nel kernel come tutti i processori dual core. Oltretutto l'hyperthreading utilizza un secondo "aggancio" all'unica pipeline di ogni processore/core (come tu stesso puntualizzi sempre), cosa che sui core duo non esiste.  :Rolling Eyes: 

BTW, per quanto riguarda le C[XX]FLAGS il mio consiglio è 

```
-pipe -O2 -march=pentium-m -msse3 -fomit-frame-pointer
```

Ciauz!

----------

## .:chrome:.

 *earcar wrote:*   

> I core duo sono dei normali dual core, quindi bisogna abilitare solo SMP nel kernel come tutti i processori dual core. Oltretutto l'hyperthreading un secondo aggancio alla pipeline di ogni processore/core (come tu stesso puntualizzi sempre), cosa che sui core duo non esiste.

 

hai ragione. però quello che a me da da pensare è che l'architettura che usano non è la stessa dei centrino, né dei Pentium3/4, ma è qualcosa di abbastanza diverso.

quanto all'uso dell'HyperThreading, mi rimetto solo a quanto mi diceva una volta n tizio, molto più ferrato di me su questa materia, che diceva che il modo in cui lavorano i due core in congiunzione era molto simile a quello della pipeline dei processori HT, forse più che il modo in cui interagiscono due CPU normali in un sistema SMP.

così me l'ha venduta e così la rigiro. mi sono fidato, perché lui ne sa di certo più di me sui microprocessori... poi chissà magari mi ha detto una vaccata  :Smile: 

----------

## gioi

 *k.gothmog wrote:*   

> 
> 
> @gioi:
> 
> perdonami, non avevo capito 
> ...

 

Ecco, l'informazione sui ck-sources è preziosissima... vedrò di fare delle prove! Ti ringrazio...

----------

## gioi

 *earcar wrote:*   

> 
> 
> BTW, per quanto riguarda le C[XX]FLAGS il mio consiglio è 
> 
> ```
> ...

 

dunque io ho già abilitato

```
-pipe -O2 -march=pentium-m -fomit-drame-pointer
```

ma il -msse3?

che vantaggi dà in compilazione? Le sse3 sono simd quindi lavorano solo su dati in floating point... ergo applicazioni multimediali... conviene sul serio abilitarlo nei flag generali di compilazione?

----------

## .:chrome:.

 *gioi wrote:*   

> ma il -msse3?
> 
> che vantaggi dà in compilazione? Le sse3 sono simd quindi lavorano solo su dati in floating point... ergo applicazioni multimediali... conviene sul serio abilitarlo nei flag generali di compilazione?

 

in compilazione non ti danno nessun vantaggio

metterle nelle CFLAGS non costa nulla, ma di codice già pronto per SSE3 dubito che se ne vedrà in giro, e secondo me se ne vedrà un gran poco, quindi si tratterà di una flag che non darà nessun beneficio (e nessuna penalizzazione) al sistema

per carità.. tutto questo è una mia opinione

----------

## gioi

(maledette virgole)...

Intendevo che vantaggio mi da mettere qualla flag nelle opzioni generali di compilazione...cioè... il numero di applicazioni che beneficiano delle SSE3 è davvero ridotto sia come target (multimedia) che come percentuale intrinseca (la maggior parte non utilizza specifiche migliorie che adottino tale tecnologia)...

In effetti da questo punto di vista sono completamente d'accordo con te, k.gothmog....

----------

