GCC 4.0.0 --> Upgrade da 3.4.x <--

[sblantipodi]

Salve a tutti.
Mi domandavo se qualcuno ha effettuato l'upgrade su una distribuzione Linux basata sulla vecchia versione 3.4.x
Ho ricompilato la 4.0.0 dai sorgenti e l'ho installato in una directory ad hoc. Visto che sono 325MB e rotti di installazione (C, C++ e Java frontend) vorrei sovrascrivere la vecchia versione in /usr
La mia paura e' che le applicazioni linkate alla libgcc_s.so e libstdc++.so.6 smettano di funzionare per qualche problema.

C'e' qualcuno che ha installato questo compilatore in /usr?
Problemi? Non mi risulta che la libreria libstdc++ fornita con questa versione sia incompatibile al livello di ABI con la versione del 3.4.3, ma non si sa mai.

Thanks.

[ilsensine]

Originariamente inviato da sblantipodi

La mia paura e' che le applicazioni linkate alla libgcc_s.so e libstdc++.so.6 smettano di funzionare per qualche problema.

Potrebbe darsi. Ti consiglio di tenerlo in una dir a parte, e linkare con -Wl,--rpath=/path/alle/nuove/librerie
E' molto più affidabile.

[ilsensine]

Originariamente inviato da sblantipodi

Salve a tutti.
Non mi risulta che la libreria libstdc++ fornita con questa versione sia incompatibile al livello di ABI con la versione del 3.4.3, ma non si sa mai.

Forse no, ma rompere la compatibilità tra diverse versioni delle libstdc++ pare uno degli hobby degli sviluppatori del gcc. Non a caso ora queste librerie sono distribuite con il gcc, non separatamente come era un tempo.

[mjordan]

Scusatemi, il thread e' mio. Ho postato erroneamente con l'account di mio fratello che non effettua mai il logout quando usa la mia macchina...

X ilsensine: Si sto gia' facendo cosi' ma siccome sono molto a corto di spazio quei 325MB mi farebbero molto comodo. Ho notato che la libreria Java (libgcj) e' praticamente raddoppiata ma quella non e' un problema, mentre la libstdc++ con la versione 3.4.3 del compilatore si chiama "libstdc++.so.6.0.3" mentre con la versione 4.0.0 del compilatore e' marchiata "libstdc++.so.6.0.4" ... Non mi fa presupporre a una incompatibilita' sorgente e binaria (per il C++).
Per quanto riguarda libgcc_s non c'e' un modo per dedurre qualcosa, a parte la differenza di 52KB fra le due

Mi domando: Esiste una pagina sul sito di GCC che elenchi le incompatibilita' con la versione precedente? La pagina sulle "New features" elenca solo incompatibilita' a livello di flag deprecati o estensioni rimosse. Ma per uanto riguarda la compatibilita' binaria?

[sblantipodi]

Originariamente inviato da mjordan

Scusatemi, il thread e' mio. Ho postato erroneamente con l'account di mio fratello che non effettua mai il logout quando usa la mia macchina...

X ilsensine: Si sto gia' facendo cosi' ma siccome sono molto a corto di spazio quei 325MB mi farebbero molto comodo. Ho notato che la libreria Java (libgcj) e' praticamente raddoppiata ma quella non e' un problema, mentre la libstdc++ con la versione 3.4.3 del compilatore si chiama "libstdc++.so.6.0.3" mentre con la versione 4.0.0 del compilatore e' marchiata "libstdc++.so.6.0.4" ... Non mi fa presupporre a una incompatibilita' sorgente e binaria (per il C++).
Per quanto riguarda libgcc_s non c'e' un modo per dedurre qualcosa, a parte la differenza di 52KB fra le due

Mi domando: Esiste una pagina sul sito di GCC che elenchi le incompatibilita' con la versione precedente? La pagina sulle "New features" elenca solo incompatibilita' a livello di flag deprecati o estensioni rimosse. Ma per uanto riguarda la compatibilita' binaria?

frate' non ti lamentare

[mjordan]

Originariamente inviato da sblantipodi

frate' non ti lamentare

Perche' non installi il 4.0.0 sul 3.4.3 e posti la tua esperienza?
Io sono sicuro al 98% che non provoca danni. Toglimi il 2% di insicurezza

