slacky.eu

joe ha scritto:Mi chiedevo se vi fosse qualche accorgimento o "trucco" per migliorare le prestazioni in fase di compilazione.

man gcc ha scritto: Without any optimization option, the compiler's goal is to reduce the cost of
compilation and to make debugging produce the expected results. Statements are
independent: if you stop the program with a breakpoint between statements, you can
then assign a new value to any variable or change the program counter to any other
statement in the function and get exactly the results you would expect from the
source code.

Turning on optimization flags makes the compiler attempt to improve the performance
and/or code size at the expense of compilation time and possibly the ability to
debug the program.

[...]
-O0 Reduce compilation time and make debugging produce the expected results. This
is the default.
[...]

joe ha scritto:Più o meno ho capito.
Quindi la storia di ccache non è inerente all'esempio di mplayer...

joe ha scritto: Dal canto mio penso che forse un piccolo incremento di prestazioni sia ottenibile spegnendo il server grafico X e lanciando la compilazione in tty1 per esempio. Io l'ho fatto compilando all'interno di una sessione "screen" mandata in background e appunto spegnendo X e altri software che potessero occupare inutilmente cpu..
Francamente non so quanto incida, a me la compilazione di mplayer impiega veramente troppo... non ho cronometrato ma sicuramente più di un'ora.

joe ha scritto: E il kernel... io sto usando quello di default non riconfigurato/ricompilato quindi, si potrebbe assistere ad un incisivo miglioramento compilando su un sistema ch eusa un kernel maggiormente ottimizzato?

erio ha scritto:aspetti il 2.6.38 e la patch di Galbraith,poi dai i make a -j32,e puoi fare anche altro,almeno con il port del 2.6.36 era cosi.

albatrosla ha scritto:...Un trucco per "risolvere" il problema, che torna utile se la directory dei sorgenti è "a perdere" o se si pensa di doverci riprovare un po' di volte, è quello di copiare i sorgenti e compilare tutto in tmpfs o comunque su un ramdisk. I tempi di accesso alla ram sono molto inferiori di quelli di accesso al disco, e non c'è il problema di operazioni concorrenti che vengano eseguite sul device. Potendo disporre di quantitativi di ram sufficienti, è una via da prendere seriamente in considerazione.

• Generalmente ogni settimana compilo molti programmi di cui seguo il ramo current.
• Ho 2GB di memoria di cui me ne resta più o meno sempre 1 libero.

Compilazione di 'dia' con /tmp in tmpfs:
real    4m39.050s
user    4m40.930s
sys     0m36.770s

Compilazione di 'dia' con /tmp  su HD:
real    4m45.916s
user    4m39.930s
sys     0m38.680s

spina ha scritto:Ma la compilazione su HD è avvenuta dopo un riavvio? Perché se no il risultato potrebbe essere falsato.

spina ha scritto:Comunque mi sono venuti dei dubbi, ho provato a compilare 5 programmi e mi è sembrato anche a me che ci mettesse più del solito. In teoria però il ragionamento non è sbagliato e l'accesso al disco è davvero molto più lungo di quello in RAM. Non vorrei ci sfuggisse qualche altro dettaglio. Ad esempio a me è sembrato che il processore si riscaldasse più del solito. Magari in questo modo la RAM si scalda troppo o che ne so. Butto delle ipotesi perché effetticamente non mi spiego questi risultati, teoricamente dovrebbe metterci molto di meno se tutto il processo avviene in RAM-

spina ha scritto: Comunque, per ora provo a tenere il /tmp in RAM, se troverò problemi ve lo farò sapere. Il problema più grave è che io faccio praticamente tutto in /tmp e quindi rischio di riempirla senza accorgemene, a quel punto voglio vedere che succede, semplice "no space left on device" o altro? Fino ad ora non ho mai consumato interamente i miei 2GB, neanche compilando le wxGTK con -j3.