cpu -> kernel [Archivio] - Hardware Upgrade Forum

AnonimoVeneziano

21-10-2003, 10:28

Originariamente inviato da mjordan
Quell'opzione attiva semplicemente il giusto flag "--march=xxx" del compilatore GCC. Non è indispensabile ma ti da un'ottimizzazione migliore, + adatta al tuo processore. Chi invece dice che nota "miglioramenti" in termini di velocità mente. I miglioramenti sono sicuramente "computazionalmente evidenti" ma non a tal punto da essere evidenziati "a occhio".

Ciao.

Bhe, penso che sotto alto carico qualche miglioramento lo si possa notare anke a occhio

Ciao

mjordan

21-10-2003, 11:25

Pensare è un conto, essere obiettivi è un altro. Non si nota nessun miglioramento, soprattutto in vista del fatto che un'applicazione coinvolge tonnellate di librerie sottostanti "precompilate". Ripeto: I miglioramenti ci sono (ovviamente), ma nessun occhio umano si sofferma sui millisecondi. Uno scheduler che migliora la prelazione su un processo di due ms ha ottenuto un incremento di prestazioni enorme. Non per questo un occhio umano è in grado di accorgersene.

AnonimoVeneziano

21-10-2003, 11:43

Originariamente inviato da mjordan
Pensare è un conto, essere obiettivi è un altro. Non si nota nessun miglioramento, soprattutto in vista del fatto che un'applicazione coinvolge tonnellate di librerie sottostanti "precompilate". Ripeto: I miglioramenti ci sono (ovviamente), ma nessun occhio umano si sofferma sui millisecondi. Uno scheduler che migliora la prelazione su un processo di due ms ha ottenuto un incremento di prestazioni enorme. Non per questo un occhio umano è in grado di accorgersene.

Bho, se lo dici tu ci credo :)

Comunque effettivamente la sola compilazione ottimizzata del kernel non porterà a risultati soddisfacenti, ma la compilazione ottimizata pure dell' infrastruttura penso proprio che sia + visibile

mjordan

21-10-2003, 11:50

Certo. Ma a questo punto conviene andare di LFS :sofico:

AnonimoVeneziano

21-10-2003, 11:51

Originariamente inviato da mjordan
Certo. Ma a questo punto conviene andare di LFS :sofico:

O gentoo o CRUX (ricompilando il sistema di base) ;)

Ciao

mjordan

21-10-2003, 11:55

Due distro che non ho mai provato e mai proverò ;)

Hell-VoyAgeR

21-10-2003, 12:00

Originariamente inviato da mjordan
Due distro che non ho mai provato e mai proverò ;)

ok con questo post sei entrato definitivamente nel novero dei miei idoli :)

AnonimoVeneziano

21-10-2003, 12:01

Originariamente inviato da mjordan
Due distro che non ho mai provato e mai proverò ;)

Ognuno ha i suoi gusti :)

Personalmente Gentoo non mi gusta tantissimo , il portage per me non è ankora ben congegnato, a parte il fatto che la versione STABLE ha certi pacchetti Obsoleti che non vengono aggiornati , e la UNSTABLE è UNSTABLE proprio nel vero senso della parola ( pensa che un po' di tempo fa c'era pure GLIBC beta tra i pacchetti della UNSTABLE) , inoltre spesso sono Broken certi EBUILDs , e è l'unica distro con cui Internet mi gira una Lumaca e non ho ankora capito perchè (ci mette anke 30 secondi a risolvere gli indirizzi.... BHO)

Invece la CRUX è sicuramente una delle mie Distro preferite . E' semplicissima, e ti lascia gestire tutto a te . Ha un sistema di Ports semplicissimo che non conosce neanke quale sia la parola BROKEN ,e creare un ports per mano tua è altrettanto semplice e ci perdi 1 minuto circa.

Ciao

mjordan

21-10-2003, 12:06

No no io non le proverò mai perchè per me le distro sono soltanto 3. Ovvero quelle che sono sinonimo di Linux (gusti a parte ovviamente) e cioè:
RedHat, Debian, Slackware. Thò... Pure una Suse va ...

Ne possono fare quante ne vogliono. Sinceramente non mi interessano.

