# [Info] MAKEOPTS="-j3" con Itel Core 2 Duo?

## canduc17

Da manuale:

```
Con MAKEOPTS si definisce quante compilazioni parallele possono essere eseguite durante l'installazione di un pacchetto. Una buona scelta è il numero di CPU nel sistema più uno, ma non è detto che sia sempre l'impostazione migliore.
```

Io ho sempre lasciato settato

```
MAKEOPTS="-j2"
```

 e non ho mai avuto un problema...

Ma visto che ho un Intel Core 2 Duo e il sistema in pratica mi riconosce 2 cpu:

```
candesktop canduc # cat /proc/cpuinfo

processor       : 0

vendor_id       : GenuineIntel

cpu family      : 6

model           : 15

model name      : Intel(R) Core(TM)2 CPU          6600  @ 2.40GHz

stepping        : 6

cpu MHz         : 2394.000

cache size      : 4096 KB

physical id     : 0

siblings        : 2

core id         : 0

cpu cores       : 2

fdiv_bug        : no

hlt_bug         : no

f00f_bug        : no

coma_bug        : no

fpu             : yes

fpu_exception   : yes

cpuid level     : 10

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 nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm

bogomips        : 4801.84

clflush size    : 64

processor       : 1

vendor_id       : GenuineIntel

cpu family      : 6

model           : 15

model name      : Intel(R) Core(TM)2 CPU          6600  @ 2.40GHz

stepping        : 6

cpu MHz         : 1596.000

cache size      : 4096 KB

physical id     : 0

siblings        : 2

core id         : 1

cpu cores       : 2

fdiv_bug        : no

hlt_bug         : no

f00f_bug        : no

coma_bug        : no

fpu             : yes

fpu_exception   : yes

cpuid level     : 10

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 nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm

bogomips        : 4799.32

clflush size    : 64
```

secondo voi posso settare

```
MAKEOPTS="-j3"
```

  :Question: 

----------

## fbcyborg

Io per il mio portatile con il core 2 duo ho seguito il consiglio del numero di processori "più uno"....

Devo dire che con l'SMP nel kernel e il -j3 va che una meraviglia.

Mi trovo davvero bene.

Secondo me dovresti impostare -j3. Almeno così lo sfrutti a pieno il processore.

----------

## CarloJekko

-j3 serve solo durante la compilazione. Dice al compilatore se puo operare parallelamente. O usi -j2 o -j3 non cambia nulla per il sw che compili.

Ciao!

----------

## djinnZ

Probabilmente l'avvertimento è stato messo lì perchè alcuni "mattoni" poco gradivano la compilazione parallela (es: mozilla, OOo, kde, gnome) e c'è rimasto anche se mi pare che tra ebuilds e automake il problema appartenga solo al passato.

Per non dire del fatto che se impieghi nella compilazione tutte le cpu/core del sistema non è una certezza matematica il guadagno in prestazioni.

----------

## Apetrini

Io con il mio Core2 Duo uso -j4 e devo dire che ora quando compila(con pacchetti grossi) ci mette qualcosa di meno(a naso). Suppongo si sfrutta di piu la cpu con -j4 tendando di occuparla sempre.

----------

## canduc17

Addirittura -j4?  :Shocked: 

----------

## fbcyborg

 *canduc17 wrote:*   

> Addirittura -j4? 

 

infatti si!!!!  :Very Happy:  Penso che -j3 sia l'opzione corretta.

----------

## bandreabis

Credo che nemmeno i developer di Gentoo sappiano quale sia il valore più corretto....

----------

## fbcyborg

Vabbè....

----------

## Kernel78

Giusto per dare qualcosa di più oggettivo rispetto a pareri puramente soggettivi (es. io metto -j12 perchè mi piace il blu) ho deciso di fare qualche prova sul mio AMD Athlon(tm) 64 X2 Dual Core Processor 4600+

Ho compilato kdelibs (un pacchetto a caso tra quelli belli grossi) con diversi valori, nella fattispecie: -j3, -j4 e -j5 e questi sono i risultati

```
     Sat Oct 27 00:06:24 2007 >>> kde-base/kdelibs-3.5.8

       merge time: 30 minutes and 29 seconds.

     Sat Oct 27 00:40:48 2007 >>> kde-base/kdelibs-3.5.8

       merge time: 30 minutes and 22 seconds.

     Sat Oct 27 01:19:12 2007 >>> kde-base/kdelibs-3.5.8

       merge time: 29 minutes and 46 seconds.

```

Come si può vedere la differenza è risibile, sarei tentato di provare a ricompilare tutto il sistema con diversi valori per vedere se su quantità ingenti di pacchetti si accumuli un risparmio di tempo significativo (ma devo trovare il tempo per farlo).

----------

## khelidan1980

Io avevo letto da qualche parte che mettondo valori in piu del numero di cpu faceva in modo che gcc arrivasse ad occupare quasi il 100% della cpu in compilazione,ma non ricordo la fonte e quindi l'attendibilità,e se fosse vera non so quanto convenga dato che,almeno io,uso il pc mentre compilo!

----------

## bandreabis

 *khelidan1980 wrote:*   

