Pagina 1 di 1
il paradosso di absinthe (che egocentrico che sono :)
Inviato: ven 9 set 2005, 17:37
da absinthe
dunque dunque,
ho bisogno di un chiarimento perchè l'altra sera mi sono incartato...
tutti sanno (lo so pure io!) che se uno vuole ottimizzare un pacchetto per la propria macchina è bene che se lo ricompili usando il proprio tipo di processore come target. fin qui tutto ok.
la cosa atroce che ho scoperto è che in realtà per migliorare ancora di più l'ottimizzazione occorrerebbe ricompilare prima tutta la toolchain..
orbene se questo è vero: per ricompilare la toolchain devo avere una toolchain. ad esempio in slack mi pare che questa sia ottimizzata per 486.
ora la toolchain non è altro che una serie di pacchetti a sua volta... indi per averla davvero ottimizzata la dovrei compilare con una toolchain ricompilata e ottimizzata a sua volta...
cioè:
per ottimizzare davvero un pacchetto avrei bisogno di una toolchain ottimizzata compilata con una toolchain ottimizzata compilata con...
ovvero:
"per compilare una toolchain ottimizzata devo già avere tale toolchain"
vi prego di chiarirmi dove sta la fregatura altrimenti pretendo il mezzo busto (fate voi quale: va bena anche la parte di sotto...)
ciaux,
M.
PS: non è che per caso gli "effetti parassiti" di una ottimizzazione realizzata con toolchains non ottimizzate vanno via via scomparendo?, cioè se compilo una toolchain con una toolchain non ottimizzata il pacchetto prodotto con tale toolchain ottimizzata se ne frega della prima toolchain?
PPS: non è che sta storia della ricompilazione della toolchain è una bufala?
Inviato: ven 9 set 2005, 17:50
da l1q1d
Considerando che se la teoria che tu auspichi fosse giusta nn ci sarebbe ottimizzazione allora per esclusione della prima ipotesi rimane solo la seconda opzione ovvero:
La toolchain si ottimizza tramite i parametri passati dall'utente per cui dopo essere stata compilata su una macchina ottimizzata questa aggiorata con la nuova toolchain sarà ottimizzata.
Sembra quasi filosofia per cui aspetto il commento di Samiel
Inviato: ven 9 set 2005, 22:37
da StormyMonday
Sembra una catena di S. Antonio...
Inviato: sab 10 set 2005, 1:52
da Sawk
parli come un gentooista : ))))))))))))))
Inviato: sab 10 set 2005, 1:58
da samiel
L'ora è troppo tarda
e il filosofo riposa....
M.
Inviato: sab 10 set 2005, 13:38
da marco79
Non cio' capito molto.... ma mi sa che e' l'idea di gentoo ti compili tutto il sistema e in soli 2 giorni hai installato un sistema ottimizzato in tutto