mjordan

21-10-2003, 12:07

Originariamente inviato da Hell-VoyAgeR
ok con questo post sei entrato definitivamente nel novero dei miei idoli :)

In che senso scusa? :D Mi pigli per il sedere? :sofico:

Hell-VoyAgeR

21-10-2003, 12:09

Originariamente inviato da mjordan
In che senso scusa? :D Mi pigli per il sedere? :sofico:

assolutamente no, la penso esattamente come te
anche per esperienza personale di questi giorni su un server gentoo-based!

mjordan

21-10-2003, 12:11

E l'idea di mettere gentoo su un server di chi è stata? :D

AnonimoVeneziano

21-10-2003, 12:19

Originariamente inviato da mjordan
No no io non le proverò mai perchè per me le distro sono soltanto 3. Ovvero quelle che sono sinonimo di Linux (gusti a parte ovviamente) e cioè:
RedHat, Debian, Slackware. Thò... Pure una Suse va ...

Ne possono fare quante ne vogliono. Sinceramente non mi interessano.

Cosa intendi per "Sinonimo di linux" ? :confused:

mjordan

21-10-2003, 12:27

Intendo che "ai tempi d'oro" (cioè 1995 e precedenti) erano le uniche distro ad essere considerate tali. Quando chiedevi cosa usavano domandavi:"Usi Red Hat, Debian o Slack?" :D Già la Suse era una distro abbastanza inusuale.

Ah pure la Caldera ricordo, col suo famigerato "Network Desktop" ... Ma personalmente penso che la gente che l'abbia usata si conti sulla punta delle dita ...

Hell-VoyAgeR

21-10-2003, 13:20

Originariamente inviato da mjordan
E l'idea di mettere gentoo su un server di chi è stata? :D

lasciamo perdere... cmq non io altrimenti ora sarei con un pinguino di cemento di 2 tonnellate attaccato al collo in fondo all'adriatico!

pinball

21-10-2003, 13:48

Originariamente inviato da AnonimoVeneziano
Invece la CRUX è sicuramente una delle mie Distro preferite . E' semplicissima, e ti lascia gestire tutto a te . Ha un sistema di Ports semplicissimo che non conosce neanke quale sia la parola BROKEN ,e creare un ports per mano tua è altrettanto semplice e ci perdi 1 minuto circa.

Ciao

sta crux mi alletta.. quasi quasi la provo! :) ma a quanto ho capito ha iun sistema tipo apt-get per l'installazione dei pacchetti o sbaglio?

ciaooo

AnonimoVeneziano

21-10-2003, 13:53

Originariamente inviato da moly82
ma a quanto ho capito ha iun sistema tipo apt-get per l'installazione dei pacchetti o sbaglio?

ciaooo

No, direi che è tutto il contrario :D

Ciao

pinball

21-10-2003, 13:56

Originariamente inviato da AnonimoVeneziano
No, direi che è tutto il contrario :D

Ciao

quindi come slack che ti compili tutto a mano? :confused: :D

AnonimoVeneziano

21-10-2003, 14:03

Originariamente inviato da moly82
quindi come slack che ti compili tutto a mano? :confused: :D

Quasi, crei un file con all' interno delle informazioni primarie (tipo il sito dove scaricare il file sorgente e i comandi per la compilazione) , poi dai il comando "pkgmk" e ti crea un pacchetto da installare . Poi c'è un sistema "prt-get" per la risoluzione delle dipendenze , ma è ankora acerbo, per i piccoli programmi è molto + comodo il sistema classico, ma per i programmi grandi che richiedono parecchie dipendenze è forse un po' + comodo PRT-GET , comunque puoi installare anke a mano , non ti ruba molto tempo.

Già molti programmi hanno quel file di informazione già fatto , ma se per caso non c'è un prog che ti interessa puoi crearlo tu in pochi secondi , oppure modificarne uno esistente per installare un versione diversa di un programma.

Ciao

krokus

21-10-2003, 23:37

Originariamente inviato da mjordan
Quell'opzione attiva semplicemente il giusto flag "--march=xxx" del compilatore GCC. Non è indispensabile ma ti da un'ottimizzazione migliore, + adatta al tuo processore. Chi invece dice che nota "miglioramenti" in termini di velocità mente. I miglioramenti sono sicuramente "computazionalmente evidenti" ma non a tal punto da essere evidenziati "a occhio".

