cpu -> kernel

[Never]

non è vero... su 10' di film ho guadagnato ben (reggiti)


0=zero



è stata una scusa per ricompilare il kernel

[mjordan]

In sostanza il principio è questo. Per una sola applicazione pesante (leggasi intensa, parecchi calcoli, come transcoder) conviene ricompilare la singola applicazione anzichè il kernel. I vantaggi di un kernel ben ottimizzato si vedono maggiormente nell'esecuzione di diversi processi contemporaneamente (questo per via di quelle sezioni critiche dell'SO come ad es. lo scheduler e il dispatcher.) Un codice ben generato (compito del compilatore) aumenta di netto le prestazioni delle latenze di dispatch. Ma quando il processo è univoco e gli altri sono in uno stato "sleep" (come avviene nella maggiorparte delle macchine desktop del pianeta) conviene tecnicamente parlando ricompilare la propria applicazione, magari modificando a mano il Makefile dei sorgenti generato dal configure e passando come flag del compilatore --march=xxx-xxx sostituendo alle x il nome del processore posseduto (per esempio --march=athlon-xp) e verificando che il livello di ottimizzazione della traduzione del codice non sia inferiore all' -O3 (anche se questo, in rari xcasi, può portare alla generazione di codice scorretto) e comunque mai sotto all' -O2 (la massima ottimizzazione ottenibile con la massima sicurezza di correttezza di generazione del codice).

Io sono un paranoico e in genere ricompilo sia il kernel che l'applicazione in questione, ma ripeto è paranoia. I vantaggi di una tale operazione la può notare un server IBM con 800 thread http al secondo da servire, non un comunissimo desktop. Ricompilando la singola applicazione come transcoder, invece, potresti migliorare i tempi di qualche minuto, che anche se sembra poco, è un risultato strepitoso (pensa se l'elaborazione dovesse durare 5 anni guadagnando un minuto ogni ora di elaborazione con la sola ottimizzazione del compilatore .... ).

Spero di essere stato il + chiaro possibile per chi aveva ancora dei dubbi.

[mjordan]

Originariamente inviato da Never
non è vero... su 10' di film ho guadagnato ben (reggiti)


0=zero



è stata una scusa per ricompilare il kernel

Vedo che il concetto non è chiaro. Non mi hai mica sorpreso dicendo che su 10 minuti di film hai ottenuto 0. Ma se al posto dei dannati secondi misuri i microsecondi, vedi che il miglioramento c'è stato. E quì si ritorna a quello che ho già detto e ridetto.

[Never]

