ARGOMENTO:

Però non dimentichiamo che il software attuale, sebbene inefficiente, è stato largamente testato. La cosiddetta reingegnerizzazione potrebbe fare al caso loro, ma così come una completa riscrittura del codice necessiterebbe di un grande numero di ore-uomo.

Riscrivere "da raw" il codice sarebbe un delirio. D'altro canto è uno dei team più corposi, al codice partecipa un sacco di gente e siamo nel 2016: vedere codice così mal ottimizzato fa male al cuore.

Rjs5 lo spiega bene in un post successivo:

Each developer has added their changes and Rosetta code complexity incrementally grew. Changes accumulate whether they are correct or not .... as long as there are no errors detected. Goofy code gets added. Many times it is hard to see and rarely does anyone have the courage to remove the problem code.

The 64-bit Rosetta binary has a couple functions that use the old MMX instructions to do 64-bit operations. The MMX instructions are "aliased" to the FP registers and if you use them, then you have to reset the FP registers. The program will stall 30 to 50 cycles on the next FP operation.This is a Rosetta error where the source code references the "__m64" datatype and forces the compiler to use the MMX registers instead of the XMM registers. There is really no reason this 64-bit code even needs to use MMX or XMM. Just use its 64-bit registers.

Dovrei avere ancora un Pentium II MMX da qualche parte......
Altrochè le Avx.....

proprio per i motivi ben spiegati da questo Rjs5, sono sempre più convinto che l'unico modo per uscirne è ripartire da zero.
Una patch aggiunta adesso rischia di spostare i "bachi" da un altra parte, e poi non è detto che lo sforzo di ottimizzare una forse piccola parte (per ora ha individuato due funzioni) dia risultati sperati.
Magari proprio l'impostazione generale, direi architetturale, sarebbe tutta da rivedere. Non parliamo poi della possibilità di usare GPU !!!!

Beh, intanto complimenti a rjs5 che guarda davvero dentro al codice invece di limitarsi a ricompilare.
Poi, aumentare i crediti sarebbe ingiusto verso i precedenti volontari e non velocizzerebbe le ricerche/esperimenti in corso.
Vista la situazione di "spaghetti-code" forse dovrebbero prendere in considerazione l'ipotesi di assumere a tempo pieno uno sviluppatore che gli faccia manutenzione al codice e/o riscriva tutto da capo. Personalmente, visto che rosetta@home funziona e produce risultati, inizierei con il ripulire/riordinare il codice.
Credo avrebbe lavoro da fare fino all'età della pensione.

Facessero assunzioni qua da noi, magari riescono a risolvere i problemi di disoccupazione in Italia.

Se effettivamente neanche lo staff è al corrente dell'intero significato del sorgente in loro possesso, potrebbero provare a darlo in pasto a doxygen. Chissà, magari ne capiscono qualcosa in più. Io rimango dell'idea che si può far ritoccare il codice a una o più mani esperte, poco alla volta.

xdarma ha scritto:

Vista la situazione di "spaghetti-code" forse dovrebbero prendere in considerazione l'ipotesi di assumere a tempo pieno uno sviluppatore che gli faccia manutenzione al codice e/o riscriva tutto da capo. Personalmente, visto che rosetta@home funziona e produce risultati, inizierei con il ripulire/riordinare il codice.

Forkare il codice e riscriverlo da zero (mentre il vecchio codice rimane in produzione).

Nubman ha scritto:

Se effettivamente neanche lo staff è al corrente dell'intero significato del sorgente in loro possesso, potrebbero provare a darlo in pasto a doxygen. Chissà, magari ne capiscono qualcosa in più.

Bell'idea!! L'ho rigirata a Rjs5.
Quello che mi preoccupa, più di tutto, è che gli admin del progetto sembrano particolarmente disinteressati alla cosa: non rispondono alle mail di Rjs5, non partecipano ai thread riguardanti le ottimizzazioni, ecc.
Direi che con questo atteggiamento non si procede di molto.

boboviz ha scritto:

Riscrivere "da raw" il codice sarebbe un delirio. D'altro canto è uno dei team più corposi, al codice partecipa un sacco di gente e siamo nel 2016: vedere codice così mal ottimizzato fa male al cuore.

Rjs5 lo spiega bene in un post successivo:

Each developer has added their changes and Rosetta code complexity incrementally grew. Changes accumulate whether they are correct or not .... as long as there are no errors detected. Goofy code gets added. Many times it is hard to see and rarely does anyone have the courage to remove the problem code.

The 64-bit Rosetta binary has a couple functions that use the old MMX instructions to do 64-bit operations. The MMX instructions are "aliased" to the FP registers and if you use them, then you have to reset the FP registers. The program will stall 30 to 50 cycles on the next FP operation.This is

a Rosetta error where the source code references the "__m64" datatype and forces the compiler to use the MMX registers instead of the XMM registers. There is really no reason this 64-bit code even needs to use MMX or XMM. Just use its 64-bit registers.

