gcc 4.0 - NO FLAMES

[DaVe&OpenMOsix]

Ciao a tutti!
lasciamo le guerre di religione scatenate sull'altro post e, se potete, rispondetemi a queste 2 domande:
1) qualcuno ha provato il compilatore fortran?
io sono molto interessato alle innovazioni del compilatore per fortran90/95.
adesso però non ho coraggio di usare gcc4 sulla macchina di lavoro.
2) è possibile far convivere il gcc3.x con il 4.x?
per esempio gcc3 per compilare il sistema e gcc4 per compilare programmi miei?
-usando portage, si intende... altrimenti compilerei a mano... -
in attesa di poterlo provare su una macchina di test, vi ringrazio per le risposte
ciao
DV

[Sasdo]

dunque:
1) Non l'ho provato =)
2) li emergi entrambi, poi quando hai bisogno di usare uno o l'altro (in mutua esclusione però!) usi gcc-config.

Code: Select all

# gcc-config -l 
[1] gcc-3.4
[2] gcc-4.0
[3] ..etc...
# gcc-config 1          // per usare il 3.4
// oppure
# gcc-config 2          // per usare il 4.0

occhio però che non so cosa può succedere se cambi profilo mentre emergi qualcosa...

p.s.
bel post

[redmatrix]

Per la prima domanda non sono sicuramente la tua risposta, per la seconda la risposta è si.
Come accade per il kernel anche gcc è un programma che ha il multislot in portage, questo significa che puoi installarne quante versioni vuoi e switchare tra una e l'altra con il comando gcc-config (che devi emergere a parte).
Usando

Code: Select all

 gcc-config -l (è una elle non un uno) 

ottieni la lista dellei versioni correntemente installate nel tuo sistema. Ogni versione è preceduta da un numero tra parentesi quadre (ti posto il listato che ottengo sul mio pc)

Code: Select all

root@skeggia root # gcc-config -l
[1] i686-pc-linux-gnu-3.3.5-20050130
[2] i686-pc-linux-gnu-3.3.5-20050130-hardened
[3] i686-pc-linux-gnu-3.3.5-20050130-hardenednopie
[4] i686-pc-linux-gnu-3.3.5-20050130-hardenednossp
[5] i686-pc-linux-gnu-3.4.3 *
[6] i686-pc-linux-gnu-3.4.3-hardened
[7] i686-pc-linux-gnu-3.4.3-hardenednopie
[8] i686-pc-linux-gnu-3.4.3-hardenednossp
root@skeggia root #

la voce seguita dall'asterisco corrisponde alla versione attualmente in uso.
Usando il comando

Code: Select all

 gcc-config N 

dove N sta per un numero corrispondente a uno di quelli tra parentesi quadre switchi appunto tra le varie versioni.
Se io volessi passare dal 3.4.3 al 3.3.5 (i686-pc-linux-gnu-3.3.5-20050130) che si trova alla prima riga (della mia lista) dovrei dare un

Code: Select all

 gcc-config 1 (è un uno non una elle) 

Spero di essere stato chiaro

Ciao

@sasdo
Azz mi hai battuto sul tempo

[DaVe&OpenMOsix]

grazie ragazzi... neanche 10 minuti per due risposte, entrambe ottime!

allora, visto che la seconda domanda ha avuto risposta, aspetto ancora per la prima domanda!
ciao
DV

[Sparker]

Ho installato il gcc4 e ho ricompilato parte di kde: kdelibs-3.4, qt e poco altro quasi senza problemi

Quasi perchè qualche stranamente alcune applicazioni kde non partivano lamentandosi di non trovare il simbolo CXXABI_1.3.1 in libstdc++.so
Bella forza, utilizzavano il libstdc++.so del gcc-3.4!!!!
Si, le ho ricompilante, e No, non ha risolto (anzi peggio, ma non mi dilungo)

Confidando nella fortuna e nel fatto che la libreria C++ dovrebbero essere compatibile all'indietro, ho sostituito la libstdc++ con un link simbolico a quella del gcc-4.0 ed ora funziona tutto che è una meraviglia.

[edit]con "funziona tutto che è una meraviglia" NON intendo che compila senza problemi o che non ne dà in generale, ma solo che il mio KDE pare andare alla perfezione

[BikE]

Io compilato xorg 6.8.2 e da problemi..... vedremo.... vedremo....

[Cagnulein]

avete notato uno speed up visibile?

[cloc3]

Bella forza, utilizzavano il libstdc++.so del gcc-3.4!!!!

Code: Select all

