ARGOMENTO:

boboviz ha scritto:

Pure la versione ottimizzata per Arm, adesso....
In cosa differisce da quella di Rattorosso???

Il sorgente dovrebbe essere leggermente diverso:

Daniel ha scritto:

I have eliminated two top bottlenecks in code: testAndRemove is reduced to isnan and simple range check plus existing code for edge removal;

Per le ottimizzazioni dell'applicazione ARM, non ti so dire, ma Daniel dice che va un 30% più veloce.

Sto provando le app ottimizzate e vanno molto bene. Anche senza icc.

Le Vitis Vinifera ottimizzate durano pochi minuti (5/6)
E' normale? Sono ok queste wus??

boboviz ha scritto:

Le Vitis Vinifera ottimizzate durano pochi minuti (5/6)
E' normale? Sono ok queste wus??

Si, non tutte in realtà (sono 4 batch con parametri diversi) ma sono comunque molto più veloci di quelle di EC (e producono un file di output molto più grande). Fra un po` quando avremo testato a dovere il nuovo applicativo (per ora nessun problema), allungherò la durata delle wu ai tempi di prima.

Io sia con FMA che AVX ho quasi dimezzato i tempi, però la cpu è ancora fresca. Che ci siano ancora margini di miglioramento?

Ho avuto conferma che TN-Grid e` stato scelto come progetto per il Charity Event 2017 (challenge). Ricordo che le regole qui sono diverse da solito, in pratica si tratta di cambiare momentaneamente team (solo per questo progetto) per la durata del challenge. Qui maggiori informazioni pratiche . Per quella data dovrei aver
a) messo le app ottimizzate al posto di quelle solite
b) raddoppiato la durata delle workunits
c) fatto un upgrade della parte boinc server (incrociando le dita....)

inoltre il team gridcoin sta valutando (con una votazione online tra i membri) se includere TN-Grid nella loro whitelist (i progetti che supportano), se questo accadrà aspettatevi le solite sfide di gridcoin

buon anno a tutti!

bene ... lavoro intensificato anche per te Valter

segnalo inoltre che TN-Grid è stato incluso anche nel trophy di Formula-Boinc-2017

E le versioni SSE2 diventano quelle ufficiali!!!!
Pure i miei processori scrausi riescono a reggerle e a contribuire al progetto

Sembra che valterc dovrà raddoppiare di nuovo la dimensione delle wu

gene.disi.unitn.it/test/forum_thread.php?id=135&postid=780

rattorosso ha scritto:

Sembra che valterc dovrà raddoppiare di nuovo la dimensione delle wu

gene.disi.unitn.it/test/forum_thread.php?id=135&postid=780

C'è un gran fermento nel forum, tra chi mette le mani in pasta e chi guarda.

E' stato veramente utile rendere pubblico ( o quasi ) il progetto, se questi sono i risultati.

Nuovi esperimenti in arrivo per il "vermicello Coli" (lo proporrei alla nomination di qualcosa di importante... )

Si accenna anche ad una competizione con altri team di ricerca ( DREAM5 ) che operano sullo stesso metodo di ricerca .

DREAM network inference challenge

The DREAM initiative organizes an annual reverse engineering "competition" (we prefer to see it as a community experiment) called the DREAM challenges. We use GNW to provide the so-called DREAM network inference challenge.

The goal of this challenge is to predict network connectivities from real (in vivo) and simulated (in silico) gene expression datasets. The true structure of the gene networks is revealed only after the submission of the predictions. In addition to inference of network structure, we also encourage prediction of gene expression measurements for specific conditions that we withhold from the training data.

@Valter : meglio che tu vada a prendee qualche WD-Black (per NAS) , o un bel WD-Red , un bel ampliamento mi sa che lo dovrai fare