Dovrei avere ancora un Pentium II MMX da qualche parte......
Altrochè le Avx.....

quanto lo capisco ... anche io sono costretto forzatamente a passare a gcc le MMX quando non dovrei perchè molte applicazioni o librerie lo richiedono ! ho provato a disabilitarlo globalmente e aggiungere singolrmente l applicazioni che lo richiedono ... praticamente ogni volta devo aggiungere , aggiungere ...e alla fine lo tengo globalmente. ... però è uno spreco di "cicli" nel tempo

A questo punto, però ci sono cose che non capisco.
1) Il codice viene scritto sotto Linux e poi compilato anche per Windows o viceversa? Io avevo capito che usavano Visual Studio per il codice e poi gcc per la compilazione. Boh.
2) Perchè gli admin sono così disinteressati alle ottimizzazioni? Anche solo un 10% in più, corrisponderebbero ad una potenza aggiuntiva di migliaia di core.

E comunque il piano di battaglia di Rjs5 mi sembra chiaro:

1. capture an executing Rosetta BOINC "slot" directory and verify that I can execute the Rosetta work unit stand alone and get the Rosetta answer repeatedly.
2. figure out how to build a standard Rosetta binary that I can substitute into that slot directory and get the same answer.
3. determine if Rosetta or the build process can be changed to make a substantial difference in performance.

I am not optimistic about making any difference.

I fully expect that there is no real need nor incentive for Rosetta to mess with the code to improve performance

P.S. Lo so che mi attirerò le ire di Xdarma e so pure che è un pro-Intel, ma a me stò rjs5 comincia a starmi simpatico.

è uscita la nuova versione 3.68, con un discreto batch.
peccato che moltissime WU vadano in "Validate error" dopo pochissimi minuti di elaborazione

zioriga ha scritto:

è uscita la nuova versione 3.68, con un discreto batch.
peccato che moltissime WU vadano in "Validate error" dopo pochissimi minuti di elaborazione

Per ora nessun problema con questa versione (incrociando le dita).
Piuttosto: carina la nuova grafica, ma un pò incoerente. Gli ho girato sul forum qualche suggerimento.

P.S.
Se hai tempo/voglia/ecc, segnala questi errori sul loro forum, sottolineando la versione del client boinc e l'OS che usi

Hanno fermato il batch e lunedì dovrebbe uscire la nuova versione che risolve il bug presente.

boboviz ha scritto:

Hanno fermato il batch e lunedì dovrebbe uscire la nuova versione che risolve il bug presente.

E' uscita ieri sera la versione 3.70 per tutti gli OS
Gli errori sembrano decisamente in calo!!!

La versione 3.71, uscita stanotte, va a risolvere alcuni bug....

Fate spesa di ram.
Quelli di Ralph stanno rilasciando delle wu che richiedoo 4 gb di ram cadauna

boboviz ha scritto:

Fate spesa di ram.
Quelli di Ralph stanno rilasciando delle wu che richiedoo 4 gb di ram cadauna

sabayonino ha scritto:

boboviz ha scritto:

Fate spesa di ram.
Quelli di Ralph stanno rilasciando delle wu che richiedoo 4 gb di ram cadauna

E, infatti, mi vanno tutte in errore di memoria.....

boboviz ha scritto:

sabayonino ha scritto:

boboviz ha scritto:

Fate spesa di ram.
Quelli di Ralph stanno rilasciando delle wu che richiedoo 4 gb di ram cadauna

E, infatti, mi vanno tutte in errore di memoria.....

Perchè non metti il max_concurrent nell app_config di ralph ? Cosí limiiti l elaborazione ad una sola wu

sabayonino ha scritto:

boboviz ha scritto:

sabayonino ha scritto:

boboviz ha scritto:

Fate spesa di ram.
Quelli di Ralph stanno rilasciando delle wu che richiedoo 4 gb di ram cadauna

E, infatti, mi vanno tutte in errore di memoria.....

Perchè non metti il max_concurrent nell app_config di ralph ? Cosí limiiti l elaborazione ad una sola wu

Sinceramente queste politiche non le capisco...

sabayonino ha scritto:

Perchè non metti il max_concurrent nell app_config di ralph ? Cosí limiiti l elaborazione ad una sola wu

Potrei pure farlo, ma non mi va di usare metà della mia ram disponibile per una sola wu (adesso ho 8 gb).
Con l'altra metà dovrei gestire sistema, antivirus, programmi e altri 5 core liberi.

Piuttosto ho visto moduli da 8 gb a 35 euro. Ne prendo 2/3 e non ci penso più

P.S.
Tra l'altro, il messaggio è ancora più inquietante.

05/02/2016 09:21:56 | ralph@home | Rosetta Mini needs 7629.39 MB RAM but only 7356.70 MB is available for use.

Spero NON si riferisca alla singola wu, altrimenti son dolori