Newsgroup: it.comp.os.linux.debian
Titolo: Pacchetti ottimizzati per CPU

E' un discorso che ho gia' affrontato tempo fa in altra sede ma ora mi sono 
sorte nuove domande.
In pratica la domanda era: perche' non esistono pacchetti Debian ottimizzati 
per CPU?
La risposta e' stata che ci sono gia' tante architetture supportate e 
sarebbe troppo oneroso mantenere una versione di ciascun pacchetto per 
generic 386 e 586, 686, P4, Athlon, etc.: in molti casi il guadagno in 
prestazioni non sarebbe sufficiente a giustificare lo sforzo e i pochi 
pacchetti per i quali ne valga la pena sono gia' disponibili con diverse 
ottimizzazioni (che io sappia solo kernel e openssl). E poi se proprio ci 
tieni puoi sempre ricompilarteli da te.
La risposta e' piu' che ragionevole se non fosse per il fatto che mi sembra 
stupido che ciascuno perda tempo e risorse a ricompilarsi i pacchetti quando 
il risultato sarebbe uguale per tutti quindi mi domando:
- visto che i pacchetti di una "stable" non sono poi cosi' "dinamici" 
sarebbe ipotizzabile la realizzazione di un archivio di questi pacchetti 
(magari parallelo a quello ufficiale) gia' ottimizzati "generic 686"?
- i pacchetti ricompilati in questo modo sarebbero equivalenti a quelli 
"ufficiali" dal punto di vista della sicurezza o sarebbero soggetti a 
vulnerabilita' diverse? Se fossero equivalenti si potrebbe tollerare un 
ritardo nell'aggiornamento delle versioni ottimizzate ricorrendo alla 
versione "generic 386" aggiornata disponibile nell'archivio security 
ufficiale.
Che ne pensate?
Per chi si chiedesse quanto si guadagna a compilare tutto per 686, per quel 
che puo' valere posso dirvi che non avendo dati al riguardo a portata di 
mano ho fatto una prova empirica raffrontando sulla stessa macchina il tempo 
per la compilazione (eseguita a runlevel 1) dello stesso kernel tree su 
Archlinux e Sarge con kernel 686: le differenza e' stata del 10-15% (misura 
fatta dopo una prima compilazione "di riscaldamento" e conseguente make 
clean). Niente di trascendentale, pero'...
Alessandro.

 clean). Niente di trascendentale, pero'...
Io ho compilato mencoder e avidemux (con tutto quello da cui dipendono,
comprese libjpeg e libpng) per AthlonXP. Rispetto ai pacchetti debian
386 e marillat 586, ho notato un incremento di prestazioni inferiore al
5% in encoding.
Ricompilando bzip2 avevo notato addirittura un rallentamento.
Ripeto: per me la strada migliore e` abbandonare 386 e 486 che sono
ormai inutilizzabili, con sarge, e compilare tutto per 586. Non so se
gia` lo facciano.
Bye.

 clean). Niente di trascendentale, pero'...