New application (v 0.11)
In the next few hours the new v1.1 optimized applications made by Daniel will be promoted as the official ones (version 0.11). This version is faster than the previous one. If you are using the anonymous platform and want to safely 'come back' remember to: wait until the workunits queue is empty, stop boinc, delete app_info.xml, start boinc. 6 Feb 2017, 11:31:51 UTC

@valterc: le nuove wu di TN-Grid, mi fan scaccolare la cpu tra il 98% e il 99% contro le precedenti che lo tenevano fisso al 100%, ho visto che sono aumentate notevolmente di peso 6mb in upload, io con contratto a 11gb mese "causa non raggiunto dalla linea adsl" me li ciuccia tutti in 1sett se scaccolo h24...

MA19-GORICIZZA-86MI ha scritto:

@valterc: le nuove wu di TN-Grid, mi fan scaccolare la cpu tra il 98% e il 99% contro le precedenti che lo tenevano fisso al 100%, ho visto che sono aumentate notevolmente di peso 6mb in upload, io con contratto a 11gb mese "causa non raggiunto dalla linea adsl" me li ciuccia tutti in 1sett se scaccolo h24...

Se vai su questo Sito , puoi vedere quando dovrebbe ( ) arrivare la banda ultralarga nella tua città...

MA19-GORICIZZA-86MI ha scritto:

@valterc: le nuove wu di TN-Grid, mi fan scaccolare la cpu tra il 98% e il 99% contro le precedenti che lo tenevano fisso al 100%, ho visto che sono aumentate notevolmente di peso 6mb in upload, io con contratto a 11gb mese "causa non raggiunto dalla linea adsl" me li ciuccia tutti in 1sett se scaccolo h24...

Il problema e` abbastanza semplice, il ns database di E. Coli ha circa 4800 geni, mentre quello di V. Vinifera circa 28000 (le piante hanno il genoma più complesso in natura, più geni dei mammiferi), Inoltre, per motivi diciamo 'intrinsechi' il calcolo e` molto più veloce su Vv che su Ec. Per l'output, l'applicativo cerca relazioni a coppie tra geni, in teoria in Vv sono circa 28000^2/2, quindi e` normale che l'output sia più grosso.
Ogni 'espansione' (PC-IM) di un singolo gene e` composta da un certo numero di PC (nPC), in questo momento ce ne sono 350 per workunit. Se aumento nPC aumenta il tempo di calcolo e la dimensione del file di output. Se diminuisco nPC diminuisce il tempo di calcolo e il file di output ma aumenta il numero di workunits e quindi il numero di righe nel database. Quindi se p.es con nPC=350 ho mezza ora di calcolo e un file di ~6Mb, con nPC=150 ho 15 minuti di calcolo e un file di ~4Mb, alla fine ho comunque generato più traffico di rete. Insomma ci sono vari parametri da tenere in considerazione, li stiamo tenendo sotto controllo per capire la configurazione ottimale.
Il nuovo applicativo di Daniel e` parecchie volte più veloce dell'originale (4 o più), questo ovviamente e` molto buono ma paradossalmente ha amplificato queste problematiche.

Ciao, sbaglio o sono finite le workunits per questo progetto?

matteo-quatrida ha scritto:

Ciao, sbaglio o sono finite le workunits per questo progetto?

Abbiamo da risolvere il problema dei file di output troppo grandi. La soluzione c'è ma dobbiamo modificare leggermente l'applicativo. In teoria entro la prossima settimana si riparte a pieno regime. Nel frattempo andiamo lenti con le workunits, in questa situazione c'è da fare micro management e il weekend c'è anche altro da fare ..... Dopodiché lavoro ce ne sarà a iosa..

valterc ha scritto:

MA19-GORICIZZA-86MI ha scritto:

@valterc: le nuove wu di TN-Grid, mi fan scaccolare la cpu tra il 98% e il 99% contro le precedenti che lo tenevano fisso al 100%, ho visto che sono aumentate notevolmente di peso 6mb in upload, io con contratto a 11gb mese "causa non raggiunto dalla linea adsl" me li ciuccia tutti in 1sett se scaccolo h24...