[sblantipodi]

Originariamente inviato da mjordan

Perche' non installi il 4.0.0 sul 3.4.3 e posti la tua esperienza?
Io sono sicuro al 98% che non provoca danni. Toglimi il 2% di insicurezza

facciamo una cosa...
prova tu dopo mi racconti

[mjordan]

Originariamente inviato da sblantipodi

facciamo una cosa...
prova tu dopo mi racconti

Ok. Dopo un backup di vera fortuna e una semi nottata passata ad aspettare la terminazione della compilazione di questo maledetto compilatore, superata la paura iniziale del "make install" annuncio con orgoglio che GCC 4.0.0 puo' essere installato tranquillamente in /usr sovrascrivendo la vecchia versione 3.4.x senza avere alcun problema con la risoluzione dei simboli all'interno delle librerie libgcc_s.so.1 e libstdc++.so.6
Anche se le librerie a corredo sono perfettamente compatibili a livello binario e sorgente con le precedenti non mancano dei problemi, che pero' sono di poco conto:

1) Il kernel 2.6.11 non compila il modulo i2c-core.c avendo dei problemi sintattici in i2c.h (speriamo che si risolve con il 2.6.12, del resto il kernel compila liscio e senza problemi, solo quando si decide di compilare i moduli si verifica questo problema)
2) Quando si usano le istruzioni SSE2 il compilatore genera codice incorretto (non so pero' se si verifica solo sulla mia architettura Athlon-XP Mobile). Ho compilato un mio programma OpenGL con il flag "-msse2" e il programma termina con il segnale "Illegal Instruction". Disabilitando tale flag il programma funziona correttamente. Funziona correttamente anche con i flag -march=athlon-xp, -mmmx, -msse e -m3dnow.

Ma visto che tale flag e' praticamente inutilizzato dalla maggior parte dei software il problema non sussiste per adesso.

Direi che l'upgrade vale la pena. Il nuovo tree-ssa e il nuovo linguaggio intermedio GIMPLE riescono a generare un codice ottimizzato da panico. Ho ricompilato Blender per Linux sia con il vecchio compilatore 3.4.3 che con il 4.0.0
La versione 4.0.0 e' risultata molto piu' veloce nei rendering. Un mio rendering che usa HDRI mapping, displacement maps, reflection maps e una full GI con irradiance cache impiega la bellezza di 40 secondi di meno su un rendering time complessivo di circa 4 minuti. Non male per uno swap-over di un compilatore...

Decisamente consigliato.
P.S.: I compile time secondo me non sono aumentati. Molta gente si lamenta dei compile time elevati con la versione 4.0.0. Per quello che ho riscontrato io, il codice C e' rimasto praticamente invariato mentre in alcuni casi mi e' sembrato di vedere un incremento della VELOCITA' nella compilazione di codice C++.
In ogni caso non vedo l'ora che esce GCC 4.1.0, che implementera' un nuovo parser C/C++ scritto a mano che sostituira' l'attuale generato da Bison che sara' molto piu' veloce.

[VICIUS]

Originariamente inviato da mjordan

2) Quando si usano le istruzioni SSE2 il compilatore genera codice incorretto (non so pero' se si verifica solo sulla mia architettura Athlon-XP Mobile). Ho compilato un mio programma OpenGL con il flag "-msse2" e il programma termina con il segnale "Illegal Instruction". Disabilitando tale flag il programma funziona correttamente. Funziona correttamente anche con i flag -march=athlon-xp, -mmmx, -msse e -m3dnow.

Ma visto che tale flag e' praticamente inutilizzato dalla maggior parte dei software il problema non sussiste per adesso.

Questo perchè gli xp hanno supporto solo per le sse. Le see2 sono state introdotte negli athlon 64 e le sse3 dei prescot nella revision E degli athlon di prossima uscita.

Originariamente inviato da mjordan

Direi che l'upgrade vale la pena. Il nuovo tree-ssa e il nuovo linguaggio intermedio GIMPLE riescono a generare un codice ottimizzato da panico. Ho ricompilato Blender per Linux sia con il vecchio compilatore 3.4.3 che con il 4.0.0
La versione 4.0.0 e' risultata molto piu' veloce nei rendering. Un mio rendering che usa HDRI mapping, displacement maps, reflection maps e una full GI con irradiance cache impiega la bellezza di 40 secondi di meno su un rendering time complessivo di circa 4 minuti. Non male per uno swap-over di un compilatore...

Decisamente consigliato.
P.S.: I compile time secondo me non sono aumentati. Molta gente si lamenta dei compile time elevati con la versione 4.0.0. Per quello che ho riscontrato io, il codice C e' rimasto praticamente invariato mentre in alcuni casi mi e' sembrato di vedere un incremento della VELOCITA' nella compilazione di codice C++.
In ogni caso non vedo l'ora che esce GCC 4.1.0, che implementera' un nuovo parser C/C++ scritto a mano che sostituira' l'attuale generato da Bison che sara' molto piu' veloce.

Io ho fatto un po di benchmerk di prova qualche giorno fa è ho ottenuto dei risultati poco incoraggianti. prova a vedere qui http://forum.hwupgrade.it/showthread.php?t=927384 . Spero anche io in un 4.1.0 migliore.

ciao

[mjordan]

Originariamente inviato da VICIUS

Questo perchè gli xp hanno supporto solo per le sse. Le see2 sono state introdotte negli athlon 64 e le sse3 dei prescot nella revision E degli athlon di prossima uscita.

Mi sono spiegato male. Quello che volevo dire e' che ricevere codice incorretto specificando un flag per un'architettura non supportata dal quel flag e' un'inconsistenza del compilatore. Specificare "-march=athlon-xp" congiuntamente a "-msse2" e' una contraddizione che un compilatore dovrebbe tracciare. Con -msse3 il programma, infatti, sembra ignorare tale flag e gira correttamente, con -msse2, invece, genera un illegal instruction. Sarebbe come voler compilare codice 64 bit su un athlon thunderbird e ricevere una corretta compilazione per poi eseguire il programma e ricevere un messaggio "Instruction set not supported". Se lo slogan d'oro per uno sviluppatore di compilatori e' "Un buon compilatore non crasha mai" bisognerebbe aggiungere "Un buon compilatore non consente controsensi". Se avessi compilato un cross compiler sarei rimasto muto. Ma visto che durante il bootstrap del compilatore, sembra riconoscere appieno la mia architettura generando un automa "Athlon" allora mi si storce il naso.

Io ho fatto un po di benchmerk di prova qualche giorno fa è ho ottenuto dei risultati poco incoraggianti. prova a vedere qui http://forum.hwupgrade.it/showthread.php?t=927384 . Spero anche io in un 4.1.0 migliore.

ciao

Non voglio essere troppo pesante, ma quel benchmark non ha senso per diversi motivi.
Primo fra tutti perche' e' fortemente limitato da un'operazione che coinvolge un forte I/O su disco e quindi non e' la maniera ottimale per testare le performance del exec time di un codice. Lame invece sarebbe un test piu' appropriato. E in secondo luogo perche' non considera i nuovi flag di GCC 4.0.0 che non sono paragonabili a GCC 3.3.x o 3.4.x semplicemente perche' non sono disponibili. Alcuni benchmark seri fatti sugli ultimi snapshot del mainline, evidenziano si un aumento della dimensione del codice generato, ma anche un aumento in media della velocita di esecuzione dei programmi CPU intensive, quantificabile con valori che vanno dal 10 al 12% di incremento (questo con il solo flag -fvisibility, che sulle vecchie versioni non e' utilizzabile).
Inoltre "fare tre test e prendere il risultato piu basso" non e' poi cosi tanto scientifico come metodo. Sarebbe meglio farne 10 e calcolare la media dei risultati per cercare di avere il risultato meno empirico possibile e soprattutto cercando di eliminare i casi fortunati. Resta comunque un metodo down per testare un qualcosa di cosi' complesso come un compilatore.
Come si puo' leggere nelle pagine del sito di GCC:

The -fvisibility-inlines-hidden option has been added which marks all inlineable functions as having hidden ELF visibility, thus removing their symbol and typeinfo from the exported symbol table of the output ELF binary. Using this option can reduce the exported symbol count of template-heavy code by up to 40% with no code change at all, thus notably improving link and load times for the binary as well as a reduction in size of up to 10%. Also, check the new -fvisibility option.

Un buon link per quato riguarda le comparazioni di diverse versioni di GCC e' il seguente:
http://www.coyotegulch.com/reviews/l...ilers/#results

anche se dev'essere aggiornato come risultato perche' prende in considerazione dei vecchi snapshot di GCC 4.0.0 quando il merge con il tree-ssa era ancora agli albori.

Per quanto riguarda comparazioni serie, il benchmark ufficiale usato anche dagli stessi sviluppatori GCC rimane sempre e solo CSiBE:
http://www.inf.u-szeged.hu/csibe/

Inoltre non bisogna dimenticare che GCC 4.0.0 porta con se piu' "un'evoluzione" che non una "rivoluzione". L'infrastruttura tree-SSA e' stata messa li ma senza implementare ancora quelle ottimizzazioni che sono possibili ORA grazie ad essa. In definitiva le vere migliorie si vedranno con la serie 4.x.x | x > 0
Per adesso GCC 4.0.0 porta solo un grosso sforzo fatto per il merging di tale infrastruttura.
Il tree-SSA (Single Static Assignment) e' un'infrastruttura che consente di rappresentare le caratteristiche di un microprocessore utili ad un compilatore mediante una struttura a grafo. Questo consente di descrivere un'architettura in modo molto astratto senza pero' perdere di definizione nella descrizione. GIMPLE e' un linguaggio intermedio generato grazie al tree-SSA che rimane ancora ad alto livello prima di essere convertito in RTL, il linguaggio intermedio piu' dipendente dalla machina che e' cio' che diventera' codice Assembly nativo dopo un ulteriore passo di ottimizzazione. Tutto questo consentira' di implementare ottimizzazioni che prima erano difficili o impossibili da raggiungere.
In definitiva, io sono molto fiducioso. Gia' cosi', molti degli sviluppatori Blender che stanno sperimentando il nuovo compilatore stanno ottenendo con i nuovi flag incrementi nella velocita' di rendering fino al 12% su raytracing il cui tempo complessivo non va oltre i 10 minuti. Questo non e' affatto sufficiente per dire "GCC 4.0.0 e' migliore dei precedenti", intendiamoci, ma e' un buon inizio. SI perche' GCC 4.0.0 e' solo un inizio di un'evoluzione, un po come lo e' il PCI Express per le schede grafiche adesso. :P Inoltre un benchmark serio dovrebbe considerare anche come sono state compilate le librerie usate sotto dai programmi. E' quasi inutile compilare un programma con il 4.0.0 e usare sotto la glibc compilata nativamente con il 3.3.x. Questo semplicemente per il fatto che la maggior parte di codice eseguito da un programma coinvolge piu' il codice di libreria che non il codice suo. Anche solo ricompilare la glibc sarebbe una buona cosa. Ma qui' stiamo entrando nel campo delle paranoie da benchmark di scheda grafica. Per me un compile time maggiore di 4 secondi su un tree da 30000 righe di codice non mi dice niente rispetto all'incremento di prestazioni del 12% evidenziato su un rendering da 10 minuti... E, come si dice sempre nel campo dell'informatica ai propri utenti:

Your mileage may vary

[VICIUS]

Originariamente inviato da mjordan

Mi sono spiegato male. Quello che volevo dire e' che ricevere codice incorretto specificando un flag per un'architettura non supportata dal quel flag e' un'inconsistenza del compilatore. Specificare "-march=athlon-xp" congiuntamente a "-msse2" e' una contraddizione che un compilatore dovrebbe tracciare. Con -msse3 il programma, infatti, sembra ignorare tale flag e gira correttamente, con -msse2, invece, genera un illegal instruction. Sarebbe come voler compilare codice 64 bit su un athlon thunderbird e ricevere una corretta compilazione per poi eseguire il programma e ricevere un messaggio "Instruction set not supported". Se lo slogan d'oro per uno sviluppatore di compilatori e' "Un buon compilatore non crasha mai" bisognerebbe aggiungere "Un buon compilatore non consente controsensi". Se avessi compilato un cross compiler sarei rimasto muto. Ma visto che durante il bootstrap del compilatore, sembra riconoscere appieno la mia architettura generando un automa "Athlon" allora mi si storce il naso.

Ecco ora è piu chiaro. Si in effetti gcc dovrebbe intercettare queste inconsistenze pero non possono mica perdere tempo a controllare tutte le varie combinazioni possibili. In fondo chi usa un compilatore a mano passando CFLAGS personalizate si presume abbia un certo livello di "conoscenza" di quello che sta facendo. Il fatto che con sse3 non crasha è probabilmente solo fortuna anche perchè i casi in cui è veramente utile sono mooolto pochi quindi gcc non lo usa praticamente mai.

Originariamente inviato da mjordan

Non voglio essere troppo pesante, ma quel benchmark non ha senso per diversi motivi.
Primo fra tutti perche' e' fortemente limitato da un'operazione che coinvolge un forte I/O su disco e quindi non e' la maniera ottimale per testare le performance del exec time di un codice.

MD2 è un algoritmo di hashing atipico e l'ho scelto apposta perchè, almeno sul mio pc, non è limitato da operazioni di I/O. Si tratta piu che altro di cicli che fanno operazioni xor, or e simili in memoria. Anche facendo il test su tmpfs quindi annullando i tempi di accesso al hd i risultati non sono cambiati di molto, forse c'è un guadagno di 200/300 ms ma non mi sembra niente di eccezionale. Il problema per questo algoritmo è riuscire a paralelizare per bene le operazioni sfruttare al massimo la cache di primo e secondo livello del processore.

Originariamente inviato da mjordan

Lame invece sarebbe un test piu' appropriato. E in secondo luogo perche' non considera i nuovi flag di GCC 4.0.0 che non sono paragonabili a GCC 3.3.x o 3.4.x semplicemente perche' non sono disponibili. Alcuni benchmark seri fatti sugli ultimi snapshot del mainline, evidenziano si un aumento della dimensione del codice generato, ma anche un aumento in media della velocita di esecuzione dei programmi CPU intensive, quantificabile con valori che vanno dal 10 al 12% di incremento (questo con il solo flag -fvisibility, che sulle vecchie versioni non e' utilizzabile).

Che io sappia non ci sono stati grandi cambiamenti di flag che possano influenzare lame a parte -march -> -mtune. Le opzioni -fvisibility-* sono esclusiva di C++ e in C non serve a niente. Da quello che ho capito permette di non esportare alcuni simboli e quindi diminuisce la dimensione del binario su hd minore, quindi meno ram occupata e ad un link run-time minore ma di certo non incremneta le prestazioni del eseguibile.

Originariamente inviato da mjordan

Inoltre "fare tre test e prendere il risultato piu basso" non e' poi cosi tanto scientifico come metodo. Sarebbe meglio farne 10 e calcolare la media dei risultati per cercare di avere il risultato meno empirico possibile e soprattutto cercando di eliminare i casi fortunati. Resta comunque un metodo down per testare un qualcosa di cosi' complesso come un compilatore

Il pc è comunque un sistema deterministico. Prendere il valore migliore è semplicemente prendere il valore piu vicino al valore che sarebbe ottenibile teoricamente senza iterferenze dovute ad altri processi in background e ad interruzioni dovute allo scheduling, fare la media in questo caso rende la misura molto piu sensibile ad errore.

Originariamente inviato da mjordan

Inoltre non bisogna dimenticare che GCC 4.0.0 porta con se piu' "un'evoluzione" che non una "rivoluzione". L'infrastruttura tree-SSA e' stata messa li ma senza implementare ancora quelle ottimizzazioni che sono possibili ORA grazie ad essa. In definitiva le vere migliorie si vedranno con la serie 4.x.x | x > 0 [...]

Sul fatto che gcc 4.0 sia una vera rivoluzione che ha grandissimi margini di miglioramento mi trovi perfettamente d'accordo. Speriamo bene.


ciao

[mjordan]

Originariamente inviato da VICIUS

Ecco ora è piu chiaro. Si in effetti gcc dovrebbe intercettare queste inconsistenze pero non possono mica perdere tempo a controllare tutte le varie combinazioni possibili. In fondo chi usa un compilatore a mano passando CFLAGS personalizate si presume abbia un certo livello di "conoscenza" di quello che sta facendo. Il fatto che con sse3 non crasha è probabilmente solo fortuna anche perchè i casi in cui è veramente utile sono mooolto pochi quindi gcc non lo usa praticamente mai.

