Questa frase, pronunciata però in maniera affermativa, è stata oggetto di discussione qualche tempo fa nell’area Programmazione del forum del nostro sito “madre”, dove un utente tesseva le lodi del compilatore a cui ha dato i natali Richard Stallman.
Non entrerò nel merito di quel thread-valanga (come capita nelle migliori guerre di religione, specialmente quando di mezzo ci sono questioni tecniche), ma ne approfitto per uno spunto di riflessione, che mi trascino già da parecchio tempo, su questo compilatore (o su questa collezione di compilatori, come ormai recita l’acronimo).
Generalmente quattro sono le qualità che servono a discriminare la bontà di un compilatore:
- prestazioni del codice compilato
- dimensione dei binari (siano essi file oggetto o eseguibili)
- velocità di compilazione
- architetture e sistemi operativi supportati
Le priorità non vanno dalla prima all’ultima, ma dipendono strettamente dall’utilizzatore. Quindi se ho messo le prestazioni davanti a tutte, non è perché devono essere il primo metro di paragone. Ad esempio a me normalmente interessa la velocità di compilazione perché influenza direttamente la mia produttività come programmatore; se, quando tutto funziona, voglio ottenere un eseguibile più veloce e/o di dimensione più contenuta per la build finale, sono disposto a perderci un po’ di tempo in più.
La dimensione diventa importante a seconda del target scelto per la distribuzione del prodotto. Può non essere un problema se il veicolo scelto è un disco Blu-Ray, ad esempio, perché lo spazio che è possibile utilizzare si misura nell’ordine delle decine di GB (ma si può saturare anche quello). Diventa critica se il prodotto lo si dovrà scaricare, invece, con su un telefonino tramite connessione WAP che può essere più o meno lenta, gratuita o a pagamento.
Supportare più architetture / piattaforme può essere inutile, un valore aggiunto, o un requisito indispensabile. Anche qui, manco a dirlo, tutto dipende da quello che vogliamo realizzare. Ad esempio, se voglio realizzare un videogioco per PC, molto probabilmente non m’interesserà questa funzionalità, visto che generalmente si sviluppa per Windows e le architetture x86 (che domina) e/o AMD64 (che ne rappresenta il futuro prossimo). Se, invece, il mio target è rappresentato dai telefonini, come minimo sarà indispensabile il supporto agli ARM.
Una quinta voce che non ho menzionato sarebbe l’affidabilità, ma si tratta di una caratteristica che non dovrebbe nemmeno essere in discussione: da un compilatore, al pari di un altro componente estremamente importante quale può essere un filesystem, ci si aspetta che sia solido e produca codice che faccia fede all’originale sorgente per quanto riguarda i calcoli eseguiti; e che, ovviamente, non presenti problemi che non siano riconducibili al sorgente stesso.
Detto ciò, il “miglior” compilatore al mondo non esiste sostanzialmente per due ragioni. La prima, lapalissiana, perché le esigenze di chi lo usa non sono tutte le stesse, come già accennato in precedenza; io posso, e ho, necessità diverse rispetto a un altro programmatore, inoltre possono benissimo variare in base al progetto a cui sto lavorando.
Secondo, è praticamente impossibile conciliare tutte e quattro le qualità; si tratta di un classico problema di ottimizzazione su delle variabili correlate che non può fornire i migliori risultati per tutte. Tanto per fare qualche esempio, se voglio ottenere le migliori prestazioni è chiaro che dovrò obbligatoriamente spendere più tempo a ottimizzare il codice finale, e ciò incide per forza di cose sulla velocità di compilazione. Se, invece, m’interessa contenere la dimensione dell’eseguibile, dovrò rinunciare in parte alle prestazioni perché, ad esempio, non potrò sfruttare un aggressivo inline delle funzioni.
Fornita la risposta al quesito esposto nel titolo, penso sia utile dare qualche spunto per vedere come si comporta GCC rispetto alle variabili elencate, in modo da farsi un’idea e poter decidere, in base a ciò serve a ognuno, se val la pena utilizzarlo oppure cercare uno strumento che “calzi meglio”.
Per quanto riguarda le prestazioni GCC non ha certo brillato. D’altra parte nei primi di anni di vita di un progetto è più importante farlo funzionare correttamente piuttosto che perdere tempo alla sua ottimizzazione; citando una massima di Kent Beck, “Make it work, make it right, make it fast“. Le sue ultime versioni sono sostanzialmente comparabili a Visual Studio C++, anche se non ho trovato confronti con l’ultima versione di quest’ultima (la 2010).
Di seguito riporto una serie di link ordinati temporalmente che mostrano alcuni risultati e il relativo grado di maturità raggiunto:
- Nine Language Performance Round-up: Benchmarking Math & File I/O
- Benchmarking With 64 Bits
- Compiler benchmark
- Intel Beats Up GCC
- Benchmarks Of GCC 4.5.0 Compiler Performance
Ovviamente con questi benchmark non ho la pretesa di giudicare globalmente i risultati dei compilatori testati. Risultano, comunque, abbastanza variegati per tipologia applicativa, e possono essere utili per farsi un’idea. Fermo restando che, in fin dei conti, gli unici confronti utili rimangono quelli fatti con applicazioni relative ai nostri, specifici, interessi.
Dal quadro emergono alcuni punti: il primo, abbastanza scontato, è che il compilatore Intel è risultato essere sempre imbattibile. Il secondo è che i miglioramenti di GCC sono stati notevoli, anche se hanno comportato un lungo periodo (forse un po’ troppo) di sviluppo. Il terzo, ma l’avevo già accennato, è che il confronto con Visual Studio s’è fatto serrato con le ultime versioni (dalla 4.3 in poi).
Il quarto è che, come si vede dall’ultimo link, non sempre si ottengono prestazioni migliori rispetto alle versioni precedenti, a volte con risultati nettamente inferiori; sono, insomma, presenti delle regressioni (come si suol dire in questi casi), che a quanto pare sfuggono agli sviluppatori ufficiali (e a questo punto è lecito dubitare che esistano delle suite test di regressione, come si vedrà più avanti, parlando dei problemi con alcune architetture).
Relativamente alla dimensione degli eseguibili ho trovato poco in giro, anche perché, purtroppo, il metro di paragone prediletto rimane quello delle prestazioni. Di seguito un paio di utili link (qualche informazione appare anche nel precedente link “Benchmarking With 64 Bits“):
- Building Qt Static (and Dynamic) and Making it Small with GCC, Microsoft Visual Studio, and the Intel Compiler
- Enormous increase in DLL object files size in 4.5
Il compilatore Intel genera gli eseguibili di dimensione più elevata, ma questo era anche prevedibile, se consideriamo che nel binario vengono incluse porzioni di codice specifiche (chiamate “code path” in gergo) per un certo numero di suoi processori. GCC genera codice di dimensione inferiore, ma sempre superiore rispetto a Visual Studio.
La nota dolente è rappresentata dal secondo link, che porta a un ticket del bugtrack (non ancora corretto né preso in carico da qualche sviluppatore) del compilatore, che evidenzia un problema della release 4.5, la quale al momento genera eseguibili e/o codice oggetto di dimensione notevolmente aumentata rispetto alle versioni precedenti.
Anche per quanto riguarda i tempi di compilazione si trova poco materiale. Sempre Aaron Giles, nel suo blog, ha scritto un post qualche tempo fa con dei test di build sulla sua nuova (all’epoca) macchina, dove risultano tempi superiori per una build di debug, decisamente elevati per una di release, ma inferiori rispetto alla release altamente ottimizzata di Visual Studio.
Qualche indicazione più recente si trova anche nel precedente link “Building Qt Static (and Dynamic) and Making it Small with GCC, Microsoft Visual Studio, and the Intel Compiler“, dove risulta che il compilatore Intel è di gran lunga il più lento (il che è in linea con quanto ci si aspetterebbe, perché perderà molto tempo in fase di ottimizzazione). Visual Studio si conferma essere il più veloce anche nella generazione di codice ottimizzato, impiegando 1/3 del tempo rispetto a GCC.
Dal canto mio avrei voluto provare a compilare Python (2.6.4) per misurare i tempi di build sulla mia macchina in ufficio, dove ho installato anche Cygwin e, quindi, GCC, ma purtroppo i tentativi di compilazione di progetti di una certa dimensione sono miseramente falliti, in quanto vengono lanciati diversi processi che prosciugano la memoria della macchina, costringendomi a ucciderli manualmente.
In ogni caso riguardo ai tempi di compilazione troppo lunghi si lamentano anche i miei colleghi in ufficio; “mal comune mezzo gaudio”, come si suol dire. Questo è anche uno dei motivi che ha portato NetBSD a concentrare le sue forze su un compilatore alternativo, PCC, che risulterebbe essere dalle 5 alle 10 volte più veloce, pur generando codice di buona qualità.
Rimane l’ultimo punto, quello del supporto alle architetture e/o s.o. diversi, e qui mi sembra scontato che GCC vinca a mani basse, supportando di tutto ed essendo praticamente onnipresente. Intel, ovviamente, supporta soltanto le sue architetture (x86, x86-64, e Itanium), tant’è che, anche per x86 e x86-64, produce codice ottimizzato che funziona esclusivamente per i suoi processori (e non per quelli di AMD o altri vendor).
VisualStudio Express supporta soltanto x86. Per x86-64, Itanium, e ARM, serve la versione Professional. Anche qui è evidente che Microsoft supporti le architetture esclusivamente a suffragio del suo prodotto principe, Windows (in tutte le sue forme, inclusa quella mobile dove impera ARM).
Non è, però, tutto rose e fiori per GCC, visto che da un po’ di tempo a questa parte la qualità del codice generato per architetture diverse da quelle più gettonate (x86 in particolare) risulta essere peggiorata notevolmente, specialmente per quanto riguarda la famiglia Motorola 68000:
- 68K/Coldfire C-Compiler Performance
- [4.4 regression] zlib is about 20% slower when compiled with GCC 4.4.1
- GCC 4.5.0 Amigaos 68k Compiler CYGWIN Hostet
Ma, a giudicare dai cambiamenti apportati al generatore di codice, di cui si trovano degli esempi eloquenti nel primo e nel terzo link, probabilmente altre architetture saranno state toccate da questi interventi.
La cosa più grave è, che, nonostante le segnalazioni siano state effettuate da parecchio tempo, non si è provveduto a sistemare questi bug; anzi, i ticket non vengono nemmeno assegnati. Ma c’è di peggio. Come si può leggere dal primo commento di questa pagina (è la seconda del primo link), i mantainer ufficiali sembrano pure incompetenti e arroganti a fronte degli sforzi fatti da gente interessata a far migliorare GCC (segnalazioni effettuate e patch fornite, come si può leggere dalla prima pagina).
Il risultato è che, similmente al più famoso caso delle libc (dove il mantainer ufficiale si rifiutò in malo modo di correggere un bug che creava problemi con l’architettura ARM, costringendo gli sviluppatori di Debian a eseguirne un fork), i programmatori hanno deciso di passare a un altro compilatore che facesse fronte alle loro esigenze (come per il caso NetBSD di cui ho parlato prima).
Quello dei bug segnalati ma non sistemati è un problema ben noto (basta controllare i link ai ticket, oppure fare qualche ricerca nel bugtracker), sebbene spesso si senta ripetere il solito mantra che nei progetti open source vengano fixati velocemente. Anche in progetti grossi e con una vasta comunità dietro, com’è GCC, ciò non è sempre vero. Al solito, dipende dall’interesse dei mantainer della relativa area.
Purtroppo capita anche con bug che mettono in discussione la quinta, scontata, voce: quella dell’affidabilità. Da qualche tempo è tornato, infatti, alla ribalta un vecchio bug, quello relativo ai crash dovuti alla (mancanza di) allineamento dello stack, quando si compila ottimizzando per le istruzioni SSE. Parlo di roba vecchia perché è da molto che si trascina, e ogni tanto rispunta quella che viene denominata “rottura dell’ABI x86″:
- Building simple test application with -march=pentium3 -Os gives SIGSEGV (unaligned sse instruction)
- XMM alignment fault when compiling for i386 with -Os
- gcc shouldn’t assume that the stack is aligned
Particolarmente interessanti sono gli interventi di Agner Fog, noto esperto dell’architettura x86, che chiarisce il problema e ribadisce il rispetto dell’ABI x86, oppure ne suggerisce un aggiornamento onde evitare questi inconvenienti particolarmente rognosi.
Non è, infatti, accettabile che si verifichino dei crash a causa della selezione di un’opzione di compilazione più aggressiva. Compilando una libreria dinamica, l’interfaccia da essa esposta è e dev’essere più che sufficiente per poterne effettuare il linking senza alcuna ripercussione. Altrimenti viene meno proprio il concetto di “interfaccia”, che serve a fornire un “contratto” di utilizzo (e a “nascondere” l’implementazione).
Una soluzione ad alcuni problemi potrebbe essere quello di modularizzare il codice, magari caricando al volo soltanto quelli che servono quando si deve compilare per una determinata architettura (mi riferisco sia all’ottimizzatore che al generatore di codice), che contribuirebbe a un miglioramento dei tempi di compilazione e prestazionali (ad esempio l’isolamento impedirebbe che i cambiamenti all’ottimizzatore x86 influenzassero quelli del 68000). Questo lo renderebbe più manutenibile, considerato che al momento è enorme, e il codice non brilla certo per “qualità”.
Sempre a proposito di codice, sarebbe auspicabile che certi mantainer “poco ortodossi”, e magari non all’altezza, fossero allontanati, per il bene del progetto e, soprattutto, di chi ne usufruisce. Non credo che nella numerosa comunità di GCC si faccia fatica a trovare dei rimpiazzi migliori…
E’ incredibile che a simili livelli ci possa essere gente così immatura. Giusto per capire l’entità del danno la famiglia 68k/coldfire quali applicazioni possiede ? Esiste un compilatore ufficiale di motorola in grado di sopperire a gcc ?
non ho letto l’articolo ma dal titolo e dalla mia esperienza con questo compilatore posso dirti SI!!,(l’ho usato praticamente per tutto e lo uso ancora perchè sto continuando lo sviluppo di eso, il mio sistema operativo), è il miglior compilatore del mondo.. rhide invece non posso dirti che sia la migliore ide del mondo eheheheh.. adesso che sono migrato al c# però devo dire che anche visual studio e csc non sono male..
Beh, non so, se sia gcc ad essere politically correct, o se siano altri complilatori a non esserlo (Giulio andreotti avrebbe una idea in proposito).
Ma credo che basti guardare un qualsiasi benchmark intel vs amd, su linux e su windows, per capire quanto sia enorme lo sbalzo
Ho avuto modo di lavorare su progetti parecchio voluminosi (qualche milione di linee di codice in C++), e posso confermare che dove Visual Studio 2005 impiega 2 minuti per compilare in Release, GCC ne impiega almeno 3 per la versione Debug e 4-5 per la Release.
Per chi sviluppa grossi software è davvero una cosa fastidiosa.
gcc ha certamente le sue pecche ma nel complesso rimane ancora oggi nella top10
il punto è che nonostante l’arroganza dei mantainer e nonostante la voglia di rompere la retrocompatibilità ad ogni versione, quanti compilatori supportano così tanti sistemi operativi e così tante architetture?
l’unico che può ( e lo farà ) rompere le uova nel paniere è llvm
parlando dei compilatori ms, è vero che quelli attuali sono ottimi ma abbiamo dimenticato le notti insonni a cercare bug nel nostro codice quando invece il bug era nel runtime del compilatore? purtroppo ci sono passato e maledico microsoft e i suoi compilatori che solo negli ultimi anni sono davvero migliorati….almeno adesso supportano l’ansi c a dovere
Più che tempo ad ottimizzare Compiler impiega tempo ad introdurre codice malevolo in formato di loop intili che girano sotto Authentic AMD XD
@D: non se Motorola/FreeScale produca qualche compilatore per i 68000, ma nei link forniti in quella parte dell’articolo trovi riferimenti a un compilatore che offre delle buone prestazioni con questa famiglia di processori.
@wdasm32: almeno leggilo l’articolo! :D
@The Solutor: potresti essere più chiaro?
@collione: come ho scritto nell’articolo, il supporto a diverse architetture non è l’unico metro di paragone utilizzabile per giudicare la “bontà” di un compilatore.
Come sempre, dipende dalle proprie esigenze: magari per te, se hai che fare con diversi tipi di CPU, è fondamentale questa caratteristica, ma per altri no.
Personalmente non ho trovato bug nei compilatore Microsoft, ma ciò non significa che non ce ne siano, appunto. Software così complessi è difficile che non ne abbiano.
@Alessio T: penso ti riferisca al compilatore Intel, ma non è così. Se venisse provato ciò che dici, scatterebbe una denuncia per concorrenza sleale.
Infatti Intel si limita a ottimizzare esclusivamente per i suoi processori, lasciando per tutti gli altri il codice path standard (386, se non ricordo male).
In effetti la frase “GCC è il miglior compilatore al mondo!” è un tipico mito del Linux, che per esperienza personale ho sentito dire da più di una persona. Ma come tutti questi miti, sono in larga parte infondati. Programmando in C++, posso confermare (empiricamente, si intende…:) ) che GCC è + lento del compilatore Microsoft, e genera codice di Release che è (poco) più lento in esecuzione (ho fatto poco tempo fa un benchmark per un mio sw di calcolo numerico), pur costruendo eseguibili puù “voluminosi”.
Oltretutto è di una lentezza esagerata in compilazione quando compila le STL/Boost o altre librerie che fanno uso massiccio di template. Non ne sono totalmente sicuro, ma mi sembra che Visual Studio usi una diversa strategia di compilazione del C++ in questo caso, in cui il codice template istanziato in comune tra più file sorgente è compilato una sola volta alla fine, mentre GCC ricompila più volte le stesse classi/funzioni template se sono istanziate in unità di compilazione diverse.
P.S. complimenti per l’articolo ben documentato e che tocca argomenti di cui è difficile trovare informazioni chiare in giro.
Su compiler ci sono indagine ed inchieste tutt’ora in corso e non certo per mancata ottimizzazione, cmq qualche righina su x86open64 no? (non dico per forza la build che si trova sul sito developer amd)
L’articolo verteva su GCC, confrontato con i compilatori più gettonati. Per questo non ho preso in considerazione neppure LLVM.
@Aeryon: ho la tua stessa impressione. Compilando codice dotato di molti template GCC letteralmente mi uccide la macchina. Quindi con BOOST ci va proprio a nozze, visto che è per larga parte una collezione di template… :D
@Cesare
Per essere più chiaro…
Confronta i benchmark soliti fatti su HW upgrade (o qualsiasi altro posto) e prenditi a riferimento i benchmark di due processori (uno intel e uno amd).
E poi confronta gli stessi due processori in ambiente linux su phoronix.com ne trovi a iosa (per esempio).
Ora, capita spesso che un processore intel che sotto windows sia magari mediamente il 100% più veloce mentre su linux magari risulta alla pari se non il 10% piu lento del corrispettivo amd.
Ora, direi che i casi sono 2 o è gcc che sfrutta male i processori intel, o sono altri compilatori che sfruttano male (magari volutamente) quelli amd.
Credo che si possa discutere per giorni su quale delle due sia l’ipotesi corretta, ma lo sbalzo c’è e c’è in maniera evidentissima.
Poi, immagino (non essendo un programmatore), che se il discorso lo si fa uscire dall’ambito x86 la faccenda si complchi ulteriormente…
Ho capito, ma sia l’articolo sia il mio commento precedente spiegano la situazione.
Intanto Intel ha il miglior compilatore in assoluto per i suoi processori. Questo è pacifico, spero, e di test ne troverai anche tu a iosa sull’argomento.
Poi non è che Intel produca codice lento appositamente per i processori di altre famiglie. Semplicemente lei ottimizza per i suoi, e basta; per TUTTI gli altri lascia il codice generico (386).
Per cui è ovvio che le differenze fra processori Intel e AMD (ma anche tutti gli altri) siano marcate usando eseguibili generati dal suo compilatore.
Questo a prescindere da Windows, perché i compilatori Intel (c’è anche il Fortran, oltre a C/C++) sono disponibili anche per Linux.
I risultati sono ben diversi usando, invece, un compilatore come GCC (ma anche Visual Studio), che ottimizza bene per TUTTI indistintamente.
Ripeto: se Intel facesse eseguire codice volutamente lento per dei precisi processori della concorrenza, sarebbe stata già inchiodata dall’antitrust da tempo. Si salva proprio perché non ottimizza allo stesso modo per tutti gli altri processori.
Cesare di Mauro ha scritto :
“Poi non è che Intel produca codice lento appositamente per i processori di altre famiglie. Semplicemente lei ottimizza per i suoi, e basta; per TUTTI gli altri lascia il codice generico (386).”
Ma suvvia non cadiamo nel ridicolo ti pare ? Ci sono processori Intel come Amd che non supportano le sse, ma ce ne sono altrettanti che supportano queste estensioni. Il compilatore Intel invece dui andare a guardare quali features un determinato processore possiede e quindi ottimizzare di conseguenza, guarda soltanto la marca del processore. Se e’ Intel ottimizza o meno in funzione della presenza delle sse, se e’ AMD NON OTTIMIZZA NIENTE anche qualora il processore supportasse le sse.
Come programmatore concordo con te (io farei così), ma non puoi dire a Intel come riconoscere un processore ed eseguire appositi code-path: il codice del compilatore è il suo, e gli investimenti li ha fatti lei e vuole tutelarsi.
Formalmente ha, quindi, ragione da vendere. Infatti l’antitrust non s’è mai mossa contro.
Dimenticavo una cosa molto importante: non basta riconoscere una caratteristica per generare codice apposito che la sfrutti al meglio.
Bisogna SEMPRE considerare l’implementazione dell’ISA. Parlando delle SSE, queste sono implementate in maniera diversa a seconda della famiglia di processori.
Sui primi Pentium3 un’istruzione SSE veniva “spezzata” in due microistruzioni, e schedulate opportunamente (visto che non potevano essere eseguite quattro MUL FP nello stesso ciclo di clock, per fare un esempio).
La famiglia Core, invece, esegue un’istruzione SSE in un solo ciclo di clock, e ha quindi ottimizzazioni diverse dal P3.
Quindi il codice ottimizzato SSE per P3 e Core sarà generalmente diverso. Per cui è ovvio che si renda necessario il riconoscimento della famiglia per eseguire l’apposito code-path.
@ Cesare di Mauro :si e no. Il concetto di ISA e’ nata per astrarre dal hardware sottostante. L’ottimizzazione del codice si puo’ e dev’essere fatta a livello di ISA. Quindi se un processore supporta le sse che sono appunto STANDARD, si ottimizza di conseguenza (indipendentemente che il processore si chiami Intel o AMD) etc…
Poi ovviamente niente vieta ad Intel di andare a livello ancora piu’ basso e ottimizzare in maniera piu’ spinta tenendo conto dell’implementazioni delle sse. Ma questo e’ un plus e non centra niente con il comportamento scorretto del compilatore in presenza di cpu AMD.
Premesso che il comportamento del compilatore non è scorretto nei confronti di AMD, ma lo è per tutti gli altri produttori di CPU x86, non si può tenere conto soltanto delle SSE, ma è necessario prendere in considerazione anche l’implementazione dell’ISA.
Faccio un altro esempio: P4 e Banias, offrono la medesima ISA (SSE2 e 3 incluse), ma hanno implementazioni completamente diverse. Se generassi codice generico tenendo conto delle SSE2, commetteresti un madornale errore, perché il codice girerebbe bene solo una delle due famiglie, o addirittura non sarebbe ottimale per nessuna delle due.
Di questo trovi ampia documentazione nel sito di Intel: c’è un manuale dedicato alle sole ottimizzazioni, dov’è spiegato quali ottimizzazioni effettuare per una famiglia piuttosto che per un’altra, e i problemi che ci sono.
Anche per questo il codice generato dai compilatori Intel è molto veloce per i suoi processori: perché viene eseguito il miglior codice per quella particolare CPU sul quale sta girando.
P.S. A scanso di equivoci, io ho avuto soltanto CPU AMD nei miei PC, e mi piacerebbe vederli spremuti meglio che si può. Pertanto le mie sono esclusivamente considerazioni tecniche.
anche questo articolo è interessante,
purtroppo l’anima di gcc è ineguagliabile rispetto agli altri compilatori,
ricordo che stiamo parlando di un software che affonda le sue radici negli anni ’70 e che si è evoluto ed ha compilato milioni di applicazioni.
per quanto mi riguarda se dovessi sviluppare una applicazione in C/C++ continuerei ad utilizzare gcc non perchè è il miglior compilatore del mondo, ma perchè è il compilatore piu’ affidabile in assoluto, non esistono bugs irrisolvibili con il gcc e sopratutto produce un buon codice rispetto agli altri compilatori…
a coloro i quali fantasticano sull’efficacia dei compilatori intel/microsoft nulla da dire se utilizzate su architetture x86/windows ma se poco poco dovete compilare qualcosa su cell o altro siete belli che fritti..
in calce mi piace dire che tornare ad utilizzare l’assembler non è una cattiva idea….
Eh, comunque il discorso resta quello, gcc potrebbe non essere il migliore compilatore in assoluto ma sicuramente risulta essere più “democratico”.
Questo intendevo.
Cesare, apprezzo molto i tuoi articoli, che sono sempre molto equilibrati, ma non condivido alcune delle tue affermazioni sull’ottimizzazione del codice da parte del compilatore Intel.
Guarda per esempio qui dei benchmark indipendenti (quindi ne’ AMD, ne’ Intel) in Fortran che confrontano diversi compilatori, Win32 / Linux64 su processore AMD:
http://www.polyhedron.com/benchamdwin
http://www.polyhedron.com/pb05-linux-f90bench_AMD0html
chi produce il codice piu’ veloce sulla maggioranza dei test ed il secondo e terzo in media assoluta?
Se le ottimizzazioni utilizzate su processori AMD fossero veramente cosi’ triviali non pensi che il compilatore Intel si sarebbe piazzato peggio? :)
Anche questo e’ interessante, anche su Win64/Core i7, dove arriva di nuovo secondo rispetto al compilatore di Absoft:
http://www.polyhedron.com/pb05-win32-f90bench_p40html
Quando qualche anno fa facevo ricerca all’universita’ il codice piu’ veloce, sui nostri Opteron su Linux, era appunto prodotto dal compilatore Intel e non GCC…
Vedo purtroppo che qui molta gente commenta per partito preso senza avere nessuna esperienza diretta, magari sporcarsi un po’ le mani con il codice su diverse piattaforme potrebbe essere utile per farsi una propria idea.
Secondo punto, che mi interessa direttamente visto che lavoro su debuggers (!) :
nella lista delle cose importanti in un compilatore non hai inserito la qualita’ della debug information.
Fondamentale nel debugging di codice ottimizzato… il miglior debugger del mondo non potra’ fare nulla se la debug info – che appunto viene generata dal compilatore – e’ fatta con i piedi!
So che il 99% degli sviluppatori da’ il debugging come un fatto scontato e garantito (almeno per codice non ottimizzato), ma in alcuni casi non e’ cosi’.
Ed in effetti ci si accorge del debugger solo quando questo ha problemi… e lo sviluppatore e’ gia’ incazzato di suo perche’, appunto, sta cercando di risolvere un bug, non proprio una bella situazione :(
@Cesare: meno male che c’e’ qualcuno che capisce che non si puo’ ottimizzare per l’ISA senza sapere che implemtazione c’e’ sotto!
E’ una cosa banale che purtroppo sfugge a molti…
“Se le ottimizzazioni utilizzate su processori AMD fossero veramente cosi’ triviali non pensi che il compilatore Intel si sarebbe piazzato peggio? :)”
Scusa ma cosa dimostrano quei benchmark ?
Dimostrano che il compilatore intel non è scarso (e non mi pare che nessuno lo abbia mai sostenuto).
Ma finché non fai un confronto tra due cpu grossomodo simili per prestazioni, non hai nessuna idea di quanto il codice sia stato ottimizzato, non ottimizzato, o eventualmente, “pessimizzato”
Guardati questi per esempio:
http://www.phoronix.com/scan.php?page=article&item=intel_lynnfield&num=5
Tenendo presente di dove stanno usualmente Phenom X3 710 e i7 920, sia come posizionamento di mercato sia come prestazioni sotto windows.
Caro Solutor, non mi sembra difficile il concetto.
Sono elencati una serie di compilatori insieme a gcc e icc che non sono prodotti da ditte che fanno processori e quindi presumo che non abbiano nessun interesse a far girare il codice “lentamente” su AMD, no?
Bene, se solo uno di questi compilatori riesce a produrre codice piu’ veloce del compilatore Intel – marginalmente – si puo’ ancora dire che il codice prodotto da quest’ultimo non e’ ottimizzato affatto su AMD?
I benchmark che hai postato tu invece non mi pare siano ricompilati utilizzando toolchain diverse, o sbaglio?
Su questo post stavamo parlando della qualita’ del codice prodotto dai diversi compilatori, quindi il tuo commento mi sembra leggermente off topic.
@homero Uno dei migliori pregi di gcc è che è free ed open source, oltre ad essere un progetto storico, ma non è di certo un compilatore perfetto ed è tuttaltro che affidabile (anche in versione stable). Considera comunque che utilizzo sempre gli snapshot, la stable è troppo lenta per i miei gusti, di bug ovviamente ce ne sono ma non è così male, poi mi piace provare le cose all’ultimo grido.
Per il c è abbastanza veloce, e ben supporta gli standard (vedi c99), mentre per il c++ è decisamente più lento, la compilazione di boost è effettivamente un buon esempio. Ho notato che se ci vai giù pesante con gli header e le std il rallentamento è ben visibile. Diciamo che per me la velocità di compilazioni non è un problema.
@goldorak Le ottimizzazioni vengono fatte sia a livello di isa che a livello di architettura, non a caso ci sono due parametri separati. E’ probabile che se non specifichi un particolare cpu ma solo sse il codice sia comunque più ottimizzato per una particolare cpu (probabilmente quelle più recenti). Ricordo un articolo che ho letto (che purtroppo non trovo più) anni fa che metteva a confronto i tre compilatori, da cui usciva che il compilatore ms producesse migliore codice per architettura core rispetto al p4 anche specificando la cpu. Un articolo ben fatto con analisi del codice prodotto.
Ogni architettura è si compatibile con l’isa ma è diversa come implementazione, una buona ragione per ricompilare il codice anche se non e detto che ti vada bene.
@homero L’assembler è morto da anni, non solo nel settore pc ma anche in quello embedded, dove sopravvive solo nelle cpu vecchiotte e per i nostalgici.
@TheKaneB Ms ha lasciato un po andare negli anni il c/c++, buttandosi nel c# e recuperando negli ultimi tempi. Comunque nella mia esperienza i compilatori ms sono ben noti per rompere lo standard, e lo dico apertamente che sono ormai prevenuto, non che non apprezzi alcune cose del loro ide, ma del compilatore ne faccio volentieri a meno.
@ Cesare Di Mauro [e il codice non brilla certo per “qualità”] sono curioso di vedere cosa combineranno con l’integrazione del c++ nel codice.
iva
Non mi pare neanche difficile capire quello che sto dicendo io
“Bene, se solo uno di questi compilatori riesce a produrre codice piu’ veloce del compilatore Intel – marginalmente – si puo’ ancora dire che il codice prodotto da quest’ultimo non e’ ottimizzato affatto su AMD?”
Lo si può dire solo dal momento in cui compari patate con patate.
Il compilatore intel, per quello che mi riguarda potrebbe essere più veloce degli altri e CONTEMPORANEAMENNTE essere pesantemente sbilanciato a favore dei processori intel.
Le due cose non sono mutuamente esclusive.
Il compilatore intel, se paragonato al compilatore bau-bau compiler, potrebbe produrre codice più veloce del 100% su processori intel e del 10 % su processori AMD, e quindi potrebbero essere vere sia la tua affermazione sulla bontà intrinseca del compilatore intel, quanto quella che il compilatore bau-bau sia + democratico meno sbilanciato, mettila come ti pare.
un esempio che avrebbe tagliato la testa al toro poteva essere la diversa implementazione dei rispettivi decoder ;-)
prendiamo ad esempio un Via Nano – stando al product brief questo sarebbe dotato di un decoder superscalare simmetrico a tre vie, in cui ogni pipeline può produrre ad ogni ciclo di clock una o due microistruzioni più un indirizzo (eventuale) riferito alla rom del microcodice
quindi la cpu può decodificare ed eseguire sempre e comunque (a meno di interdipendenze tra istruzioni o branch misprediction – per mitigare le quali però il nano adotta un interessante accorgimento) tre istruzioni X86 sia semplici sia complesse, quindi per una cpu del genere il compilatore è relativamente poco influente al raggiungimento delle massime prestazioni, ottenute invece attraverso un design più pulito, quindi flessibile
le ultime cpu intel invece, evolvendo (alla lontana, ma nemmeno troppo) dall’ architettura P6, implementano un decoder asimmetrico, capace di elaborare, per ciclo, un’ istruzione complessa (le istruzioni complesse sono quelle che richiedono il ricorso al microcodice, e il “microcode engine” è uno e sequenzia il microcodice una microistruzione a ciclo) e fino a tre semplici;
il core 2 è però capace, qualora due tra le istruzioni x86 di quella cache line (la decodifica procede prendendo una cache line da 32 byte -sul core 2 – alla volta, quindi se un’ istruzione, magari complessa, sfora nei 32B seguenti -cosa che può accadere se il compilatore non le allinea in modo ottimizzato- occorrerà attendere il ciclo dopo per decodificarla) siano di tipo idoneo (ad esempio una cmp e un salto), di fonderle prima della decodifica (in effetti eseguendo 5 istruzioni x86)
le prestazioni in questo caso sono potenzialmente superiori, ma è evidente come tale potenzialità dipenda fortemente dal codice generato – quindi dal compilatore, in effetti chiamato a mascherare ineleganze e/o limitazioni eventuali dell’ hw, e a produrre codice che ne attivi quelle feature che contano sul supporto sw per essere sfruttate;
è evidente come questo sia freutto di una mentalità che vede l’ implementazione dell’ ISA rappresentata da una combinazione di HW E SW complementari, prodotti congiuntamente e immessi sul mercato come un tutt’ uno in virtù della propria maggiore forza idustriale – ma non vuol dire che intel sia in torto…
@D
“Giusto per capire l’entità del danno la famiglia 68k/coldfire quali applicazioni possiede ?”
A parte che GCC di suo non fa nessun danno, e spesso è semplicemente oro colato avere un compilatore così versatile e per giunta free, io per io 68K ho come riferimento ancora il SAS/C, anche se Freescale caldeggia Codewarrior.
@Cesare
“P4 e Banias, offrono la medesima ISA”
Soprattutto quantomeno la grossolana differenza delle dimensioni di cache L1 e L2 dovrebbe subito balzare all’occhio anche al meno navigato dei programmatori: probabilmente anche solo un -Os al posto di un -O3 potrebbe stravolgere i valori in campo.
@K
“L’assembler è morto da anni, non solo nel settore pc ma anche in quello embedded”
Sarà, ma a me continuano a offrirmi progetti in ASM.
Se si vogliono fare ottimizzazioni estreme si profila il codice (con valgrind ad esempio) e si interviene a manina sul binario, non c’è gcc o ifc che tenga.
Io chiedo a gran voce il ritorno del …
S A S C !!!!
Io utilizzo il software di rendering Blender 3D, i binari ottimizzati su Graphicall con Visual C++ sono mediamente 5-10% più veloci dei medesimi ottimizzati e compilati con GCC. Percui scarico ed uso sempre i primi.
@ goldorak
Potrei argomentare che l’ottimizzazione del codice NON puo’ e NON deve essere fatta a livello di ISA… ma altri mi hanno preceduto :)
“@homero L’assembler è morto da anni, non solo nel settore pc ma anche in quello embedded, dove sopravvive solo nelle cpu vecchiotte e per i nostalgici.”
eccolo qua il sentenziatore…
l’assembler a me piace usarlo ancora infatti la prima istruzione che compilo come test è codice con una bella istruzione asm e poi vado di debug per vedere come e dove lo ha schiaffato all’interno dell’eseguibile…. e posso assicurare che è molto utile utilizzarlo…
@The Solutor: Intel è una società orientata al profitto. Che possa essere democratica in un mercato in cui la competizione è tutto, è pura utopia.
@iva: per l’articolo mi sono orientato esclusivamente su C/C++, e quindi escludendo altri linguaggi come il Fortran.
Che ci siano aziende che producano compilatori migliori di Intel (la differenza, comunque, è irrisoria) ci può benissimo stare. Non conosco Absoft, ma da quel che ho visto quello dei compilatori Fortran è il suo business, per cui è logico che c’abbia investito risorse e, quindi, abbia ottenuti ottimi risultati.
Sul fatto che il codice generato dal compilatore Intel vada meglio su Opteron rispetto a quello GCC, non mi sembra che abbia detto nulla di simile. Può benissimo essere così, ci mancherebbe, perché dipende anche dal tipo di codice eseguito. Proprio per questo ho, però, i miei dubbi che su codice che faccia abbondante uso delle SSE, quello Intel offra prestazioni migliori a quello GCC sugli Opteron.
Rimane il fatto che Intel per tutti i processori non suoi fa eseguire un code path generico, e questo è stato dimostrato. Qui http://www.agner.org/optimize/blog/read.php?i=49 trovi del materiale specifico. Che poi questo codice si riveli comunque buono anche per i processori AMD, è un punto a favore di questi ultimi e non del compilatore Intel. ;)
Infine sulle informazioni debug, in tutta onestà non c’avevo nemmeno pensato. Sarà perché il debugger lo uso veramente pochissimo (anche se quello di Visual Studio è ottimo), ma non mi sono nemmeno posto il problema quando ho steso l’articolo.
@K: ci vorrà parecchio tempo prima di vedere qualche risultato concreto nell’uso del C++ in GCC. Primo perché attualmente è scritto tutto in C (e sarebbe meglio che fosse riscritto) e la code base è enorme. Secondo perché chi contribuisce al progetto generalmente è abituato a lavorare in C, e sono pochi quelli che padroneggiano il C++ (come si può vedere dai commenti alla notizia).
@j: non conoscevo i dettagli sul Via Nano (sul resto concordo). Però, se non ricordo male, si tratta di un processore in-order; e anche qui, se non c’è un code-path apposito, le prestazioni possono risentirne, anche di molto.
@Marco: il danno di GCC per i 68000 c’è, ed evidente, confrontando il codice generato con le vecchie versioni con le ultime, com’è possibile vedere dai link che ho fornito nell’articolo.
Per quanto riguarda l’ottimizazione del codice per CPU Intel, la stessa casa americana l’anno scorso ha messo su un team apposito di 3 persone. MeeGo sembra essere un prodotto aggressivamente ottimizzato dato che richiede CPU con almeno SSE3 e, da ciò che si è visto, la reattività e la velocità di esecuzione di MeeGo su netbook Atom è impressionante se paragonata a quella che si ottiene da una distro linux qualunque, non so con Win7.
LLVM non è stato considerato nell’articolo per ragioni condivisibili ma ho la sensazione che tra pochi anni potrebbe diventare un nuovo punto di riferimento, attualmente la sua libc++ sembra essere fino a 4 volte più veloce della controparte GNU libstdc++.
Anch’io mi sono scontrato anni fa con un bug del GCC, che causava crash di un encoder MP3. Non riuscii ad identificare la causa, ma avevo risolto diminuendo le opzioni di ottimizzazione. Adesso che leggo qui, in effetti ricordo che succedeva sui Pentium 3 (che ha SSE) ma non sugli Athlon (che ancora non avevano SSE).
Pleg ha scritto :
“Potrei argomentare che l’ottimizzazione del codice NON puo’ e NON deve essere fatta a livello di ISA… ma altri mi hanno preceduto :)”
Mi sa che sbagli. Altri hanno detto quello che io ho sostenuto e cioe’ che ci sono due livelli di ottimizzazione, uno a livello di isa ed uno a livello di architettura.
Argomenta, argomenta che la cosa mi interessa se la pensi diversamente.
i C7 erano in order, il Nano (“Isaiah”) è basato su una un bel processore OOO con pipeline a 14 stadi (e, per dire, 7 porte, dedicate, tra instruction scheduler e alu – Core 2 ne ha 6, di cui alcune condivise tra alu intere e alu FP/ simd) ;-)
è anche vero che via è arrivata per ultima, a quanto? un decennio? di distanza da intel e amd sul fonte dell’ esecuzione out of order, che se ne uscisse d’ amblè con un design moderno e pulito personalmente non mi stupisce più di tanto …
d’ altra parte, mi torna alla mente quello che diceva il mio docente di Architetture dei Calcolatori – nessuno comprerebbe una cpu di un produttore secondario o marginale, se incapace di prestazioni adeguate in ogni circostanza, compreso il caso di sw già circolante, ottimizzato e compilato per le cpu del produttore leader del mercato (a prescindere se questo adotta dei “trucchi” a livello di hw, di compilatore, o entrambi, perchè questo non conta più una volta che il codice è in circolazione, conta solo farlo girare meglio possibile) –
quindi, chi insegue, è portato a fare meglio, da un punto di vista progettuale, del leader, e a tirare fuori design possibilmente più eleganti ed efficienti di questo
@Cesare
“il danno di GCC per i 68000 c’è, ed evidente, confrontando il codice generato con le vecchie versioni con le ultime, com’è possibile vedere dai link che ho fornito nell’articolo.”
Non indendevo questo. Volevo dire che nessuno ti obbliga ad usare GCC 4.x per compilare codice 68K. Ci sono n compilatori, commerciali e non, che generano codice di gran lunga migliore.
Se proprio si vuol usare il gcc la versione 2.95.3 va più che bene.
Dov’è il problema?
Ma che ci guadagna l’autore ogni volta che a parlare sempre e solo male del software libero? Non sarebbe meglio parlare bene del software proprietario? Nessuno obbliga nessuno ad usare programmi liberi.
Io continuo a cliccare sulle cose che mi interessano e mi trovo continuamente articoli firmati da Cesare Di Mauro, dove tralasciando tutto quello che succede di buono, egli si concentra su quell’unica pecca.
Ad esempio ext4: ne parla una volta, perchè c’era stato un baco che ha perso dei dati a qualcuno (quando era in beta).
Idem Ubuntu, un solo articolo, negativo. Richard Stallman, idem. E poi una sfilza di articoli su come l’open source non funziona e non può funzionare o non da da mangiare agli sviluppatori. Il tutto mentre l’open source avanza ogni anno.
Non capisco se ci guadagna a svolgere questo lavoro o se si sente minacciato dal cambiamento, ma di certo mi frega di sentire parlare di queste cose da uno che le capisce e le respira ogni giorno, che usa linux da dieci anni e ci compila gentoo con gcc, non da uno che dice che gli crasha sotto cygwin sul suo netbook da quattro soldi.
se un sistema operativo ha problemi, poniamo di usabilità e consistenza, argomento a me caro ( ma il discorso vale anche in altri ambiti – mi viene da pensare all’ odiosa tastiera a membrana del mio cellulare), una persona che lo abbia usato per dieci anni, vuoi per l’ uso prolungato (che li fa perdere di vista, con abitudine e i meccanismi acquisiti per aggirarli), vuoi perchè magari sono in prima istanza dei non-problemi nell’ utilizzo di quella persona, vuoi per una questione di orgoglio personale, non ti dirà mai che quei problemi esistano …
anche se può sembrare paradossale, quando si parla di problemi di usabilità, malfunzionamenti o in genere tutto quello che ha a che vedere con l’ esperienza d’ uso quotidiano, è più attendibile l’ opinione di un utente nuovo (non necessariamente digiuno d’ informatica, ma nuovo dello strumento specifico) relativa al suo primo contatto, che non quella di un utente navigato (magari reso di parte proprio dal contatto prolungato con lo strumento e dalla conseguente affezione creatasi per esso)
Esistono ottimizzatori, che partendo dal solo binario, possono ottimizzare il programma? Perchè in questo caso si potrebbe lasciare gcc compilare il codice senza ottimizzazioni (in modo da rispettare il più possibile il programma), e poi inviarlo all’ottimizzatore (ovviamente parlo di situazioni dove non è disponibile un altro compilatore).
Se la frase sopra è vera, sarebbe possibile integrare l’ottimizzatore nel sistema operativo, lasciare il sorgente non ottimizzato, in modo che quando il programma viene caricato, viene anche ottimizzato secondo il processore correntemente in uso? Magari includendo nel binario “informazioni sull’ottimizzazione”, così il loader sa dove intervenire.
@Daniele: ho visto qualche test, ed è impressionante il guadagno di velocità della libreria standard di LLVM. Però una libreria si può sempre rimpiazzare con una versione più efficiente.
@goldorak: Intel ottimizza a livello di architettura e di ISA. Dov’è che sbaglierebbe?
@j: sì, gli ultimi sono OOO e sembrano promettere bene (interessanti le scelte architetturali), ma purtroppo Via s’è ormai isolata in una microscopica nicchia di mercato.
@Marco: è chiaro che coi 68000 si potrebbero benissimo utilizzare altri compilatori, commerciali e non.
Tornare alle vecchie versioni di GCC, però, non è certo la soluzione migliore, visto che tanti progetti ormai richiedono le nuove.
Andrea R: ti costa tanta fatica evitare di leggere i miei articoli, visto che poi stai così male? Nessuno ti obbliga a farlo: pensa alla salute e orientati verso altri lidi: vedrai che almeno il fegato ringrazierà…
Mi sento, però, di darti almeno un consiglio: non basta leggerli gli articoli, ma anche capirli.
P.S. I problemi di corruzione con ext4 sono continuati anche dopo il mio articolo. Eccone un altro: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/453579 Tanto per dimostrarti che non si tratta di mosche bianche, come vorresti far credere. Documentati anche tu, ogni tanto, anziché leggere che nel mondo va tutto bene (mi ricorda un nostro, purtroppo famoso, politico).
@Z80Fan: si, si può ottimizzare un binario già generato, senza nemmeno avere indicazioni aggiuntive nel binario originale.
HP in questo campo è stata particolarmente attiva (vedi progetto “Dynamo”).
@Cesare
“Tornare alle vecchie versioni di GCC, però, non è certo la soluzione migliore, visto che tanti progetti ormai richiedono le nuove.”
Continuo a non vedere il motivo per cui stracciarsi le vesti o gridare allo scandalo: chi sviluppa un’applicazione che richiede GCC4 probabilmente non ha come target l’architettura 68K, non gli interessa che i binari siano ottimizzati per 68K o, ancora peggio, non è a conoscenza che esistono soluzioni migliori.
Complimenti, a parte la botta di nostalgia che mi provoca, l’articolo è ben fatto ed appieno condivisibile il concetto di base: non esiste il compilatore più bello del mondo.
E’ assolutamente vero. La scelta del compilatore dipende dal contesto in cui lo adopero.
Certo:
– ogni nuova versione di gcc precompilata è più lenta dell’altra. E’ una vera fortuna che uno si possa bildare la propria. E, test di velocità a parte, g++ -c main.cc mi ha sempre fatto arrivare in orario alle consegne
– esistono compilatori specifici per processore/os più veloci di GCC, vedi Visual Studio. Ed infatti anch’io uso Visual C se devo compilare una applicazione per Winzozz. GCC su M$ si dovrebbe usare solo se costretti da esigenze precise e comprendendone i rischi. Ma, scusatemi, non sarebbe veramente sorprendente il contrario?
Diciamo che la possibilità di GCC di essere un “coltellino svizzero” è vincente rispetto ad ottimizzazioni. Quando mi è capitato di compilare piccole utility su Linux Emnbedded non ho mai avuto un Visual Studio che fosse utilizzabile, GCC mi ha sempre aiutato. Ovviamente esistono sulmercato compilaotori specifici. Ma perdo più tempo ad imparare ad usarli che ad attendere la compilazione GCC.
Poi, è ovvio, quando aprirò una fabbrica sw per costruire un OS per ARM, forse mi preoccuperò di vericare l’usufruibilità di alternative, considerando che in ambienti embedded come i cell attuali, fatalità, gli SDK per lo più usano JAVA e derivati con il punto e la net, altro che compilatori.
Le considerazioni fatte dal’articolista sono corrette, e hanno un peso sul quotidiano, ma non mi sembra spostino un granchè sul ruolo del GCC come strumento di sviluppo industriale e personale.
@ Cesare di Mauro ha scritto : “@goldorak: Intel ottimizza a livello di architettura e di ISA. Dov’è che sbaglierebbe?”
Sbaglia nel senso che disabilita di proposito le ottimizzazioni a livello di isa per certe cpu non intel (che supportano le sse).
A parita’ di sistema operativo e applicativo da compilare, se usi icc su un processore intel (che supporta le sse) il sorgente verra’ compliato con le dovute ottimizzazioni, se lo stesso progetto lo compili su una cpu Phenom X4 (che supporta le sse) l’ottimizzazione a livello di isa viene disabilitata.
Cosa ce’ di cosi complicato da capire ? Come qualcun’altro aveva fatto notare, l’ottimizzazione si fa a due livelli, quello architetturale e quello ISA. Il compilatore intel viene criticato perche’ DISABILITA l’ottimizzazione a livello di ISA per processori non intel anche se avessero il supporto alle sse. Non sto parlando di ottimizzare a livello di microcodice, ma di ISA.
Qualche volta penso che tu faccia veramente orecchie da mercante.
@Cesare
Il mio (virgolettatissimo” democratico era riferito al compilatore, non alla società.
Che non esista a livello aziendale mi pare pacifico.
Peraltro la democrazia a torto o a ragione non è mai esistita neanche nei progetti liberi.
Basta guardare quello che succede ogni volta che ci si trova ad un bivio in ambito linux, non importa se si parli di reiser4 v.s ext4, di radeon v.s. radeonhd, di udev v.s. devfs e quant’altro.
@goldorak: io, invece, penso che bisognerebbe leggere e comprendere meglio quello che scrivono gli altri. Inoltre documentarsi prima di parlare non sarebbe male, e il link per farlo l’ho fornito prima e te lo ripropongo, ma questa volta riportando il dettaglio tecnico del funzionamento del dispatcher usato dal compilatore Intel: http://www.agner.org/optimize/blog/read.php?i=49
E il motivo è sempre lo stesso: perché Intel ottimizza per l’ISA E (congiunzione) per l’implementazione specifica (il MODELLO della CPU: P3, P4, Banias, ecc. ecc. ecc.). Come avevo già detto io, altri, e come torno a ripeterti.
Quel che hai riportato nel tuo commento è del tutto sbagliato, perché il compilatore produce codice con tutte le ottimizzazioni necessarie a prescindere dalla CPU usata nella compilazione.
Tutto si gioca, infatti, in fase di esecuzione, ossia non appena parte il processo e si attiva il dispatcher, che provvede all’identificazione e a eseguire l’apposito code-path.
Detto in altri termini e al contrario di quello che hai riportato, non c’è nessuna disabilitazione delle ottimizzazioni in fase di compilazione, ma la SCELTA di un apposito code-path che tiene conto della seguente tripletta: vendor (Intel o non Intel), modello della CPU, e ISA.
E’ chiaro adesso? Qui non è questione di fare orecchie da mercante, ma quanto meno di capire i termini della discussione. Spero di non dover ripetere nuovamente le stesse cose, perché sarebbe seccante.
Alla luce di cià, ripropongo nuovamente la domanda: dove sarebbe il comportamento scorretto?
@Andrea R
“Non sarebbe meglio parlare bene del software proprietario? Nessuno obbliga nessuno ad usare programmi liberi.”
Concordo pienamente. A volte gli articoli di Cesare sono straordinari, a volte si tratta di giornalismo da 2 soldi ricco di faziosità, come in questo caso. Evidentemente qualche remora nei confronti del free software ce l’ha, non vedo altri motivi.
I fatti e le argomentazioni in quest’articolo non mancano, come pure i consigli (vedi parte finale).
La faziosità, piuttosto, è da ricercare in chi fa certe affermazioni senza nemmeno porsi il problema di come stanno le cose. Per partito preso.
@Cesare
“I fatti e le argomentazioni in quest’articolo non mancano”
Appunto, basta andare a guardarsi i link per confermare appieno la mia precedente affermazione.
A quanto pare non sono alla portata di tutti. Vedi l’inizio dell’articolo, dove scrivo il motivo che mi ha portato a scrivere il pezzo (che comunque parla abbastanza genericamente di compilatori).
@ Cesare di Mauro : ma l’hai letto il primo intervento che si trova nel url che hai linkato ?
Agner Fog dice :
“…..
I have complained about this behavior for years, and so have many others, but Intel have refused to change their CPU dispatcher. If Intel had advertised their compiler as compatible with Intel processors only, then there would probably be no complaints. The problem is that they are trying to hide what they are doing. Many software developers think that the compiler is compatible with AMD processors, and in fact it is, but unbeknownst to the programmer it puts in a biased CPU dispatcher that chooses an inferior code path whenever it is running on a non-Intel processor. If programmers knew this fact they would probably use another compiler. Who wants to sell a piece of software that doesn’t work well on AMD processors?
”
Piu’ chiaro di cosi’ non si puo’. E scorretto vendere un compilatore x86, e poi di nascosto usare un meccanismo che DISABILITA ottimizzazioni su cpu non intel anche quando le stesse cpu non intel sono pienamente x86 compatibili.
Se intel se ne uscisse dicendo : attenzione, icc fornisce ottimizzazioni soltanto per cpu genuine intel allora non ci sarebbe alcun problema. Sai che comprando l’icc avrai una specifica ottimizzazione su cpu intel e se hai un altra cpu ti attacchi. Ma non e’ questo quello che fanno.
Marco ha scritto : “Concordo pienamente. A volte gli articoli di Cesare sono straordinari, a volte si tratta di giornalismo da 2 soldi ricco di faziosità, come in questo caso. Evidentemente qualche remora nei confronti del free software ce l’ha, non vedo altri motivi.”
Mah, le critiche che fa qualche volta sono giustificate.
E soltanto il modo in cui le dice che fa comparire i suoi interventi come delle crociate contro il free software.
Un po’ come Charlie contro Nvidia.
Ad ogni modo Cesare di Mauro stima moltissimo python, quindi qualcosa di buono il mondo open source l’ha fatto no ? ^_^
Mai detto nulla in contrario. Infatti, come amo ripetere spesso, da professionista a me interessa il software, non le “etichette” (closed, open, libero o non, a pagamento o no, e chi più ne ha più ne metta) e men che meno l’integralismo pseudoreligioso.
Scelgo quello che calza “meglio” per il problema che devo risolvere.
Comunque onestamente trovo difficoltà a comprendere dov’è che sbaglierei nel portare delle critiche. Prendiamo quest’articolo: con le premesse da cui è partito (titolo e primi paragrafi), com’è che avrei dovuto trattare l’argomento? Ditemi voi…
Per quanto riguarda il commento precedente, beh, dice una cosa ben diversa da quello che io e altri abbiamo sostenuto finora. Messa in quei termini la questione è effettivamente scorretta: Intel dovrebbe dire chiaro e tondo le cose come stanno.
E’ sul perché tecnicamente abbia scelto quella strada che le nostre opinioni divergono, e su questo vedi anche il pezzo di Agner Fog che ho riportato prima… :P
@goldorak
@Cesare
Mi sono fatto la mia opinione, che molto probabilmente è differente dalla vostra, punto. Nessun problema.
Tanto più che ho ribadito che Cesare scrive articoli che reputo eccellenti, specie quando si addentra nell’analisi dell’ISA di varie architetture. E aggiungo che questi eccellenti articoli sono la stragrande maggioranza. A volte mi scade, de gustibus, ma la mia stima e il mio apprezzamento rimangono, per quanto vi possa interessare.
Beh, a me interessa ovviamente, altrimenti non starei qui a scrivere, ma dedicherei il mio (scarso) tempo ad altro.
Anche le critiche sono benvenute, nella misura in cui mi permettono di poter “calibrare meglio” gli articoli. Proprio per questo prima ho chiesto in che modo avreste trattato lo stesso argomento.
Secondo me l’articolo si sofferma decisamente troppo sulle questioni sociopolitiche della gestione del progetto, come purtroppo capita spesso quando parli di free software.
Progetti come NetBSD, come dal suo motto “Of course it runs NetBSD” non avrebbero avuto modo di esistere senza un compilatore che supporti tutte quelle architetture.
Mi aspetto che, analogamente alla serie 68K, anche sulle architetture quali AMD29K, VAX, 88K ci siano state pesanti regressioni sulle performance: ottimizzazioni per le CPU attuali mal si adattano a quelle più vetuste. Utenti 68K purtroppo ce ne sono sempre meno, da qui meno sviluppatori, meno maintainers del relativo codice gcc, fino all’abbandono definitivo del supporto. Si può discutere fino alla morte su n-mila modi migliori di gestione del progetto, ma quello è.
Infine, io (da vero feticista per queste cose) avrei sviluppato un articolo compilando con diversi tool (e a diversi livelli di ottimizzazione) e disassemblando piccoli programmi in C e analizzando il codice anche dinamicamente simulando diverse CPU.
BTW ottimizzazioni particolarmente “spinte” come ad esempio -mregparm=n (per passare parametri alle funzioni sui registri anziché sullo stack) non vengono quasi mai prese in considerazione, sarei curioso di sapere come si comporta il compilatore Intel per default.
Sarebbe stato sicuramente un miglioramento non da poco, però considera che già adesso impiego 1-2 giorni, spalmati nell’arco della settimana (ma a volte preparo il materiale molto prima, se c’è qualcosa che mi colpisce), per realizzare i miei articoli. E se consideri che fra lavoro e famiglia mi rimane già ben poco tempo, non saprei come avrei potuto fare altrimenti (questa volta ho pure rischiato di non completarlo in tempo; è stata una delle peggiori settimane che ho passato).
Non ti nascondo che ho preferito la comoda via di utilizzare i test fatti già da altri. D’altra parte chi vuole può verificare con mano i dati, ed è da stimolo per i lettori (i commenti in un blog tecnologico servono anche a questo).
A me interessava esporre un’idea e concentrare l’attenzione sugli argomenti trattati, perché generalmente non è roba di cui si parla, mentre continuano a circolare le solite storie (il titolo è già tutto un programma, no?).
E’ verissimo che gli argomenti sono un in certo senso “biased”. Ma penso sia piuttosto naturale: ognuno di noi ha una visione, un modo di pensare che ha sviluppato nel tempo in base alle propri esperienze. Le mie, come si sarà intuito, non sono state (e non sono) tutte rose e fiori.
Cercherò, comunque, di rimettermi in discussione anche su questo punto. In tutta onestà sono rimasto molto sorpreso e non mi sarei aspettato critiche proprio su quest’articolo: lo ritenevo “politicamente corretto”. Probabilmente nello scriverlo ho trasmesso qualcosa di quel che era accaduto nel thread di cui parlavo nell’apertura.
Servirà da lezione per il futuro.
Rispondendo ai punti strettamente tecnici, è verissimo che NetBSD deve molto a GCC. E’ innegabile. Ma è anche vero che col tempo questo progetto è diventato troppo pesante, e chi ha bisogno di realizzare build per progetti di decine di milioni di righe di codice (perché anche NetBSD col tempo è diventato enorme), e con continui cambiamenti, ha un grosso cappio al collo.
Penso si tratti di essere semplicemente realisti: per esigenze nuove servono nuovi strumenti, ed è quello che stanno facendo. Non si tratta di sputare nel piatto in cui hanno mangiato.
Sulle ottimizzazioni delle varie famiglie di CPU, che dire: è un vero peccato, anche perché case come FreeScale continua a produrre processori “68000-based” (e ne sono previsti di nuovi), specialmente per il settore embedded.
Ci può anche stare che vengano preferite le architetture più diffuse (bisogna essere realisti anche in questo), ma personalmente quello che mi dà fastidio è il comportamento scorretto dei mantainer ufficiali a fronte di sollecitazioni sui problemi riscontrati, e addirittura con tanto di patch fornite.
Ma vabbé, qui ricadiamo nuovamente nella “politica”, e hai ragione anche tu: prendiamone atto e amen (tanto ci sono dei progetti alternativi, per fortuna).
Onestamente ritengo certi commenti e certe critiche sorprendentemente fuorvianti e fuori luogo. Mi pare ovvio che il senso dell’articolo sia, più che dare una risposta univoca ad una domanda sciocca, far capire la complessità e le metodologie di scelta che portano a scegliere un compilatore rispetto ad una altro e oserei dire, non solo a scegliere un compilatore, ma addirittura una versione specifica rispetto ad un’altra.
E’ necessario dire che la complessità della materia è enorme? Parliamo di performance di un compilato, ma questo è un valore unico? Certo che no. Lo stesso compilatore potrebbe ottimizzare meglio certi codici, certi applicativi, e ottimizzare peggio in altri ambiti. E questo ci poterebbe a moltiplicare all’infinito i benchmark, alimentando proporzionalmente le discussioni stupide e le crociate.
A conti fatti, certe polemiche servono solamente a chi non lavora e a tempo da perdere online. E’ chiaro che un team esperto sceglierà compilatore, versione di esso, architettura/e, con relative opzioni, che siano il più possibile adeguati alle esigenze del progetto, le quali possono essere le più disparate.
In conclusione, ottimo articolo. Come sempre.
Il motivo per cui sotto cygwin GCC è lentissimo è che windows non supporta il piping dei risultati intermedi, ma questi devono essere memorizzati in file temporanei, al contrario di linux e gli altri sistemi operativi unix dove invece ciò non accade.
Su windows gcc è molte volte più lento che su linux, ma d’altronde è un compilatore pensato non per windows, ma per linux.
Non sono un programmatore , ma vorrei dire la mia esperienza in proposito.
Un programma di astronomia di posizione da me fatto in Fortran su Linux64 con processore AMD64x2 viene eseguito in quadrupla precisione con Intel Fortran che mi dà 2 remark di vettorizzazione che posso eliminare ad ogni esecuzione con il comando “-vec-report0”.
Ho provato ad ottimizzare il compilatore, ma le relative istruzioni sono valide solo per i processori Intel.
Mentre con Gfortran (in doppia precisione) il risultato si avvicina a quello fornito da Intel Fortran in quadrupla, usando lo stesso in doppia precisione il risultato oltre a fornire tutta una serie di Remark di vettorizzazione peggiora.
Tengo a precisare che a parte i Remark i risultati coincidono con quelli forniti da altro computer con Linux Ubuntu64, ma processore Intel Core 2 .
Di conseguenza penso che effettivamente il compilatore Intel sia più veloce,ma per contro pecchi di accuratezza in doppia precisione quando deve lavorare intensamente su matrici ,rispetto ad un Gfortran.
Chi vuole controllare può visitate il sito: “http://astrodinamica.altervista.org/anicola/work.pdf”
[quote]
Il motivo per cui sotto cygwin GCC è lentissimo è che windows non supporta il piping dei risultati intermedi, ma questi devono essere memorizzati in file temporanei, al contrario di linux e gli altri sistemi operativi unix dove invece ciò non accade.
Su windows gcc è molte volte più lento che su linux, ma d’altronde è un compilatore pensato non per windows, ma per linux.
[/quote]
Questo al massimo incide sulla velocità di compilazione non sul sorgente creato che cmq quasi sempre si rileva più lento se generato on gcc, cmq windows usa il sistema file solamente se il codice passato è inferiore a 256 kb
altrimenti usa la shared memory come in linux…