ARGOMENTO:

boboviz ha scritto:

Lo so, 1,6% sembra poco, ma bisogna considerare 2 fattori:
1) E' stato ottenuto con una semplice ricompilazione, senza nessuna ottimizzazione del codice
2) Dovete moltiplicare questo piccolo miglioramento per le migliaia e migliaia di cpu dedicate a rosetta.

Mmm, da maniaco delle ricompilazioni con nuove cflags ti dico che secondo me è troppo vicino a quel margine di incertezza che ottieni facendo due volte lo stesso test.
Generalmente se la differenza è inferiore al 5% (in più o in meno) la considero ininfluente.
IMO, ovviamente.

Stanno usando Visual Studio 2010, vediamo se passano al 2013 o addirittura al 2015 che dovrebbe uscire questa estate.

Piuttosto che IntelquacCheCosa, va bene piuttosto.

xdarma ha scritto:

Mmm, da maniaco delle ricompilazioni con nuove cflags ti dico che secondo me è troppo vicino a quel margine di incertezza che ottieni facendo due volte lo stesso test. Generalmente se la differenza è inferiore al 5% (in più o in meno) la considero ininfluente. IMO, ovviamente.

Certo, potrebbe anche essere uno scostamento casuale, ma almeno gli admin stanno dimostrando, dopo tanto tempo, l'intenzione di mettere mano all'ottimizzazione del codice. Spero sia solo un primo passo.
Aspettiamo il lavoro su Ralph per vedere se è un vero incremento (già che non siano andate peggio....)

Stanno usando Visual Studio 2010, vediamo se passano al 2013 o addirittura al 2015 che dovrebbe uscire questa estate.

Piuttosto che IntelquacCheCosa, va bene piuttosto.

Ultime nuove. Sembra che la ricompilazione sotto gcc (usando una versione del 2012) per avere l'applicativo linux dia migliori risultati rispetto alla ricompilazione sotto Visual Studio 2010 (da quel che si è capito, hanno intenzione di saltare la versione 2013 e passare alla versione 2015 di VS appena uscirà). Gli admin hanno anche ammesso che "these optimizations which our scientists and developers aren't that familiar with".
Qualcuno ha suggerito agli admin di contattare privatamente l'utente che ha aperto tutta stà gazzarra sulle ottimizzazioni.

Per Xdarma:
I primi test sotto linux sembrerebbero indicare un 12% in più
Fosse vero, è la volta che passo al lato oscuro di linux

boboviz ha scritto:

Ultime nuove. Sembra che la ricompilazione sotto gcc (usando una versione del 2012) per avere l'applicativo linux dia migliori risultati rispetto alla ricompilazione sotto Visual Studio 2010 (da quel che si è capito, hanno intenzione di saltare la versione 2013 e passare alla versione 2015 di VS appena uscirà). Gli admin hanno anche ammesso che "these optimizations which our scientists and developers aren't that familiar with".
Qualcuno ha suggerito agli admin di contattare privatamente l'utente che ha aperto tutta stà gabola sulle ottimizzazioni.

L'importante è che NON usino ICC.
Fra l'altro, gcc è famoso per la portabilità, non per le prestazioni. Quindi potrebbe essere vero che con poche modifiche hai un sensibile miglioramento. Ma sotto linux, non sotto windows.

Se migliorano x86 del 25%, mettono il progetto arm in soffitta.

Per Xdarma:
I primi test sotto linux sembrerebbero indicare un 12% in più
Fosse vero, è la volta che passo al lato oscuro di linux

Prima di schiantarti contro gentoo, impara a ricompilare il kernel con la distribuzione che ti sembra più adatta. Te lo dico perché secondo me hai il maggior "rendimento" tra prestazioni/bestemmie con la sola ricompilazione del kernel. Se usi amd, poi, potrai usare qualche flag esotica. E lì ti diverti a vedere in quanti millisecondi va in crash.

Quello "c'è stà a provà"

Intel has a Intrinsic Guide online at software.intel.com/sites/landingpage/IntrinsicsGuide/

There are also hand optimized libraries supported by Intel and open source groups (with the help of Intel) that developers can include in their code. Intel MKL and IPP libraries are, I think, available to educational institutions for distribution

xdarma ha scritto:

Le ultime generazioni di AMD hanno la fpu condivisa e "faticano" con le avx-256. Se vengono usate avx-128 riescono a elaborarne due alla volta. Sarebbe da segnalarlo, solo per evitare che vengano usate le 256 quando bastano le 128.
TIA

rjs5 ha scritto:

If I turn on AVX2, it uses the YMM 256-bit registers BUT still generates 64-bit scalar code. You see some minor improvement.

Direi che più che provarci, ci ha pensato benissimo e suggerisce anche ottimizzazioni che danneggiano leggermente gli amd.
Non serve neanche "commettere peccato" andreottianamente parlando: sono loro che ti danno le prove del reato.

xdarma ha scritto:

Direi che più che provarci, ci ha pensato benissimo e suggerisce anche ottimizzazioni che danneggiano leggermente gli amd. Non serve neanche "commettere peccato" andreottianamente parlando: sono loro che ti danno le prove del reato.

If you have access to the Intel compiler, look at the option:

-ax<CODE>

The "-a" part tells the ICC compiler to generate multiple, feature-specific, auto-dispatch code paths for Intel processors if there is a performance benefit. Since you are looking at all machines, I would set "<CODE>" for the newest machine .... Haswell.