Questa e' (scusami) una fesseria. Il software non si progetta mantenendo "casistiche ambigue" solo perche' si perde tempo. Stiamo parlando di un compilatore. Un compilatore deve sempre comportarsi in modo coerente. Il fatto di avere dei parametri utilizzabili con coerenza non significa dire "tanto l'utente che lo usa e' esperto". I flag del compilatore vengono invocati da un Makefile in genere. Supponendo di voler inserire i flag per ottimizzare il codice per un Athlon-64 non significa che devo rompere la compatibilita' del codice generato con un processore inferiore solo perche' supporta una manciata di istruzioni di meno. Inoltre e' il comportamento di default di GCC di mantenere coerenza fra i flag. Quindi questo, molto probabilmente, e' un bug. I flag di GCC definiscono implicitamente altri flag e ne annullano altri ambigui e incompatibili con quel flag.

MD2 è un algoritmo di hashing atipico e l'ho scelto apposta perchè, almeno sul mio pc, non è limitato da operazioni di I/O. Si tratta piu che altro di cicli che fanno operazioni xor, or e simili in memoria. Anche facendo il test su tmpfs quindi annullando i tempi di accesso al hd i risultati non sono cambiati di molto, forse c'è un guadagno di 200/300 ms ma non mi sembra niente di eccezionale. Il problema per questo algoritmo è riuscire a paralelizare per bene le operazioni sfruttare al massimo la cache di primo e secondo livello del processore.

Sorry avevo letto MD5 ( ). Mea culpa. Non conosco tale algoritmo e come si comporta.
In ogni caso, qualunque sia questo algoritmo, deve caricare in memoria un enorme quantita' di dati (il file su cui calcolare l'hashing) e visto che opera bit a bit ogni ciclo xor/or o quello che sia deve attendere il caricamento in memoria del dato da disco prima di operare. Non capisco come fai a dire "non e' limitato da I/O sul mio PC".

Che io sappia non ci sono stati grandi cambiamenti di flag che possano influenzare lame a parte -march -> -mtune. Le opzioni -fvisibility-* sono esclusiva di C++ e in C non serve a niente. Da quello che ho capito permette di non esportare alcuni simboli e quindi diminuisce la dimensione del binario su hd minore, quindi meno ram occupata e ad un link run-time minore ma di certo non incremneta le prestazioni del eseguibile.

Cioe' maggiore velocita' dell'eseguibile. Per exec time non si misura mica solo il codice puro dell'oggetto ma anche tutto cio' che fa il binario prima di entrare in esecuzione. La stessa Mandrake ha affermato di aver ottenuto un tempo di esecuzione minore del 14% avendo compilato KDE con i flags -fvisibility*. Tu stesso hai fatto il test con il comando time. Che include inevitabilmente il tempo di loading dei simboli.

Il pc è comunque un sistema deterministico. Prendere il valore migliore è semplicemente prendere il valore piu vicino al valore che sarebbe ottenibile teoricamente senza iterferenze dovute ad altri processi in background e ad interruzioni dovute allo scheduling, fare la media in questo caso rende la misura molto piu sensibile ad errore.

Teoria interessante. Hai ragione. Dalla parte teorica pero'. Perche' i PC sono macchine reali per fare i conti, mentre le macchine di Turing sono modelli di calcolo da white paper accademico. Prendere una media dei tempi non significa rendere piu' sensibile all'errore. Ma avvicinarsi a risultati reali. In un contesto dove scheduling, processi concorrenti e quant'altro sono inevitabili, prendere quelle casistiche fortunate che li evitino (il piu' possibile) significa introdurre un errore di valutazione. Perche' se GCC 3.3 ha avuto un caso piu' fortunato del 4.0 non significa che sia piu' veloce. Fare una media dei tempi, invece, significa avvicinarsi molto di piu' alla realta nel modo piu' preciso possibile perche' fra tutti valori, la media e' quella dei risultati che si avvicinano al mondo reale. Cosi' come prendere 30 a un esame non significa laurearsi con 110 e lode.

Sul fatto che gcc 4.0 sia una vera rivoluzione che ha grandissimi margini di miglioramento mi trovi perfettamente d'accordo. Speriamo bene.