no no sei chiarissimo ed anche didattico... la mia era una battuta, sapevo che per te era un risultato atteso, quando avrò tempo e voglia proverò a ricompilare transcode (anche se sono un po' meno paranoico)

ciao

[mjordan]

Addirittura didattico

[Jøhñ Ðøë]

Originariamente inviato da mjordan
In sostanza il principio è questo. Per una sola applicazione pesante (leggasi intensa, parecchi calcoli, come transcoder) conviene ricompilare la singola applicazione anzichè il kernel. I vantaggi di un kernel ben ottimizzato si vedono maggiormente nell'esecuzione di diversi processi contemporaneamente (questo per via di quelle sezioni critiche dell'SO come ad es. lo scheduler e il dispatcher.) Un codice ben generato (compito del compilatore) aumenta di netto le prestazioni delle latenze di dispatch. Ma quando il processo è univoco e gli altri sono in uno stato "sleep" (come avviene nella maggiorparte delle macchine desktop del pianeta) conviene tecnicamente parlando ricompilare la propria applicazione, magari modificando a mano il Makefile dei sorgenti generato dal configure e passando come flag del compilatore --march=xxx-xxx sostituendo alle x il nome del processore posseduto (per esempio --march=athlon-xp) e verificando che il livello di ottimizzazione della traduzione del codice non sia inferiore all' -O3 (anche se questo, in rari xcasi, può portare alla generazione di codice scorretto) e comunque mai sotto all' -O2 (la massima ottimizzazione ottenibile con la massima sicurezza di correttezza di

my 2 cents...
all'inizio quando misi gentoo ricompilai tutto in -O3.
Fondamentalmente il _tutto_ è sbagliato. Ora ho ricompilato il sistema e tutto il resto in -Os (O2 con ottimizazzione del size del binario)e vabbeh il march=atlohn-xp e altro... risultato che il sistema è "a okkiometro" uguale a quando era in -O3, solo è moooolto più snello, i binari (prelinkati) ci mettono meno a caricare e occupano meno memoria (a volte)... il caso più eclatante è stato openoffice, compilarlo in -O3 è un suicidio perchè prima di tutto è molto più lento a compilare, poi su un programma I/O bound come quello è francamente inutile...
Poi le applicazioni più cpu bound, es mencoder e transcode e altri l'ho ricompilate in -O3.

ah, per dirla tutta, uso gentoo da gennaio, e non ho mai avuto il sistema borked nonostante usi la unstable, e credo che l'applicazione su un server non sia da impiccarsi come dite, anche per esperienza diretta. Poi se non la si conosce o la i usa una settimana, beh, imho è charo che nn vi ci trovate bene...

[mjordan]

Ok ma in parole semplici e comprensibili a tutti, cosa volevi comunicarci?

[Jøhñ Ðøë]

che se fai le cose con la speranza di vederle "a occhio" è meglio che ti dai alla zappa bimbo

Ciauz

[Ikitt_Claw]

Originariamente inviato da Never
quando avrò tempo e voglia proverò a ricompilare transcode (anche se sono un po' meno paranoico)
ciao

A occhiometro (sempre usato transcode ricompilato io, ma per altri motivi )
non dovresti guadagnare molto, perche` l'encoder mpeg2 di default (bbmpeg) e` lent(issim)o di suo.

libavcodec (modulo export_ffmpeg) integra da un po` di tempo un veloce (si parla di 4x, anche) codec mpeg2, pero` sulla ML di transcode sono apparse
qualche lamentela; pare che per adesso tale encoder non generi sempre flussi aderenti allo standard.

In futuro la cosa dovrebbe evolvere positivamente, per cui stay tuned...

Personalmente, ho da poco scoperto xvid-dev-api-4. E sono felice.

[Never]

Originariamente inviato da Ikitt_Claw
Personalmente, ho da poco scoperto xvid-dev-api-4. E sono felice.

un po' più di info???

[Ikitt_Claw]

Originariamente inviato da Never
un po' piu di info???

Il nome altisonante (?) puo` fuorviare
si tratta semplicemente della versione di xvid in sviluppo
che poi si concretizzera` nella futura 1.0

Ho semplicemente scaricato i sorgenti da CVS e li ho compilati, e ora sto facendo qualche prova sul mio sistema
(e con transcode )

I risultati sono estremamente promettenti IMHO, superiori
anche a ffmpeg/libavcodec che sino a ieri era per me la scelta d'elezione per superiori meriti tecnici.

C'e` da dire che l'uso di questa versione di xvid e` scoraggiata dagli sviluppatori in quanto di sviluppo, stando a loro si dovrebbe usare solo e soltanto la vecchia dev-api-2 (xvid 0.9.x) che pero`, almeno nei miei test, non da` nulla in piu` rispetto a libavcodec, anzi, e` pure piu` lenta.

[mjordan]

Originariamente inviato da Jøhñ Ðøë
che se fai le cose con la speranza di vederle "a occhio" è meglio che ti dai alla zappa bimbo

Ciauz

Hai letto tutti i post precedenti che ho fatto?

[Never]

[b]... vecchia dev-api-2 (xvid 0.9.x) che pero`, almeno nei miei test, non da` nulla in piu` rispetto a libavcodec, anzi, e` pure piu` lenta.

Ok grazie, concordo con te per xvid 0.9 non ho provato la "pre1.0" anche perchè ultimamente faccio solo XSVCD
proverò, magari memcoder anche per i SVCD.

Ciao

[LukeHack]

Originariamente inviato da mjordan
Addirittura didattico

il discorso sul lungo termine per notare dei miglioramenti è giustissimo, ma in pratica ricompilando il kernel (2.4.20 all'epoca) sulla slack,il 2D andava molto meglio..ossia nel kde,tutte le finestre,processi ed anche mozilla (miracolo!) cominciarono ad avviarsi mettendoci un discreto(ben visibile) tempo inferiore...GIURO!

nel 2.4.22 invece,tali miglioramenti li ho notati solo per l'apertura di konqueror...ma è pur vero che di default questo kernel è compilato per 486, e non per 386 come i precedenti....quindi la mancanza di miglioramenti complessiva può essere giustificata da questo...

che ne pensi?

[mjordan]

Io penso che uso Linux dalla Slackware 3.0 e ho sempre ricompilato i kernel sostituendo quelli della distro con i vanilla ufficiali e MAI e dico MAI ho notato miglioramenti visibili al mio normalissimo occhio di essere umano.

Mai fatta una visita dal veterinario?

[LukeHack]

[b]
Mai fatta una visita dal veterinario?

si mi ha detto che chi non vede differenze coi kernel è perchè ha troppa peluria sulle orecchie che interferisce colla normale percezione spazio-temporale :eheh: :eheh: :eheh: