3 ms·

I was thinking about AutoDock Vina ( Molecular Docking Software ), I have literally 0 knowledege about hardware :( Then again, this is going to be a really fun

I was thinking about AutoDock Vina ( Molecular Docking Software ), I have literally 0 knowledege about hardware :( Then again, this is going to be a really fun experience

dekhn 6y ago
Yes, you can build dedicated ASICs. No, it's not worth it for docking software.
- ascorbic 6y ago
  According to Wikipedia there has been some success building FPGAs for Autodock, so maybe it could be. https://en.m.wikipedia.org/wiki/AutoDock https://en.m.wikipedia.org/wiki/AutoDock
  - dekhn 6y ago
    yes but since drug discovery isn't bottlenecked by virtual docking throughput, it doesn't matter. We've seen similar approaches applied to BLAST, and in the end, everybody ends up giving up the ASIC or the FPGA because it's not cost effective long-term.
exikyut 6y ago
I initially did an image search to get a quick idea of what you were referring to. "Oh, that looks commercial/expensive..." - but no, it's open source, under the Apache license. Which means the only question is how motivated you really are to speed it up. If your answer is "really really __REALLY__ motivated", then... - Reimplement the whole thing, in your choice of language, strictly without consideration of performance, to concretely grasp the implementation. - Rewrite your reimplementation efficiently, using profiling etc, and using SSE/AVX or related techniques if/as possible. (I noticed references to Monte Carlo simulation in the code, and found some noise online that suggests this is vectorizable. I don't understand how MC is being used in the code though.) FWIW assembly language is likely 95-99% not worth chasing instead of Rust or C; one of the few real-world scenarios that call for asm is software video decode/encode, which boils down to patterns of hardcore number crunching that compilers are regarded to optimize poorly. I do not know whether this program is slow because it is poorly optimized or slow because it is simply computationally expensive. - Rewrite your implementation to run on a GPU, if possible, using OpenMP or CUDA. (This may require implementing your own engine that achieves the same goals as the existing engine, after you achieve a high-level understanding of why the engine works the way it does, because you may need to rearchitect the way the program works in order to cram it into a GPU.) - Reimplement your implementation in VHDL so it will run on an FPGA. - Retarget your VHDL so it can be fabbed on a fixed-function ASIC. This would be my high-level Handwavy Armchair Guide to achieving what you want :) It's possible that the GPGPU or FPGA milestones will give you a significantly appreciable many-x performance boost. That may be 2x or 10x or 100x; you will be able to find out what is possible almost immediately, as you build your brain-dead implementation and go down little research/analysis paths figuring out how everything works. It's also possible that the current implementation is poorly designed, and that sticking a profiler on it may find low hanging fruit. Likewise, it's equally possible the current implementation is well-tuned above average (despite being written in C++). Oh, I found this random link that may be uninteresting or useful: https://news.ycombinator.com/item?id=18628326 https://news.ycombinator.com/item?id=18628326

I was thinking about AutoDock Vina ( Molecular Docking Software ), I have literally 0 knowledege about hardware :( Then again, this is going to be a really fun experience

dekhn 6y ago

Yes, you can build dedicated ASICs. No, it's not worth it for docking software.

ascorbic 6y ago
According to Wikipedia there has been some success building FPGAs for Autodock, so maybe it could be. https://en.m.wikipedia.org/wiki/AutoDock https://en.m.wikipedia.org/wiki/AutoDock
- dekhn 6y ago
  yes but since drug discovery isn't bottlenecked by virtual docking throughput, it doesn't matter. We've seen similar approaches applied to BLAST, and in the end, everybody ends up giving up the ASIC or the FPGA because it's not cost effective long-term.

exikyut 6y ago

I initially did an image search to get a quick idea of what you were referring to. "Oh, that looks commercial/expensive..." - but no, it's open source, under the Apache license. Which means the only question is how motivated you really are to speed it up. If your answer is "really really __REALLY__ motivated", then... - Reimplement the whole thing, in your choice of language, strictly without consideration of performance, to concretely grasp the implementation. - Rewrite your reimplementation efficiently, using profiling etc, and using SSE/AVX or related techniques if/as possible. (I noticed references to Monte Carlo simulation in the code, and found some noise online that suggests this is vectorizable. I don't understand how MC is being used in the code though.) FWIW assembly language is likely 95-99% not worth chasing instead of Rust or C; one of the few real-world scenarios that call for asm is software video decode/encode, which boils down to patterns of hardcore number crunching that compilers are regarded to optimize poorly. I do not know whether this program is slow because it is poorly optimized or slow because it is simply computationally expensive. - Rewrite your implementation to run on a GPU, if possible, using OpenMP or CUDA. (This may require implementing your own engine that achieves the same goals as the existing engine, after you achieve a high-level understanding of why the engine works the way it does, because you may need to rearchitect the way the program works in order to cram it into a GPU.) - Reimplement your implementation in VHDL so it will run on an FPGA. - Retarget your VHDL so it can be fabbed on a fixed-function ASIC. This would be my high-level Handwavy Armchair Guide to achieving what you want :) It's possible that the GPGPU or FPGA milestones will give you a significantly appreciable many-x performance boost. That may be 2x or 10x or 100x; you will be able to find out what is possible almost immediately, as you build your brain-dead implementation and go down little research/analysis paths figuring out how everything works. It's also possible that the current implementation is poorly designed, and that sticking a profiler on it may find low hanging fruit. Likewise, it's equally possible the current implementation is well-tuned above average (despite being written in C++). Oh, I found this random link that may be uninteresting or useful: https://news.ycombinator.com/item?id=18628326 https://news.ycombinator.com/item?id=18628326