ciao

Io non attendo altro che un supporto completo a OpenMP. Purtroppo questo e' uno degli svantaggi di GCC rispetto alla concorrenza commerciale...

[VICIUS]

Originariamente inviato da mjordan

Questa e' (scusami) una fesseria. Il software non si progetta mantenendo "casistiche ambigue" solo perche' si perde tempo. Stiamo parlando di un compilatore. Un compilatore deve sempre comportarsi in modo coerente. Il fatto di avere dei parametri utilizzabili con coerenza non significa dire "tanto l'utente che lo usa e' esperto". I flag del compilatore vengono invocati da un Makefile in genere. Supponendo di voler inserire i flag per ottimizzare il codice per un Athlon-64 non significa che devo rompere la compatibilita' del codice generato con un processore inferiore solo perche' supporta una manciata di istruzioni di meno. Inoltre e' il comportamento di default di GCC di mantenere coerenza fra i flag. Quindi questo, molto probabilmente, e' un bug. I flag di GCC definiscono implicitamente altri flag e ne annullano altri ambigui e incompatibili con quel flag.

Se tu dici per esempio a gcc di ottimizare il codice per x86_64 tramite -mtune=yadayada lui prende come base quello. Come puoi pretendere che poi il codice sia eseguibile anche su sistemi inferiori ? Questo vale anche per le altre architetture. Se ottimizzi per pentium 4 il codice non andra mai su un pentium 2 e cosi via. Certo il fatto che se specifichi come target un athlon e poi specifichi l'utilizzo delle sse2/3 e il compilatore genera comunque codice è un po strano. Sarebbe interessante sapere cosa ne pensano i programmatori di gcc e se ne sono mai accorti.

Originariamente inviato da mjordan

Sorry avevo letto MD5 ( ). Mea culpa. Non conosco tale algoritmo e come si comporta.
In ogni caso, qualunque sia questo algoritmo, deve caricare in memoria un enorme quantita' di dati (il file su cui calcolare l'hashing) e visto che opera bit a bit ogni ciclo xor/or o quello che sia deve attendere il caricamento in memoria del dato da disco prima di operare. Non capisco come fai a dire "non e' limitato da I/O sul mio PC".

La versione scritta completamente in C sfrutta il processore al 100% e non macina piu di qualche mbyte per secondo sul mio amd xp1700.

Originariamente inviato da mjordan

Cioe' maggiore velocita' dell'eseguibile. Per exec time non si misura mica solo il codice puro dell'oggetto ma anche tutto cio' che fa il binario prima di entrare in esecuzione. La stessa Mandrake ha affermato di aver ottenuto un tempo di esecuzione minore del 14% avendo compilato KDE con i flags -fvisibility*. Tu stesso hai fatto il test con il comando time. Che include inevitabilmente il tempo di loading dei simboli.

Senza dubbio è un must per progetti come kde. Ma per programmini scritti in C come lame quello switch non ha effetto quindi non avrebbe comunque modificato il valore finale del benchmark.

Originariamente inviato da mjordan

Teoria interessante. Hai ragione. Dalla parte teorica pero'. Perche' i PC sono macchine reali per fare i conti, mentre le macchine di Turing sono modelli di calcolo da white paper accademico. Prendere una media dei tempi non significa rendere piu' sensibile all'errore. Ma avvicinarsi a risultati reali. In un contesto dove scheduling, processi concorrenti e quant'altro sono inevitabili, prendere quelle casistiche fortunate che li evitino (il piu' possibile) significa introdurre un errore di valutazione. Perche' se GCC 3.3 ha avuto un caso piu' fortunato del 4.0 non significa che sia piu' veloce. Fare una media dei tempi, invece, significa avvicinarsi molto di piu' alla realta nel modo piu' preciso possibile perche' fra tutti valori, la media e' quella dei risultati che si avvicinano al mondo reale. Cosi' come prendere 30 a un esame non significa laurearsi con 110 e lode.

In effetti non avevo pensato al fatto che in fondo lo scheduling è praticamente inevitabile. Secondo me tutti e due i metodi sono validi. Pero ora basta matematica applicata che è sempre stata una materia piuttosto disgustosa .

ciao

[mjordan]

Voglio OpenMP