# gcc 4.0 - NO FLAMES

## DaVe&OpenMOsix

Ciao a tutti!

lasciamo le guerre di religione scatenate sull'altro post  :Shocked:  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...   :Sad:  - 

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.

```
# 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  :Wink: 

----------

## 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 

```
 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)

```

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

```
 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

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

Spero di essere stato chiaro

Ciao

@sasdo

Azz mi hai battuto sul tempo  :Wink: 

----------

## DaVe&OpenMOsix

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

 :Very Happy: 

allora, visto che la seconda domanda ha avuto risposta, aspetto ancora per la prima domanda!  :Wink: 

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 perfezioneLast edited by Sparker on Tue Apr 26, 2005 5:45 pm; edited 1 time in total

----------

## BikE

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

----------

## Cagnulein

avete notato uno speed up visibile?

----------

## cloc3

 *Sparker wrote:*   

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

 

```

#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  :Laughing:  .

----------

## Sparker

 *cloc3 wrote:*   

>  *Sparker wrote:*   Bella forza, utilizzavano il libstdc++.so del gcc-3.4!!!!
> 
>  
> 
> ```
> ...

 

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  :Razz: 

----------

## 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!  :Rolling Eyes: 

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  :Very Happy: 

----------

## .:chrome:.

 *DranXXX wrote:*   

> 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:

 *Quote:*   

> 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

 *Quote:*   

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

 

e ancora

 *Quote:*   

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

 

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

 *Sparker wrote:*   

>  *Quote:*   
> 
> 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:
> ...

 

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)

 *Sparker wrote:*   

>  *Quote:*   
> 
> 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.
> ...

 

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  :Confused: 

ieri sera ho scaricato i sorgenti, e se tutto è ok stasera compilerò (una roba alla volta...)

ma la soluzione corretta per portage quale è?

```

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  :Embarassed: 

ciao

DV

----------

## flocchini

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

----------

## 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!  :Wink: 

Ringrazio sempre k.gothmog che per me è sempre molto esplicito ma diretto e concreto  :Wink:   :Very Happy: 

----------

## Sparker

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

```

-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  :Laughing: 

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

 :Cool:   :Very Happy: 

Mi sa che il forum sta prendendo una buona piega... vediamo che come si sviluppa  :Shocked:   :Very Happy: 

----------

## !equilibrium

 *DranXXX wrote:*   

> @ 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  :Wink: 

----------

## !equilibrium

 *DranXXX wrote:*   

> 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]

----------

## .:chrome:.

 *DarkAngel76 wrote:*   

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

 

finalmente un post serio  :Very Happy: 

grande DarkAngel  :Wink: 

----------

## DaVe&OpenMOsix

ok! ho compilato sto benedetto gcc 4!

per intanto l'emerge sync e update -uD world mi hanno fatto installare gcc 3.3.5 

e gia' li' c'era qualcosa che non andava... alcuni programmi aggiornati hanno smesso di funzionare (mplayer e totem non leggono + dvd  :Evil or Very Mad:  )

bon.

ho smascherato gcc in /etc/portage/package.mask e in /etc/portage/package.keywords aggiungendo la keyword "-*".

per compilarsi, si e' compilato senza errori. ho attivato la use "fortran" (era quello che mi interessava).

ho compilato per prova alcuni programmetti fortran90 (molto semplici, senza librerie esterne... solo con costrutti f90) della mia tesi e... errori a manetta.   :Crying or Very sad: 

ieri sera, colpa la febbre, ho desistito e ho lasciato perdere, appena mi rimetto ci riprovero'.

per adesso risultato scarso.

altri programmi in c non li ho provati.

saluti

DV

----------

## .:chrome:.

 *DaVe&OpenMOsix wrote:*   

> per adesso risultato scarso

 

era ovvio che sarebbe successo.

queste corse all'ultima versione sono, oltre che immotivate, estremamente rischise

----------

## fedeliallalinea

 *k.gothmog wrote:*   

> oltre che immotivate

 

Non sono immotivate... basta che uno ha il desiderio di farlo che e' gia' un motivo valido (a suo rischio e pericolo chiaramente)

----------

## DaVe&OpenMOsix

@k.gothmog

NON e' immotivato. adesso te lo spiego. mi serve il f90. non voglio pagare la licenza per il compilatore intel o pgi. questo perche' la macchina su cui girerebbe il compilatore e' ad uso di un gruppo di studenti e la licenza intel gratuita e' solo personale. quindi se il compilatore gcc 4 fa il suo mestiere, io ho risolto un grosso problema.

se ti interessa partecipare costruttivamente alla discussione, sei il benvenuto.

credo che questo thread possa servire a piu' di qualcuno. come si era detto precedentemente evitiamo flames.

ciao

DV

----------

## randomaze

 *DaVe&OpenMOsix wrote:*   

> come si era detto precedentemente evitiamo flames.

 

A tal scopo vorrei invitare i partecipanti costruttivi al thread a non rispondere alle provocazioni.

Se necessario poi provvedo a far pulizia splittando i messaggi inutili in un altro thread in modo da testare il nuovo bottone dell'interfaccia da moderatore ("move this topic to dustbin").

----------

## redview

trovo assurdo come questo post (e il suo defunto predecessore) sia così suscettibile a flames..con un pò di calma e meno banfaggine si imparerebbe tutti di più, a partire dal sottoscritto, interessato all'argomento, ma abb ignorante a riguardo..

buona lettura:

http://developers.slashdot.org/developers/05/05/02/1415220.shtml?tid=156&tid=8

redview

----------

## .:chrome:.

 *redview wrote:*   

> trovo assurdo come questo post (e il suo defunto predecessore) sia così suscettibile a flames..con un pò di calma e meno banfaggine si imparerebbe tutti di più, a partire dal sottoscritto, interessato all'argomento, ma abb ignorante a riguardo..

 

---> post modificato <---

beh... dico la mia, dato che credo proprio sia stato il mio post a urtare al sensibilità del nostro moderatore.

non appena si scrive qualcosa che potrebbe anche lontanamente sembrare polemica sono tutti pronti a chiudere post e mettersi a fare casino...

certe volte, però, non è semplice esprimere le proprie opinioni con la dovuta pacatezza.

in generale, se qualcuno non è d'accordo con ciò che si legge (nel contenuto o nella forma) è liberissimo di controbattere; spero nessuno si offenda, e credo che a tutti interessi confrontarsi su questi argomenti.

quando si confrontano alcune idee, però, è naturale che magari i toni si scaldino; non viene fatto per cattiveria o per altro...

per quanto riguarda me, chiedo scusa se a volte rispondo in modo frettoloso o mi lascio prendere la mano.

spero che i moderatori perdonino il mio sfogo di prima. in particolare grazie a fedeli per i buoni consigli  :Smile: Last edited by .:chrome:. on Mon May 02, 2005 7:30 pm; edited 2 times in total

----------

## redview

 *randomaze wrote:*   

> A tal scopo vorrei invitare i partecipanti costruttivi al thread a non rispondere alle provocazioni.

 

mi appello all'articolo di randomaze! :Laughing: 

----------

## fedeliallalinea

 *redview wrote:*   

> mi appello all'articolo di randomaze!

 

Preciso che era riferito al post precedente a quello modificato (almeno questo e' stato scritto riferito al post vecchio)

----------

## ballero

Ho visto ora i bench di Scott R. Ladd.

E' davvero un peccato che il 4.0 non abbia mantenuto le attese in maggiori prestazioni, specialmente in confronto con l'icc.  :Mad: 

Davvero deluso.

----------

## Sparker

Beh, visto il radicale cambiamento del framework di ottimizzazione, è naturale aspettarsi delle prestazioni non eccezzionali.

Da quello che ho letto, nel ramo 4.1 stanno sfruttando Tree-SSA per implementare le ottimizzazioni adatte a contrastare ICC

(ma giudicheremo quando sarà pronto)

----------

## BikE

Da esperienza risultano problemi anche in openssl.... non durante la compilazione ma in seguito tutti i programmi che l'utilizzano vanno in SIGFAULT

----------

## DaVe&OpenMOsix

buone notizie.

ieri sera ho riprovato gcc4. come detto prima mi serviva gfortran per il fortran 90.

ho ricompilato lam-mpi, smanettando un po' con l'ebuild.

e funziona!

ho fatto diverse prove, con fortran90 semplice e con mpi, e sono state tutte buone. non ho fatto comparazione di prestazioni, ma mi sembra buono. ho compilato e fatto girare un programma parallelo abbastanza complicato, quello della mia tesi, e il risultato è a posto.

quindi, direi che tutto è ok.

provatelo, quindi, dateci dentro.

io proverò a sottomettere il mio ebuild tarocco di lam-mpi a bugzilla, vediamo cosa diranno...

ciao

DV

----------

## Dr.Dran

@ DaVe&OpenMOsix

Scusa la curiosità stai lavorando su un cluster openmosix? Io ne avevo realizzato uno 2 anni fa con 4 PII a 233 Mhz è stato mooolto divertente... aspetto la versione stabile per il kernel 2.6 che sembra quasi a tiro eh eh eh  :Very Happy: 

----------

## DaVe&OpenMOsix

@DranXXX

sì, ho lavorato su OM e MPI per la tesi. ho questo nick perchè ho cominciato a fare domande nel forum su OM appunto... aspetto il 2.6OM anch'io

e proprio per quel clusterino mi servirebbe f90. adesso c'è ifc, ma non mi sconfinfera...

ciao

DV

----------

## Dr.Dran

 *DaVe&OpenMOsix wrote:*   

> @DranXXX
> 
> adesso c'è ifc, ma non mi sconfinfera...
> 
> ciao
> ...

 

eh eh eh capisco benissimo, pure un mio amico sta lavorando alla tesi di chimica con ifc eh sta bestemmiando come un animale!!!!

P.S. io sono andato al workshop che fecero 2 anni fa su openmosix al Cineca di Bologna è stato veramente carino soprattutto conoscere il mitico Moshe Bar in persona!  :Cool:   :Very Happy:   :Very Happy:   :Very Happy: 

----------