#fix_libtool_files.sh 3.4.3

Fai anche una quicksearch. C'è una letteratura infinita. Con un link avrai problemi ad utilizzare il vecchio gcc, se un pacchetto non compilasse con il nuovo.

Io avevo postato dei problemi nella compilazione del kernel sull'altro post - quello cattivo .

[Sparker]

Bella forza, utilizzavano il libstdc++.so del gcc-3.4!!!!

Code: Select all

#fix_libtool_files.sh 3.4.3

Fai anche una quicksearch. C'è una letteratura infinita. Con un link avrai problemi ad utilizzare il vecchio gcc, se un pacchetto non compilasse con il nuovo.

No, non e' questo, e' stata la prima cosa che ho tentato.

Leggendo questo post apparso su gentoo planet sono piu' propenso ad un qualche tipo di errore legato al gcc-config (o alla mia configurazione), pero' non riesco a capire il motivo (infatti il problema permane per qualsiasi gcc selezionato)
O forse e' colpa di qualche parte di kde-base che non ho ricompilato

[tomasino]

Riguardo a speed up date un'occhiata qui:

http://gcc.gnu.org/projects/tree-ssa/vectorization.html

sembra molto interessante, finalmente posso spolverare un po' i transistor dell'altivec

[DaVe&OpenMOsix]

come scritto anche nel post "cattivo" la vettorizzazione funziona se il codice è scritto bene.
nessuno ha provato il f90? io nel fine settimana avrò (forse) tempo per testarlo.
dai, ditemi qualcosa!
ciao
DV

[Dr.Dran]

Ehm... ragazzi, c'è nessuno che sa oltre alla vettorizzazione, cosa introduce di nuovo e quali miglioramenti, a livello ri opzioni e architetture il nuovo gcc implementa?
Il Fortran 90 è già una bella implementazione e sarei curioso sulle migliorie sul compilatore C++ che è quello che di solito non è molto performante, che migliorie sono stete introdotte?

Grazie a tutti in anticipo

[.:chrome:.]

Ehm... ragazzi, c'è nessuno che sa oltre alla vettorizzazione, cosa introduce di nuovo e quali miglioramenti, a livello ri opzioni e architetture il nuovo gcc implementa?
Il Fortran 90 è già una bella implementazione e sarei curioso sulle migliorie sul compilatore C++ che è quello che di solito non è molto performante, che migliorie sono stete introdotte?

nel vecchio thread, che ha fatto gridare allo scandalo qualcuno, si era già detto, portando anche motivazioni molto concrete, come la nuova versione possa difficilmente portare un incremento di prestazioni nell'esecuzione di codice C su macchine x86 compatibili.
chi è a caccia di incrementi di prestazioni è destinato ad una sana batosta. chi l'incremento di prestazioni lo nota, è stato colpito dall'effetto panacea...

guardando bene il changelog (basterebbe leggere...) sul C è stato cambiato ben poco:

C family
* The sentinel attribute has been added to GCC. This function attribute allows GCC to warn when variadic functions such as execl are not NULL terminated. See the GCC manual for a complete description of its behavior.
* Given __attribute__((alias("target"))) it is now an error if target is not a symbol, defined in the same translation unit. This also applies to aliases created by #pragma weak alias=target. This is because it's meaningless to define an alias to an undefined symbol. On Solaris, the native assembler would have caught this error, but GNU as does not.

in pratica non è cambiato NIENTE, e notare che si tratta di un aggiornamento di major-release: una cosa che dovrebbe portare cambiamenti enormi in un software... non è cambiato NIENTE, ed il motivo è molto semplice: C è un linguaggio che esiste da una vita, ed ormai è ben standardizzato ed acquisito; tutto quello che si poteva ottimizzare è già stato ottimizzato.

ora... piccola riflessione... il kernel è scritto in C, X è scritto in C, i server sono scritti in C... la percentuale di software per UNIX scritto in C puro è SMODATAMENTE GRANDE, rispetto a quella di software scritto in altri linguaggi (C++ e java in primis).
sotto queste ipotesi (ricordo ancora per i tardi di mente che non è cambiato quasi niente nel trattamento di codice C) mi chiedo cosa si aspettino quelli che cercano l'incremento di prestazioni... se mai arriverà, questo incremento, non sarà di certo grazie al compilatore super-professional mega-galattico, ma solo all'illusione che il vecchio 486, grazie al nuovo compilatore, possa andare a fare il culo al mainframe di zion...

