[POEM@Home] Topic Ufficiale

[Gabi.2437]

figuriamoci se in italia fan trasmissioni del genere

[showa]

Ovvio...

[Gabi.2437]

Ieri su Italia Uno c'era un fantastico programma su una manza peggio di quelle di howard che alè si doveva rifare le tette e tutto e il programma parlava di lei che arrivava alla clinica e poi dell'operazione, filmata IN ESCLUSIVA!!

Ah, la grande televisione di qualità italiana

[showa]

Un po' mi sto bagnando, anche se capisco sia prematuro:
http://boinc.fzk.de/poem/forum_thread.php?id=350#3228

Per chi dice sempre tl;dr, stanno studiando per usare le GPU in questo progetto.

[Gabi.2437]

[showa]

Speriamo sia presto:

Message 3281 - Posted 12 Oct 2009 15:21:11 UTC - in response to Message 3280. Hi everybody,

first of all: thanks for the links and all the information.

We are porting mainly the crunching intensive energy functions to GPUs using OpenCL, which is cross-plattform; not nvidia bound.

If my gpu-overview regarding nvidia gpus is still up-to-date nvidia is implementing more and more language bindings and compilers for their CUDA libraries.
While it is convenient to write in another language than CUDA directly, in our case it is not necessary. Even if it was possible to translate the complete POEM application using a C-to-CUDA compiler, the performance would be a lot worse than on a CPU.

This is because GPUs are very good at data-parallel workloads and a lot worse than a normal CPU at 'conventional' work-loads.

In the current codebase 99% of all cpu time is invested into the evaluation of our energy functions. Therefore the usual approach is to write all the setup code for execution on the cpu and write function kernels of the energy functions for the GPU. Most (not all) of the energy functions are also data-parallel. Therefore they will run a lot faster on the GPU.
It doesn't matter here in which language you write them (OpenCL or CUDA or brook+) as they all rely on the same concepts. This is being done now in the writing of the next POEM application generation in OpenCL (because it's cross-plattform).

Best regards,
Timo

[Gabi.2437]

La parola CUDA e nvidia appare troppe volte lì in mezzo, non mi piace

[showa]

Beh, ma loro sembra stiano usando OpenCL, che dovrebbe essere cross-platform. No? Se fosse così, e se andasse davvero in porto quel loro progetto, si potrebbe macinare per Poem sia con Nvidia che Ati. Magari.

[showa]

Le prime wu per gpu dovrebbero essere rilasciate durante il prossimo CASP:

http://boinc.fzk.de/poem/forum_thread.php?id=384

Fosse davvero così, ne sarei MOLTO felice!!

[Gabi.2437]

Uao, speriamo bene

[showa]

Un paio di news:

(dal loro forum)

Posted 28 May 2010 15:35:40 UTC
Hi everybody,
the new App will first be released as a non-gpu SIMD app, because there is an ongoing discussion on the BOINC mailing list saying that it is currently not possible to pack the OpenCL libs in a portable way. This should hopefully be resolved with the newer NVidia and AMD drivers incorporating OpenCL by default, but that's unsure.
Currently we testdrive the new App on the local clusters here to generate structures for CASP and plan to roll it out middle of the currently running CASP to also use it for the relaxation done in the old POEM on POEM@HOME.
Best,
Timo
Posted 28 May 2010 15:35:40 UTC Hi everybody,


(dalla home page)
June 02 , 2010 - CASP 9 T531 news, T540 and T544

The modeling of T531 can be considered a success. We found in total three dominant folds, which were all quite stable in the POEM forcefield, but only one had the disulfide bridges all developed. We will submit all three folds to CASP with the first one being the one with all disulfide brigdes developed - expect pictures on tuesday. Following will be a very short relaxation of T540 as job CASP442 and a longer relaxation of T544 as job 443. Job 445 will be a regular data job simulating the docking of Antithrombin with some protein ligands.

[showa]

Nessuna nuova wu... molto brutto, specie durante il CASP.....

[lucabeavis]

Le lunghe WUs di POEM++ 0.05 funzionano o alla fine danno errore? Tempo fa era successa una cosa analoga...

[showa]

Appena finisco di elaborare per HFCC mi dedico a Poem, almeno per raggiungere il milione. E' un po' che non elaboro... ero rimasto alla versione ++ 0.02, pensa te

[lucabeavis]

Appena finisco di elaborare per HFCC mi dedico a Poem, almeno per raggiungere il milione. E' un po' che non elaboro... ero rimasto alla versione ++ 0.02, pensa te

Vanno avanti finché le lasci andare Dopo 20 ore me ne aveva aggiunte altre 30 quando sembrava che fosse alla fine. Passo a WCG per un po', non mi piace fare beta-testing.

[showa]

Mar 30 , 2011 - Bug fixed, new POEM++ incoming.
English: There's a new POEM++ version incoming, as we got the bug. Although it was only a minimal bug (the program ran fine all the time until the end), it was not that easy to spot. Due to a cosmetical change in the code, the program returned 0 after a successful run in the main function. BOINC jobs however have to call boinc_finish(0); at the end. BOINC interprets a successful returncode as a checkpoint it seems and (as we didn't generate a checkpoint at the end) started from 0 again. We are sorry that this happened and changed our testing strategy for it to not happen again. The reason why this didn't occur on the testserver was simple: We have an additional -debug flag there, when we start the job. This starts BOINC in diagnostic mode. In this case the code branched and exited correctly. Now we have completely replicated the POEM@HOME production setup so that there are no differences anymore.

[lucabeavis]

Mar 30 , 2011 - Bug fixed, new POEM++ incoming.
English: There's a new POEM++ version incoming, as we got the bug. Although it was only a minimal bug (the program ran fine all the time until the end), it was not that easy to spot. Due to a cosmetical change in the code, the program returned 0 after a successful run in the main function. BOINC jobs however have to call boinc_finish(0); at the end. BOINC interprets a successful returncode as a checkpoint it seems and (as we didn't generate a checkpoint at the end) started from 0 again. We are sorry that this happened and changed our testing strategy for it to not happen again. The reason why this didn't occur on the testserver was simple: We have an additional -debug flag there, when we start the job. This starts BOINC in diagnostic mode. In this case the code branched and exited correctly. Now we have completely replicated the POEM@HOME production setup so that there are no differences anymore.

Questo l'avevo visto anch'io, è sulla home page. Però non hanno risolto un bel niente perché a me è successo dopo il 30 marzo. Va beh..

[showa]

Ah, ok

[showa]

Sempre parlando di GPU computing, anche questo progetto supporta le gpu.

New client binaries released
The new POEM applications have been released this morning. This update also includes the long awaited NVIDIA OpenCL support for Windows.
I hope everything works as it should. If you encounter problems nevertheless, please inform us in this thread.

In realtà, un topic apposito sulle tematiche del gpu computing non l'ho trovato. C'è come al solito da settare, nelle preferenze nella pagina POEM@Home Preferences, "use ati o Nvidia Gpu".

Sinceramente ho uno spaventoso vuoto di memoria: non ricordo più se "impalla" il pc l'uso della gpu come per HFC

[showa]

Sto tornando a macinare wu per gpu: il pc risponde come se non stesse lavorando. Probabilmente perché il carico sulla gpu è "basso": gpu-z mi segnala il 54% di load (ho una 560-Ti, e non ho eventualmente configurato alcun .xml per Poem in maniere "particolari". D'altro canto, ho solo una scheda video, e mi semplifica la vita in questo caso).
D'altro canto, queste wu sono più lunghe di quelle per HFC.