I heard a comment from Dr. David Baker towards the end of http://twit.tv/show/futures-in-biotech/92
I can't recall an exact quote, and haven't listened to it again, but he was saying something like Rosetta@Home doesn't use the GPU because it would involve too much going back and forward between the CPU and GPU.
I heard a comment from Dr. David Baker towards the end of http://twit.tv/show/futures-in-biotech/92
I can't recall an exact quote, and haven't listened to it again, but he was saying something like Rosetta@Home doesn't use the GPU because it would involve too much going back and forward between the CPU and GPU.
I heard a comment from Dr. David Baker towards the end of http://twit.tv/show/futures-in-biotech/92
I can't recall an exact quote, and haven't listened to it again, but he was saying something like Rosetta@Home doesn't use the GPU because it would involve too much going back and forward between the CPU and GPU.
I see parallelization like this: we touch any segment/atom and all surrounding ones need to react somehow. Something like waves on water when you throw a rock into it.
The process seems to be sequential and difficult too parallelize. However, www.GPUGrid.net seems to have solved this issue and I would encourage the foldit team strongly to have a look.
It CAN be "really" parallel on GPU or multi core CPU.
Atoms "just" need be informed about changes around and respond to new conditions - there need be communication between threads.
Then every "cycle" we have "snapshot" of state that we can display, score and put to undo graph. Cycle length should be adjustable by user (longer on running scripts - no need to see all moves, shorter on manual work to see any change we want).
In my understanding out saves are bit upgraded PDB files. PDB is describing position and connections between atoms.