il bello è che poi quando si fanno notare queste cose, arrivano tutti i fanatici della nuova versione, quelli che non sanno nemmeno cosa sia cambiato dalla nuova alla vecchia, ma che devono avere l'ultimissima a tutti i costi, e fanno i martiri della patria...
forse sarò io una testa di minchia... a costo di apparire come diavolo volete... a me sembra che si dicano parecchie fesserie, e che ci sia troppa gente che parla di cose che non conosce, alimentando così le leggende che orbitano intorno all'informatica...

preciso che non sto a scrivere queste cose perché ho voglia di fare flames. le scrivo come una mia semplice riflessione
lo dico prima che qualcuno troppo suscettibile si sena urtato nel suo nobile animo. non vuole essere una critica diretta a nessuno. solo un invito a riflettere

[HexDEF6]

se entrambe le versioni possono essere installate senza problemi, e il fortran 90 funziona umanamente, il gcc 4 potrebbe essere la soluzione a molti miei problemi!

Ciao!

[Sparker]

Ecco, ora rischio di scatenare un flame, ma il post precedente di k.gothmog, per quanto riguarda i cambiamenti del compilatore C , è errato:

Dal changelog del gcc-4.0.0

General Optimizer Improvements
* The tree ssa branch has been merged. This merge has brought in a completely new optimization framework based on a higher level intermediate representation than the existing RTL representation. Numerous new code transformations based on the new framework are available in GCC 4.0, including:
o Scalar replacement of aggregates
o Constant propagation
o Value range propagation
o Partial redundancy elimination
o Load and store motion
o Strength reduction
o Dead store elimination
o Dead and unreachable code elimination
o Autovectorization
o Loop interchange
o Tail recursion by accumulation

Many of these passes outperform their counterparts from previous GCC releases.
* Swing Modulo Scheduling (SMS). An RTL level instruction scheduling optimization intended for loops that perform heavy computations.

e ancora

C and Objective-C
* The -Wstrict-aliasing=2 option has been added. This warning catches all unsafe cases, but it may also give a warning for some cases that are safe.
* The cast-as-lvalue, conditional-expression-as-lvalue and compound-expression-as-lvalue extensions, which were deprecated in 3.3.4 and 3.4, have been removed.
* The -fwritable-strings option, which was deprecated in 3.4, has been removed.
* #pragma pack() semantics have been brought closer to those used by other compilers. This also applies to C++.
* Taking the address of a variable with register storage is invalid in C. GCC now issues an error instead of a warning.
* Arrays of incomplete element type are invalid in C. GCC now issues an error for such arrays. Declarations such as extern struct s x[]; (where struct s has not been defined) can be moved after the definition of struct s. Function parameters declared as arrays of incomplete type can instead be declared as pointers.

I cambiament riportati da k.gothmog sono le modifiche che convolgono tutti e solo i linguaggi della famiglia C: C, C++, Objective-C. Overo un sottoinsieme molto stretto dei cambiamenti.


Poi sui reali impatti prestazionali non mi pronuncio, perchè, anche se forte del mio 30 in "Linguaggi e compilatori", non mi sento in grado di giudicare un software complesso come un compilatore commerciale.

[.:chrome:.]

General Optimizer Improvements
* The tree ssa branch has been merged. This merge has brought in a completely new optimization framework based on a higher level intermediate representation than the existing RTL representation. Numerous new code transformations based on the new framework are available in GCC 4.0, including:
o Scalar replacement of aggregates
o Constant propagation
o Value range propagation
o Partial redundancy elimination
o Load and store motion
o Strength reduction
o Dead store elimination
o Dead and unreachable code elimination
o Autovectorization
o Loop interchange
o Tail recursion by accumulation
Many of these passes outperform their counterparts from previous GCC releases.
* Swing Modulo Scheduling (SMS). An RTL level instruction scheduling optimization intended for loops that perform heavy computations.

però questo riguarda, in generale, il modo in cui vengono trattati i VALORI all'interno del linguaggio e del compilatore. io sono scettico sul fatto che questo, pur portando maggiore efficienza, possa anche portare prestazioni migliori (ma questa è una mia personalissima opinione)

C and Objective-C
* The -Wstrict-aliasing=2 option has been added. This warning catches all unsafe cases, but it may also give a warning for some cases that are safe.
* The cast-as-lvalue, conditional-expression-as-lvalue and compound-expression-as-lvalue extensions, which were deprecated in 3.3.4 and 3.4, have been removed.
* The -fwritable-strings option, which was deprecated in 3.4, has been removed.
* #pragma pack() semantics have been brought closer to those used by other compilers. This also applies to C++.
* Taking the address of a variable with register storage is invalid in C. GCC now issues an error instead of a warning.
* Arrays of incomplete element type are invalid in C. GCC now issues an error for such arrays. Declarations such as extern struct s x[]; (where struct s has not been defined) can be moved after the definition of struct s. Function parameters declared as arrays of incomplete type can instead be declared as pointers.

