ARGOMENTO:

110 core

Il progetto è stato presentato alla conferenza Hot Chips in California e si tratta di un microprocessore general purpose in fase ancora sperimentale: "Non è una tecnologia che puoi comprare per Natale", ha ironizzato Lis durante la presentazione

Peccato, ci avrei fatto un pensierino per Santa Lucia....
Urca, adesso che ci penso, un progetto come Rosetta che chiede in media 7/800 Mb di ram per core....700*110=77 gb di ram!!!

boboviz ha scritto:

110 core

Il progetto è stato presentato alla conferenza Hot Chips in California e si tratta di un microprocessore general purpose in fase ancora sperimentale: "Non è una tecnologia che puoi comprare per Natale", ha ironizzato Lis durante la presentazione

Peccato, ci avrei fatto un pensierino per Santa Lucia....
Urca, adesso che ci penso, un progetto come Rosetta che chiede in media 7/800 Mb di ram per core....700*110=77 gb di ram!!!

Lo voglio!
Non fate leggere questo messaggio a Bax che se lo compra subito
Ma perchè Rosetta non può fare un'applicazione multithread ?

astroale ha scritto:

Ma perchè Rosetta non può fare un'applicazione multithread ?

Ti giro la risposta che mi diede uno degli admin di Ralph a cui feci la stessa domanda:

Multi-threading would be a headache to support for no practical gain. Protocols typically function by taking a single structure through a series of steps, which means there's choke points which would limit the speed increase you'd get from multithreading. Rosetta is really set up for trivial parallelism. Instead of multithreading a single structure, the better way to handle multiple CPUs is to run multiple structures at the same time, and the easiest way of doing that is to run multiple independent instances of the program. (Which happens to be a good match for the boinc setup.)

boboviz ha scritto:

astroale ha scritto:

Ma perchè Rosetta non può fare un'applicazione multithread ?

Ti giro la risposta che mi diede uno degli admin di Ralph a cui feci la stessa domanda:

Multi-threading would be a headache to support for no practical gain. Protocols typically function by taking a single structure through a series of steps, which means there's choke points which would limit the speed increase you'd get from multithreading. Rosetta is really set up for trivial parallelism. Instead of multithreading a single structure, the better way to handle multiple CPUs is to run multiple structures at the same time, and the easiest way of doing that is to run multiple independent instances of the program. (Which happens to be a good match for the boinc setup.)

Boh, non è che abbia capito molto la risposta
in pratica ti dicono che non ci sarebbe un guadagno di velocità con il MT, ma risparmio di RAM ?
forse considerano sottinteso che la maggior parte della RAM usata dal processo è usata per la "struttura", quindi col MT non avresti un gran risparmio ...

astroale ha scritto:

Boh, non è che abbia capito molto la risposta
in pratica ti dicono che non ci sarebbe un guadagno di velocità con il MT, ma risparmio di RAM ?
forse considerano sottinteso che la maggior parte della RAM usata dal processo è usata per la "struttura", quindi col MT non avresti un gran risparmio ...

Pure le risposte per un eventuale client gpu non le ho mai capite fino in fondo.
Dicono che sarebbe un lavoro pesante adeguare il codice ma, caspita, si parla di uno dei gruppi di ricerca più grandi. Tra le varie figure, sono in circa 60 persone.....

boboviz ha scritto:

Pure le risposte per un eventuale client gpu non le ho mai capite fino in fondo.
Dicono che sarebbe un lavoro pesante adeguare il codice ma, caspita, si parla di uno dei gruppi di ricerca più grandi. Tra le varie figure, sono in circa 60 persone.....

... e dire che quelli di Asteroid hanno fatto le applicazioni ottimizzate.... io penso che sia un discorso diverso, come se avessero poca voglia di impegnarsi, perfino loro

boboviz ha scritto:

astroale ha scritto:

Boh, non è che abbia capito molto la risposta
in pratica ti dicono che non ci sarebbe un guadagno di velocità con il MT, ma risparmio di RAM ?
forse considerano sottinteso che la maggior parte della RAM usata dal processo è usata per la "struttura", quindi col MT non avresti un gran risparmio ...

Pure le risposte per un eventuale client gpu non le ho mai capite fino in fondo.
Dicono che sarebbe un lavoro pesante adeguare il codice ma, caspita, si parla di uno dei gruppi di ricerca più grandi. Tra le varie figure, sono in circa 60 persone.....

ReLeon ha scritto:

... e dire che quelli di Asteroid hanno fatto le applicazioni ottimizzate.... io penso che sia un discorso diverso, come se avessero poca voglia di impegnarsi, perfino loro

Non conoscendo gli algoritmi, non posso sbilanciarmi più di tanto, ma fosse vero che la maggior parte della RAM impiegata da Rosetta sono i dati del modello, allora moltiplicare questo utilizzo su GPU da 2000 shaders significherebbe richiedere tera di RAM sulla GPU. Per aggirare il problema magari esistono soluzioni ma sicuramente sono complesse e questo potrebbe rallentare troppo il processo di sviluppo-test-sviluppo, infatti se ben ricordo Rosetta (tramite il progetto di test) cambia frequentemente versione di client sperimentando continuamente nuove soluzioni, cosa che non fà ad es. asteroids dove il problema sembra molto più "standard" e l'algoritmo fisso.
Bon qui termino la difesa d'ufficio di Rosetta

Altra cosa che secondo me non li portano a fare dei client ottimizzati (parlo di SSE, ecc...) è che a parità di modello è molto probabile trovarsi risultati diversi.

Avevo letto un po' di tempo fa di un articolo dell'admin di lhc che era riuscito ad ottenere gli stessi risultati con ottimizzazioni e processori diversi ma ha dovuto creare un codice ad hoc per ottenere questo

astroale ha scritto:

Non conoscendo gli algoritmi, non posso sbilanciarmi più di tanto, ma fosse vero che la maggior parte della RAM impiegata da Rosetta sono i dati del modello, allora moltiplicare questo utilizzo su GPU da 2000 shaders significherebbe richiedere tera di RAM sulla GPU. Per aggirare il problema magari esistono soluzioni ma sicuramente sono complesse e questo potrebbe rallentare troppo il processo di sviluppo-test-sviluppo, infatti se ben ricordo Rosetta (tramite il progetto di test) cambia frequentemente versione di client sperimentando continuamente nuove soluzioni, cosa che non fà ad es. asteroids dove il problema sembra molto più "standard" e l'algoritmo fisso.
Bon qui termino la difesa d'ufficio di Rosetta

Il problema, come hanno detto sempre loro, è proprio la saturazione della memoria nel passaggio ram gpu/ram cpu.
Il sogno di molti "fan" di rosetta era di un fork del codice o di un sottoprogetto (come poem, che su gpu fa girare solo alcune cose), ma gli admin hanno detto che per adesso nisba.
Per quanto riguarda il progetto di test di Rosetta (Ralph) stendiamo un pietoso velo....