> Io avevo letto da qualche parte che mettendo valori in più del numero di cpu faceva in modo che gcc arrivasse ad occupare quasi il 100% della cpu in compilazione,ma non ricordo la fonte e quindi l'attendibilità,e se fosse vera non so quanto convenga dato che,almeno io,uso il pc mentre compilo!

 

Interessante, dove l'hai letto?

100% da un po' fastidio anche a me perché nel mentre uso il portatile e tutto rallenta... quando non si blocca, e la temperatura sale (ma per quello si può usare il risparmio energetico powersave).

Non so però (ma potrei fare una prova al prossimo emerge -uDN world) quanto più lente e lunghe potrebbero essere le compilazioni.

----------

## khelidan1980

 *bandreabis wrote:*   

>  *khelidan1980 wrote:*   Io avevo letto da qualche parte che mettendo valori in più del numero di cpu faceva in modo che gcc arrivasse ad occupare quasi il 100% della cpu in compilazione,ma non ricordo la fonte e quindi l'attendibilità,e se fosse vera non so quanto convenga dato che,almeno io,uso il pc mentre compilo! 
> 
> Interessante, dove l'hai letto?
> 
> 

 

Dovrei averlo letto o sul wiki o sulla doc ufficiale,ma non ricordo precisamente!

----------

## bandreabis

Basta cambiare il valore in make.conf?

Se è così, non ho notato differenze nell'occupazione della cpu.

----------

## Frez

Un'altra variabile da tenere presente e' se la compilazione avvenga in RAM o su disco.

Se non sbaglio il -j3/4/5 serve per utilizzare la cpu ed accedere al disco contemporaneamente.

Grossolanamente: di tutti i vari processi in fase di compilazione, uno o piu' (a rotazione) dormono in attesa che il sistema trasferisca dati da disco.

In caso di compilazione in RAM l'accesso e' estremamente piu' veloce (nella RAM "lenta"), quindi i vantaggi dei -jN con (N > nr_cpu) si dovrebbero attenuare parecchio.

Io personalmente compilo in RAM con -j2 (dual core) e spremo le cpu mantenendo il sistema utilizzabile (per normali applicazioni da ufficio, non cpu-intensive ovviamente)

Aggiungo: Linux (ovvero il kernel) identifica i processi maggiormente interattivi e assegna loro una maggiore priorita' in fase di scheduling.

Questo e l'aggiunta di un kernel preemptive rendono il sistema "responsive" anche con un idle time di 0%. (I kernel guru di passaggio possono senz'altro essere piu' precisi)

----------

## Super_Treje

Personalmente ho provare a fare tante prove sul mio portatile Toshiba P20-S203 che ha un P4 HT da 3 ghz su socket 478.

Non e un core2 ma cmq alcuni dati possono essere presi come test da fare su un core2.

La prima volta che installai gentoo, maggio 2007, iniziai pure io con un -j2.

Le motivazioni che mi diede un mio amico che mi spinse su gentoo pero' erano un po' "particolari" : un j per il compilatore, un j per ogni processore che hai.

Vabe' poi io da impiccione e rompica... che sono mi sono andato a documentare e contemporaneamente sperimentavo come mi diceva la testa a me per capire come variando quel parametro j il mio pc si comportasse.

Il test lo eseguivo sullo stesso gruppo di pacchetti abbastanza consistente come "pesantezza in fase di compilazione" oppure addirittura andavo bellamente di emerge -e world con oltre 400 pacchetti installati.

Per vedere l'impiego della cpu ho messo l'applet "controllo del sistema" di kde bello bello sulla barra con aggiornamento di memoria e cpu ad 1 secondo.

Usando j2 ho notato che la cpu non veniva utilizzata al 100% quasi mai eppure passavo anche delle ore a vedere sto' grafichetto come si comportava.

Visto che chi mi ha convinto a passare a Gentoo, io prima utilizzavo senza problemi fedora core6 senza passare alla 7 che mi pareva molto instabile, mi disse che con gentoo avrei potuto utilizzare effettivamente tutto il mio hardware fino all'ultimo registro di ogni chip avendo poi un sistema assolutamente ottimizzato per cio' che avevo come macchina mi sono detto : "tu non stai facendo cio' che devi fare!!".

Allora ho preso e ho messo -j3.

Ariparti con un emerge -e world.

Ora il grafico effettivamente mostrava che una maggiore quantita' di cpu veniva utilizzata ma cmq in alcuni pacchetti, nella fase di compilazione, non lo utilizzava al 100% ma tipo all'80-90.

"Non ci siamo ancora, non mangi, devi usarlo tutto il processore!!! "

Ho preso ed ho messo -j4.

Ariparti con emerge -e world

"Ecco ora mi piaci", usa tutto il proc e sono contento e tra l'altro non ricado nel risvolto della madaglia di usare j elevati, cioe' in quella situazione in cui il processore perde un sacco di tempo solamente per fare il dispatching tra processi abbassando quindi l'effettivo utilizzo del processore.

Per un core2duo j4 va' benissimo in quanto quel tipo di processore non ha un HT al suo interno ed e' effettivamente costituito da 2 processori, chiamati core, nudi e crudi "vecchio stampo".

Se avessi invece un quad-core ti bastera' un -j8 se questa regola di 2j per ogni core e' ancora valida.

Basta avere pazienza e circa 7-10 giorni per provare queste cosarelle  :Smile:   :Mr. Green: 

----------