come si legge: il primo punto dice che è stato cambiato il funzionamento di un'opzione;
il secondo ed il terzo dicono che un'altra opzione è stata rimossa;
il quarto punto annuncia un cambiamento di semantica da parte di una istruzione;
il quinto ed il sesto punto dicono che un'istruzione è diventata invalida e che, in pratica, è stato introdotto un controllo più rigido sull'integrità delle variabili strutturate.

è vero che ho riportato un sottoinsieme stretto di cambiamenti: infatti non è pensabile che un aggiornamento di major-release sia accompagnato a tale insieme così ristretto. quelli che ho riportato sono tutti e soli i cambiamenti strettamente connessi al kernel e ad un discorso prestazionale su sistemi operativi UNIX.
il trattamento del C++, per esempio è stato molto cambiato. Java è stato letteralmente sconvolto, e via dicendo... ma di tutte queste cose, al kernel, o a X, o ai vari window-manager, NON GLIENE POTREBBE FREGARE DI MENO, QUINDI mi sembra un discorso abbastanza stupido aspettarsi chissà quale incremento di prestazioni.
certo... magari se padre pio ci concede la grazia, è anche possibile che il kernel diventi supervelocissimo, ma non aspettiamoci nulla di particolare dal kernel.

è questo che intendevo dire

[DaVe&OpenMOsix]

calma calma! l'altro post è stato chiuso... non vorrei che questo facesse la stessa fine
ieri sera ho scaricato i sorgenti, e se tutto è ok stasera compilerò (una roba alla volta...)
ma la soluzione corretta per portage quale è?

Code: Select all

echo "sys-devel/gcc" >> /etc/portage/package.unmask 
e poi
echo "sys-devel/gcc ~x86" >> /etc/portage/package.keyword

vado bene?
non ho mai smascherato un hard masked
ciao
DV

[flocchini]

