il paradosso di absinthe (che egocentrico che sono :)

[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?

[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

[StormyMonday]

Sembra una catena di S. Antonio...

[Sawk]

parli come un gentooista : ))))))))))))))

[samiel]

L'ora è troppo tarda
e il filosofo riposa....

M.

[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

[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.

[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.

[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.

[absinthe]

è 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 è?

[useless]

vi faccio un esempio pratico, sperando che chiarisca le idee:
mettiamo che un compilatore si trovi a dover compilare

Codice: Seleziona tutto

i = 0;

supponiamo che gcc, quando produce codice "generico" (= x 486 col compilatore di default slackware) traduca l'istruzione precedente con:

Codice: Seleziona tutto

mov ax, 0
mov [si], ax

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:

Codice: Seleziona tutto

xor ax, ax
mov [si], ax

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.

[gohanz]

vi faccio un esempio pratico, sperando che chiarisca le idee:
mettiamo che un compilatore si trovi a dover compilare

Codice: Seleziona tutto

i = 0;

supponiamo che gcc, quando produce codice "generico" (= x 486 col compilatore di default slackware) traduca l'istruzione precedente con:

Codice: Seleziona tutto

mov ax, 0
mov [si], ax

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:

Codice: Seleziona tutto

xor ax, ax
mov [si], ax

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?

[absinthe]

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.

[epd20]

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