Inviato: sab 10 set 2005, 18:23
da absinthe
per la cronaca...
io uso i pacchetti di default di slack per i486

)))
è che riflettendo su sta storia dell'ottimizzazione mi era venuto in mente che forse nella storiella di ottenere la performance spettacolare/strabiliante/perfetta qualcosa che non tornava poteva esserci.
non so come funziona al suo interno un assembler o un compiler (intendo in termini quantitativi, qualitativamente il processo lo conosco) perciò non so se dico una cavolata o no !
M.
Inviato: dom 11 set 2005, 1:57
da gerardo_sl
vi prego di chiarirmi dove sta la fregatura altrimenti pretendo il mezzo busto (fate voi quale: va bena anche la parte di sotto...)
Dovresti determinare l'intorno d'errore della CPU.
Intuitivamente: la successione delle compilazioni potrebbe restituire una curva che tenda
assintoticamente a tale valore, quindi, da un certo punto in poi, il procedimento perderebbe significato.
Praticamente: tra i vari parametri ti consiglio di mettere anche il punto di fusione del processore.
Conseguenze:
1)Gentoo diventerebbe osbsoleta.
2)"Diario di un hacker" non farebbe ridere più nessuno.
Inviato: lun 12 set 2005, 2:06
da useless
è sbagliato pensare che una toolchain compilata ottimizzata x una certa architettura produca binari + ottimizzati di un'altra compilata senza ottimizzazione. al max li può produrre + velocemente, ma i prodotti sono esattamente identici.
Inviato: lun 12 set 2005, 10:52
da absinthe
useless ha scritto:è sbagliato pensare che una toolchain compilata ottimizzata x una certa architettura produca binari + ottimizzati di un'altra compilata senza ottimizzazione. al max li può produrre + velocemente, ma i prodotti sono esattamente identici.
ah. eccoci!!! dunque era una bufala! semplicemente va un pò + veloce a compilare...
thanx!
M.
PS: diario di un hacker che roba è?
Inviato: lun 12 set 2005, 11:47
da useless
vi faccio un esempio pratico, sperando che chiarisca le idee:
mettiamo che un compilatore si trovi a dover compilare
supponiamo che gcc, quando produce codice "generico" (= x 486 col compilatore di default slackware) traduca l'istruzione precedente con:
supponiamo ora che, sugli athlon xp, l'azzeramento di un registro sia + rapido facendo uno xor +ttosto che una mov (xor richiede 3 cicli di clock, mov 5, ad esempio). in questo caso, attivando le ottimizzazioni x athlon xp, gcc produrrà il seguente codice:
questo è il tipo di ottimizzazioni che vengono fatte. il codice generato è solo funzione dell'architettura target e delle ottimizzazioni selezionate. se il compilatore è stato ottimizzato, allora quando lui dovrà azzerare una variabile farà una xor +ttosto che una mov, ma il prodotto è lo stesso.
Inviato: lun 12 set 2005, 12:21
da gohanz
useless ha scritto:vi faccio un esempio pratico, sperando che chiarisca le idee:
mettiamo che un compilatore si trovi a dover compilare
supponiamo che gcc, quando produce codice "generico" (= x 486 col compilatore di default slackware) traduca l'istruzione precedente con:
supponiamo ora che, sugli athlon xp, l'azzeramento di un registro sia + rapido facendo uno xor +ttosto che una mov (xor richiede 3 cicli di clock, mov 5, ad esempio). in questo caso, attivando le ottimizzazioni x athlon xp, gcc produrrà il seguente codice:
questo è il tipo di ottimizzazioni che vengono fatte. il codice generato è solo funzione dell'architettura target e delle ottimizzazioni selezionate. se il compilatore è stato ottimizzato, allora quando lui dovrà azzerare una variabile farà una xor +ttosto che una mov, ma il prodotto è lo stesso.
Semplice no?

Inviato: lun 12 set 2005, 12:34
da absinthe
useless ha scritto:
questo è il tipo di ottimizzazioni che vengono fatte. il codice generato è solo funzione dell'architettura target e delle ottimizzazioni selezionate. se il compilatore è stato ottimizzato, allora quando lui dovrà azzerare una variabile farà una xor +ttosto che una mov, ma il prodotto è lo stesso.
si effettivamente passa al codice macchina del target... chi se ne frega di come è stato compilato lui... ok... tutto chiaro!
me lo avevano detto che l'assembly mi faceva bene (un pò come gli spinaci) però non ho seguito il consiglio di studiarlo :P
M.
Inviato: mar 13 set 2005, 12:39
da epd20
absinthe ha scritto:
me lo avevano detto che l'assembly mi faceva bene (un pò come gli spinaci) però non ho seguito il consiglio di studiarlo :P
M.
Bufala anche questa!!! Eh sì, gli spinaci non hanno tutte le proprietà che le mamme ci hanno detto...
vedi
http://www.attivissimo.net/antibufala/s ... pinaci.htm