Il test andrebbe fatto quanto meno sullo stesso tipo di installazione:
non so come hai configurato e cosa hai installato su archlinux, ma
presenze (o meno) di demoni, e altre variabili puo` inficiare di molto
questo test.
Se hai davvero tempo e voglia per un test meno "a braccio", potresti
provare a creare la stessa debian, ma ricompilata e ottimizzata con
apt-build.
Ad ogni buon conto, chi ci ha provato, sostiene che l'incremento e`
talmente risibile, che non vale la pena sovraccaricare i builder per
questo.
Per altro il concetto "solo per stable" e` contorto. I pacchetti non
nascono in stable. Non escludo, inoltre, con un aumento di
ottimizzazione, un florilegio di FTBFS, con quello che ne consegue.
Fondamentalmente, e` poco piu` che una malinconia, l'aggravio di lavoro
e per le macchine e per gli sviluppatori e maintainer pare poco
giustificato, a fronte dei benefici pressoche` nulli. Aggiungi inoltre,
che il rischio di dover reinstallare in caso di mobo bruciata diventa
molto alto - cosa che e` abbastanza poco bella su un sistema come linux,
che ti permette di sfilare un hd da una macchina e fare boot su
tutt'altra con pocchissime (o addirittura nulle) modifiche.
A me e` gia` successo di trovarmi in una situazione del genere.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
The Internet is full. Go away.

 A me e` gia` successo di trovarmi in una situazione del genere.
Anche a me.
Alessandro.

 prestazioni inferiore al 5% in encoding.
E le libc? Ad occhio mi aspetterei molto da una loro orttimizzazione (magari 
mi sbaglio).
Alessandro.

 FTBFS? Questa mi manca.
Failed To Build From Source, che e` uno dei bachi piu` bruttini che
possa fare un maintainer (capita, eh).
Di solito capita per qualche errore di Build-Depends. Qui inizierebbero
a capitare anche per errori di codice, o codice non nato per essere
ottimizzato a qualcosa di diverso da O2, ecc.
Visto che il codice, tipicamente non lo scrive il maintainer, la
procedura si allunga, si dilata.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Be afraid if you see a programmer with a screwdriver.

 ma le distro ottimizzate sono una stretta minoranza.
AFAIK RedHat Mandrake e Suse sono ottimizzate pentium.
Alessandro.

 procedura si allunga, si dilata.
In caso di fallimento della compilazione ottimizzata si potrebbe sempre 
ricorrere a quella non ottimizzata. Non sono cosi' integralista :-)
Alessandro.

 ricorrere a quella non ottimizzata. Non sono cosi' integralista :-)
Non e` proprio questo il problema, altrimenti gli FTBFS non
esisterebbero. Per diversi motivi, io potrei riuscire a compilare (e
fare upload) e tu no. E tu, correttamente, segnaleresti il bug. E` ovvio
che se l'ottimizzazione non mi permettesse di compilare, nemmeno potrei
uploadare il binario. Va da se che nel caso, si riempe la wishlist con
richieste tipo "perche` il pacchetto x, non viene ottimizzato come gli
altri?".
Cmq, questa e` _uno_ dei side-effect di una compilazione ottimizzata,
non "il" side effect.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Research is what I'm doing when I don't know what I'm doing.

 le conseguenze sulla sicurezza e stabilita' del risultato.
Premetto che non sono un C/C++ coder, ma credo che la cosa non sia cosi`
"irrilevante". Se ottimizzi un pacchetto che dipende da libc, suppongo
tu debba avere libc ottimizzata, o rischiare comportamenti poco
predicibili. Ecco che basta una libreria non ottimizzata/ottimizzabile a
far cascare tutto il gioco, o a renderlo quanto meno confuso.
Per altro, ottimizzazioni superiori a -O2 rischiano di rendere il
software abbastanza instabile (o almeno, cosi dice la docu), e
inferiori, non sono praticamente delle ottimizzazioni. Inoltre, ho
diversi dubbi che tanti software compilino a -O3 (ma qui, vado a
sensazione).
Le personalizzazioni "per processore", non sono/sembrano cosi` generiche
visto che sono espresse tutte le classi di pentium (da mmx, a p4,
passando per tutte le versioni, e perche` no prescott, athalon, winchip
e c3), per rimanere solo sulla famiglia i386.
Morale, piu` che un repository globale (con tutto quello che ne
consegue), sembra molto piu` utile ed efficace un programma come
apt-build che, en passant, permette di costruire un repository locale
con i pacchetti ricompilati come pare a te (e quelli che pare a te).
Per altro, e` in sarge, io ti consiglierei di darci un occhiata.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
One man's constant is another man's variable.


Pensavo che fosse possibile una gestione piu' lasca: se esiste il pacchetto 
ottimizzato bene, se non c'e' o non e' aggiornato si ricorre a quello non 
ottimizzato. Ad occhio mi sembra che possa essere fattibile ma non conosco 
bene il meccanismo di gestione dei pacchetti e comunque non saprei valutarne 
le conseguenze sulla sicurezza e stabilita' del risultato.
Alessandro.

 Per altro, e` in sarge, io ti consiglierei di darci un occhiata.
Ho provato a ricompilare libc6 ma mi da' qualche problema (dice che non 
trova tutti i sorgenti). Se no in passato avevevo usato anche dpkg, provero' 
anche con quello.
Alessandro.