Ciao.

Beh, quando dico miglioramenti, intendo dire che in generale il sistema sembra rispondere meglio, specialmente quando compilo qualcosa in SMP.....
...e poi scusate, ma se un utente non se ne accorge MAI, allora a che 'avolo serve??

mjordan

23-10-2003, 08:29

Originariamente inviato da krokus
Beh, quando dico miglioramenti, intendo dire che in generale il sistema sembra rispondere meglio, specialmente quando compilo qualcosa in SMP.....

Si va bhè, ok :rolleyes:

...e poi scusate, ma se un utente non se ne accorge MAI, allora a che 'avolo serve??

Serve che migliora l'esecuzione dei programmi. Un programma scientifico che calcola milioni di iterazioni verrà eseguito qualche secondo prima in un tempo complessivo di venti secondi (per esempio, si pensi a super-pi sotto Windows). Più l'elaborazione è lunga è piu si nota l'efficienza. Ma si nota su tempi di elaborazione lunga, dove su un calcolo di 45 minuti risparmi 3 o 4 minuti. Non su programmi la cui esecuzione è guidata dagli eventi come un programma ad interfaccia o un comando di console che esegue un paio di azioni nell'esatto istante che l'hai avviato. Quindi, per favore, non fare disinformazione. ;) E soprattutto non autoconvincerti di cose che non sono vere.

krokus

23-10-2003, 09:03

[QUOTE]Originariamente inviato da mjordan
Si va bhè, ok :rolleyes:

Vabbè, dico cavolate.
Ma che ne sai di quello che ci faccio io?
Sono un povero utonto e quindi non ho il diritto di accorgermi se il mio kernel va meglio?
:mad:

mjordan

23-10-2003, 09:11

Non sei un utonto, sei un utente con un cervello umano che non avverte i millisecondi di differenza.

krokus

23-10-2003, 13:13

Originariamente inviato da mjordan
Non sei un utonto, sei un utente con un cervello umano che non avverte i millisecondi di differenza.

Allora torniamo al punto di prima: se il vantaggio è infinitesimo, perchè esistono le ottimizzazioni?
Ho visto molti lamentarsi del fatto che Windows ha un kernel generico.....sì, ma se così stanno le cose, perchè si sente l'esigenza di kernel ottimizzati per un processore particolare?

NA01

23-10-2003, 13:19

propongo la sfidona!
i risultati di un kernel copilato per 386 e quello per un k7 (sempre che abbiate un k7) e poi un confronto su un qualunque programma (glxgears ad esempio) :D

io non ne ho voglia.....
se volete fatelo voi :D :D :D

PS: io miglioramenti ne ho sempre notati (sono arrivato a 2500fps partendo da 1800) ma prima di ricompilare il kernel ho sempre tolto miliardi di opzioni, quindi non sò se è merito dell'ottimizzazione....
ciaaaaaaaaaaaaa

lovaz

23-10-2003, 13:21

Ovviamente bisognerebbe farlo con le stesse opzioni del kernel, a parte il processore.
Chi ha voglia di smanettare si faccia avanti :D

AnonimoVeneziano

23-10-2003, 13:21

Originariamente inviato da NA01
propongo la sfidona!
i risultati di un kernel copilato per 386 e quello per un k7 (sempre che abbiate un k7) e poi un confronto su un qualunque programma (glxgears ad esempio) :D

io non ne ho voglia.....
se volete fatelo voi :D :D :D

PS: io miglioramenti ne ho sempre notati (sono arrivato a 2500fps partendo da 1800) ma prima di ricompilare il kernel ho sempre tolto miliardi di opzioni, quindi non sò se è merito dell'ottimizzazione....
ciaaaaaaaaaaaaa

Penso che GLXGEARs sia proprio l'esempio sbagliato , soprattutto se si usa l'accellerazione 3d :D

Ciao

NA01

23-10-2003, 13:25