Il problema e` abbastanza semplice, il ns database di E. Coli ha circa 4800 geni, mentre quello di V. Vinifera circa 28000 (le piante hanno il genoma più complesso in natura, più geni dei mammiferi), Inoltre, per motivi diciamo 'intrinsechi' il calcolo e` molto più veloce su Vv che su Ec. Per l'output, l'applicativo cerca relazioni a coppie tra geni, in teoria in Vv sono 28000!, quindi e` normale che l'output sia più grosso.
Ogni 'espansione' (PC-IM) di un singolo gene e` composta da un certo numero di PC (nPC), in questo momento ce ne sono 350 per workunit. Se aumento nPC aumenta il tempo di calcolo e la dimensione del file di output. Se diminuisco nPC diminuisce il tempo di calcolo e il file di output ma aumenta il numero di workunits e quindi il numero di righe nel database. Quindi se p.es con nPC=350 ho mezza ora di calcolo e un file di ~6Mb, con nPC=150 ho 15 minuti di calcolo e un file di ~4Mb, alla fine ho comunque generato più traffico di rete. Insomma ci sono vari parametri da tenere in considerazione, li stiamo tenendo sotto controllo per capire la configurazione ottimale.
Il nuovo applicativo di Daniel e` parecchie volte più veloce dell'originale (4 o più), questo ovviamente e` molto buono ma paradossalmente ha amplificato queste problematiche.

Grazie per l'info.

Ho cinque minuti liberi e vi aggiorno su quello che sta succedendo... Il problema più grosso da risolvere e` la dimensione del file di output rispetto al tempo di esecuzione della workunit, nel caso Vitis ~6Mb (compresso). Ora il nuovo applicativo che stiamo scrivendo dovrebbe risolvere completamente questo problema. Il nuovo file di output e` nella peggiore dell'ipotesi 679K, nel caso specifico sarà di 67K.
Questo fatto ci permetterà di creare workunit più lunghe (l'idea e` di circa una ora e mezza su un I7-4770), quindi in teoria meno traffico di rete, meno occupazione di disco lato server e il generatore di lavoro che dovrebbe starci dietro (ma stiamo cercando di ottimizzare anche quello)

Avremo quindi una nuova applicazione che si chiamerà "gene@home PC-IM", non possiamo semplicemente creare una nuova versione, perché l'ultima non e` ovviamente in grado di validare con la vecchia (file di output diversi). Quando sarà attiva chi avrà il app_info.xml (anonymous platform) non riceverà più alcun lavoro..... (perché il generatore di lavoro del vecchio applicativo verrà fermato)

Anche il sorgente della nuova applicazione verrà pubblicato?

TIA

valterc ha scritto:

Ho cinque minuti liberi e vi aggiorno su quello che sta succedendo... Il problema più grosso da risolvere e` la dimensione del file di output rispetto al tempo di esecuzione della workunit, nel caso Vitis ~6Mb (compresso). Ora il nuovo applicativo che stiamo scrivendo dovrebbe risolvere completamente questo problema. Il nuovo file di output e` nella peggiore dell'ipotesi 679K, nel caso specifico sarà di 67K.
Questo fatto ci permetterà di creare workunit più lunghe (l'idea e` di circa una ora e mezza su un I7-4770), quindi in teoria meno traffico di rete, meno occupazione di disco lato server e il generatore di lavoro che dovrebbe starci dietro (ma stiamo cercando di ottimizzare anche quello)

Avremo quindi una nuova applicazione che si chiamerà "gene@home PC-IM", non possiamo semplicemente creare una nuova versione, perché l'ultima non e` ovviamente in grado di validare con la vecchia (file di output diversi). Quando sarà attiva chi avrà il app_info.xml (anonymous platform) non riceverà più alcun lavoro..... (perché il generatore di lavoro del vecchio applicativo verrà fermato)

Ottimo ottimo....Rigiro il criceto su questo progetto.