mi sembra corretto (in realta' volevo dire "si'" ma la metto cosi' per evitare figuracce plateali in caso di fesseria )

[Dr.Dran]

Ottimo,ragazzi, ho letto i vostri post e finalmete si parla un pelo + in profondità dei quello che è il gcc 4.0, la mia inserzione voleva essere un pretesto per vedere se questo thread non diventasse come l'altro. Insomma se l'argomento è il gcc parliamo di quello no! E basta fare fantasie su incredibili ottimizzazioni che poi non sono reali, anche perchè credo che la cosa non sia effettivamente possibile in termini percettibili... ok magari un salto a una routine viene ottimizzato meglio, una struttura if viene eseguita con un ciclo in meno e che dire, non credo che noi effettivamente ci accorgeremmo di tali miglioramenti!

Ringrazio sempre k.gothmog che per me è sempre molto esplicito ma diretto e concreto

[Sparker]

Ho spulciato un po' il manuale del gcc-4 e ho individuato alcune delle flag nuove:

Code: Select all

-ftree-pre
    Perform Partial Redundancy Elimination (PRE) on trees. This flag is enabled by default at -O2 and -O3.

-ftree-fre
    Perform Full Redundancy Elimination (FRE) on trees. The difference between FRE and PRE is that FRE only considers expressions that are computed on all paths leading to the redundant computation. This analysis faster than PRE, though it exposes fewer redundancies. This flag is enabled by default at -O and higher.

-ftree-ccp
    Perform sparse conditional constant propagation (CCP) on trees. This flag is enabled by default at -O and higher.

-ftree-dce
    Perform dead code elimination (DCE) on trees. This flag is enabled by default at -O and higher.

-ftree-dominator-opts
    Perform dead code elimination (DCE) on trees. This flag is enabled by default at -O and higher.

-ftree-ch
    Perform loop header copying on trees. This is beneficial since it increases effectiveness of code motion optimizations. It also saves one jump. This flag is enabled by default at -O and higher. It is not enabled for -Os, since it usually increases code size.

-ftree-loop-optimize
    Perform loop optimizations on trees. This flag is enabled by default at -O and higher.

-ftree-loop-linear
    Perform linear loop transformations on tree. This flag can improve cache performance and allow further loop optimizations to take place.

-ftree-loop-im
    Perform loop invariant motion on trees. This pass moves only invariants that would be hard to handle at RTL level (function calls, operations that expand to nontrivial sequences of insns). With -funswitch-loops it also moves operands of conditions that are invariant out of the loop, so that we can use just trivial invariantness analysis in loop unswitching. The pass also includes store motion.

-ftree-loop-ivcanon
    Create a canonical counter for number of iterations in the loop for that determining number of iterations requires complicated analysis. Later optimizations then may determine the number easily. Useful especially in connection with unrolling.

-fivopts
    Perform induction variable optimizations (strength reduction, induction variable merging and induction variable elimination) on trees.

-ftree-sra
    Perform scalar replacement of aggregates. This pass replaces structure references with scalars to prevent committing structures to memory too early. This flag is enabled by default at -O and higher.

-ftree-copyrename
    Perform copy renaming on trees. This pass attempts to rename compiler temporaries to other variables at copy locations, usually resulting in variable names which more closely resemble the original variables. This flag is enabled by default at -O and higher.

-ftree-ter
    Perform temporary expression replacement during the SSA->normal phase. Single use/single def temporaries are replaced at their use location with their defining expression. This results in non-GIMPLE code, but gives the expanders much more complex trees to work on resulting in better RTL generation. This is enabled by default at -O and higher.

-ftree-lrs
    Perform live range splitting during the SSA->normal phase. Distinct live ranges of a variable are split into unique variables, allowing for better optimization later. This is enabled by default at -O and higher.

-ftree-vectorize
    Perform loop vectorization on trees. 

Come potete vedere sono quasi tutte attive da -O in su, quindi non impazzite per cercare la flag che può dare quel 0,001% in più a mplayer

O.T. tra l'altro ho notato " -O also turns on -fomit-frame-pointer", bene, posso liberare un po' di spazio nel make.conf

[!equilibrium]

magari a qualcuno può essere utile, per cui riporto la mia esperienza:

ho testato questa versione del compilare sul mio notebook che ha una CPU VIA, quindi parecchio scarsa e poco prestante in fatto di compilazione.
incrementi generali di prestazioni non mi sembra di notarne, anzi, mi sembra + lento

un miglioramento netto lo noto in due aspetti:
- per il mio tipo di processore (march=c3) il codice è più stabile, mentre prima dovevo compilare certi pacchetti con march=i686 altrimenti march=c3 mi sputava codice farlocco non funzionante
- le applicazioni multimediali ricompilare con march=c3 sono nettamente + veloci, ma questo non è da imputare a fantomatici boost o ottimizzazioni estreme del compilatore stesso, ma come esposto nel punto precedente, il supporto per tale architettura è + completo a beneficio anche delle estensioni della cpu che prima erano supportate male (nel mio caso MMX e 3DNOW)

non noto null'altro nel mio caso.

[Dr.Dran]

Bene questo mi sembra un buon punto per iniziare a discutere:
@ Sparker = ottimo, potremo iniziare a commentare un pò tutte le opzioni nuove e a capire che tipo di ottimizzazioni o eclusioni introducono.
@ DarkAngel76 = mi piace il fatto che tu abbia accennato ad una architettura di tipo Via C3 perchè quelle bellissime schedine all-in one sono molto appetibili per fare quasi di tutto dal desktop in posco spazio al HTPC etc etc... ci sono inrete un tot di progetti.. eh eh eh



Mi sa che il forum sta prendendo una buona piega... vediamo che come si sviluppa

[!equilibrium]

@ DarkAngel76 = mi piace il fatto che tu abbia accennato ad una architettura di tipo Via C3 perchè quelle bellissime schedine all-in one sono molto appetibili per fare quasi di tutto dal desktop in posco spazio al HTPC etc etc... ci sono inrete un tot di progetti.. eh eh eh

[OT] se vuoi sfruttare al massimo la potenza di un VIA l'ideale è usare un kernel BSD i quali, di default non fanno uso della FPU (cosa che nei VIA è pensosa, vabbhe per quello che costano non c'è da lamentarsi troppo). [/OT]

[Dr.Dran]

Concordo infatti ho trovato in rete progetti di clusterini con via C3 a 800 Mhz in cui veniva installato di default BSD

[!equilibrium]

Concordo infatti ho trovato in rete progetti di clusterini con via C3 a 800 Mhz in cui veniva installato di default BSD

altro OT nell' IT:

[OT]nella fattispecie se provi ad usare QNX o netBSD con una VIA noterai performance che linux difficilmente raggiunge (ovviamente)[/OT]