bhè, è l'unico che conosco...
cmq te lo ho detto, togliendo supporto a tutto e lasciando solo l'indispensabile per far partire il pc e farlo collegare (nemmeno le usb, le parallele ecc) ho guadagnato 700 fps 8-)
sono tanti perchè sia un caso.
poi che ci possa essere di meglio non lo mettoin dbbio, solo che non conosco programmi per testare il sistema (forse una bella compressione video sarebbe già meglio)!

cia

GhePeU

23-10-2003, 15:53

Originariamente inviato da krokus
Allora torniamo al punto di prima: se il vantaggio è infinitesimo, perchè esistono le ottimizzazioni?
Ho visto molti lamentarsi del fatto che Windows ha un kernel generico.....sì, ma se così stanno le cose, perchè si sente l'esigenza di kernel ottimizzati per un processore particolare?

te lo hanno scritto!

per migliorare le prestazioni sui lunghi tempi

mjordan

23-10-2003, 21:28

Originariamente inviato da krokus
Allora torniamo al punto di prima: se il vantaggio è infinitesimo, perchè esistono le ottimizzazioni?
Ho visto molti lamentarsi del fatto che Windows ha un kernel generico.....sì, ma se così stanno le cose, perchè si sente l'esigenza di kernel ottimizzati per un processore particolare?

Ascolta se hai una preparazione almeno infinitesima di sistemi operativi, ne continuiamo a parlare, altrimenti trust me ...

pinball

23-10-2003, 21:39

Originariamente inviato da mjordan
Ascolta se hai una preparazione almeno infinitesima di sistemi operativi, ne continuiamo a parlare, altrimenti trust me ...

:eek:

:ave:

:tapiro:

:sofico:

krokus

23-10-2003, 22:40

Originariamente inviato da mjordan
Ascolta se hai una preparazione almeno infinitesima di sistemi operativi, ne continuiamo a parlare, altrimenti trust me ...

Visto che qui si mette in dubbio la mia persona, lascio perdere perchè sono un galantuomo.

krokus

23-10-2003, 22:43

Originariamente inviato da GhePeU
te lo hanno scritto!

per migliorare le prestazioni sui lunghi tempi

E che c@@zz, e io cosa ho affermato di fare? Ho forse detto il pc va più veloce in internet? Ho il diritto di fare calcoli su tempi lunghi e di vedere 'ste benedette differenze O NO???
:mad:

mjordan

27-10-2003, 17:08

Nessuno metteva in dubbio la tua persona. Se ti è risultato questo, ti chiedo scusa fin da ora.

krokus

06-11-2003, 13:22

:)
A posto!

Never

06-11-2003, 15:54

che dite ricompilando il kernel avrò dei giovamenti nella creazione dei SVCD? con transcode per le due torri ieri ho impiegato circa 8 ore, se guadagnassi un'oretta sarebbe già un ottimo risultato... potrei farlo anche tipo test se vi interessa...
dimenticavo, ho mdk 9.2 su P4 kernel 2.4.22-21mdk non ricompilato

mjordan

07-11-2003, 06:49

Se ricompilando un kernel si potesse guadagnare un'oretta non avremmo migliaia di persone in tutto il mondo a fare ricerca sui compilatori e i sistemi operativi. :D :D :sofico:

Never

07-11-2003, 06:53

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

0=zero

:sofico:

è stata una scusa per ricompilare il kernel :D

mjordan

07-11-2003, 07:00

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

07-11-2003, 07:08

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

0=zero

:sofico:

è stata una scusa per ricompilare il kernel :D

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

07-11-2003, 09:27

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

07-11-2003, 09:35

Addirittura didattico :D

Jøhñ Ðøë

07-11-2003, 10:07

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

07-11-2003, 11:55

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

Jøhñ Ðøë

07-11-2003, 19:18

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

Ciauz

Ikitt_Claw

07-11-2003, 20:13

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. :yeah:

Never

07-11-2003, 23:26

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

un po' più di info???

Ikitt_Claw

08-11-2003, 09:34

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

08-11-2003, 09:48

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

Ciauz

Hai letto tutti i post precedenti che ho fatto? :rolleyes:

Never

08-11-2003, 09:54

[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

09-11-2003, 05:25

Originariamente inviato da mjordan
Addirittura didattico :D

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!:O

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?