Ci pensi tu, Xdarma, a fargli un cazziatone o faccio io??

boboviz ha scritto:

Ci pensi tu, Xdarma, a fargli un cazziatone o faccio io??

Eh, mi piacerebbe fare un post sul fatto che rjs5 è palesemente legato ad intel, su amd-cripple-function e sulla dubbia utilità delle avx2 per rosetta in confronto alle avx1.
Lascia stare che amd va maluccio con avx2, quanti sono i processori che le supportano e che guadagno hai?
Non conviene allargare il parco cpu "accontentandosi" di avx1? Già usare le sse mi sempra un passo da gigante.
Purtroppo il mio inglese fa ridere e ultimamente non ho molto tempo per scrivere.
Se ti prudono le mani: vai e uccidi. Altrimenti se ne riparla il fine settimana: sono un po' preso dal lavoro.

boboviz ha scritto:

xdarma ha scritto:

Direi che più che provarci, ci ha pensato benissimo e suggerisce anche ottimizzazioni che danneggiano leggermente gli amd. Non serve neanche "commettere peccato" andreottianamente parlando: sono loro che ti danno le prove del reato.

If you have access to the Intel compiler, look at the option:

-ax<CODE>

The "-a" part tells the ICC compiler to generate multiple, feature-specific, auto-dispatch code paths for Intel processors if there is a performance benefit. Since you are looking at all machines, I would set "<CODE>" for the newest machine .... Haswell.

Ci pensi tu, Xdarma, a fargli un cazziatone o faccio io??

forse mi sono perso qualcosa ... ma stanno utilizzando ICC ??

sabayonino ha scritto:

forse mi sono perso qualcosa ... ma stanno utilizzando ICC ??

Per adesso no. Ma stanno discutendo delle ottimizzazioni possibili.
Il tutto è nato da un utente legato in qualche modo a intel: rjs5
Il quale "spinge" in maniera esplicita il compilatore icc.
Al momento, nessuno ha pubblicamente evidenziato il collegamento con intel.
Sono dati pubblici, chi vuole: cerca.
E se lavora per intel, è ovvio che conosca bene icc.
IMO, forse ci faceva più bella figura se non insisteva con le super-feature dei nuovi processori intel.
Mi sembra quasi uno spot pubblicitario.

Ci sono delle novità per quanto riguarda la gestione del codice sorgente di Rosetta, prima limitato alle sole Università/centri di ricerca:

Would anyone want to or would know someone who would want to help optimize the Rosetta software, at the compiler level or even at the code level? It is freely available through an Academic license but we can also provide it to individuals under the same license agreement. This offers a great opportunity for you all to contribute directly and have direct positive impact for all researchers who use Rosetta and the optimizations would carry over to Rosetta@home.

Se conoscete Fortran e/o C++ non siate timidi!!

Effinalmente sono cominciati i test sulle applicazioni ottimizzate:

I added the Windows (SSE2) and linux (64bit SSE4) builds to Ralph@home and the linux app has a 28% failure rate.

The Windows app looks good at a 97% success rate. The current 32bit linux app also has a 97% success rate which is expected.

I'll have to look into the 64bit linux app failures and see what's actually going on. For the linux build I used the sse4 optimization option, a more current GCC, and a 64bit build which gave around a 13% improvement.

Alcuni post sopra avevo evidenziato che le maglie per poter accedere ai sorgenti di Rosetta forse si stavano allargando, ed ecco la conferma:

We don't have much time/resources to test these optimizations and it would be great of any of you would like to volunteer to help. As stated before, we can provide the source, build instructions, and tests. If you are interested please contact me directly at dekim AT u.washington.edu

Contattate Dekim e cominciate a lavorarci!!

P.S.
Strano che non abbiano risorse, sono uno dei progetti più grossi del panorama boinc, con svariati tecnici/ricercatori...

boboviz ha scritto:

Strano che non abbiano risorse, sono uno dei progetti più grossi del panorama boinc, con svariati tecnici/ricercatori...

classico esempio che i CASP non si vincono con un codice perfetto, ma prima di tutto mettendo idee dentro al codice
BTW in che linguaggio è il codice ?
a proposito, ho provato a elaborare di nuovo su questo progetto ma su 3 WU 2 le ha inviate, l'altra è rimasta incastrata in uploading, ma dallo stato del server sembrerebbe tutto a posto ...

…è da oltre 24 ore che le WU sono in "Invio in corso"…che succede?

astroale ha scritto:

BTW in che linguaggio è il codice?

Leggi un paio di post sopra.

Gattorantolo ha scritto:

…è da oltre 24 ore che le WU sono in "Invio in corso"…che succede?

E' scritto nei forum: c'è stata una tempesta e un power fault all'università
Stanno facendo ripartire il tutto

E la versione 3.62 arriva anche in produzione su Rosetta.

Aspettiamo, però, quella con le ottimizzazioni

Il codice è talmente nuovo che i server non sono in grado di "leggere" correttamente gli output di alcuni tipi di simulazioni, tipo le FFD_
Stanno aggiornando gli script lato server per ovviare al problema.
Sarebbero, a mio avviso, pure da cambiare stì server!

boboviz ha scritto:

Il codice è talmente nuovo che i server non sono in grado di "leggere" correttamente gli output di alcuni tipi di simulazioni, tipo le FFD_
Stanno aggiornando gli script lato server per ovviare al problema.
Sarebbero, a mio avviso, pure da cambiare stì server!

eh se lo abbiamo fatto pure noi....