3 ms·

Can I in theory build one optimised for running one program? Will it be of any benefit?

• riffraff 6y ago
  yes, but it depends on the program, that's what the whole ASIC industry for bitcoin mining is.
  • navanchauhan 6y ago
    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
• mhh__ 6y ago
  If we end up using technology like Clash it might be "trivial" to go from software to HDL (I.e. exploiting Haskell's compartmentalisation).
• Symmetry 6y ago
  Generally you get somewhere between 2 and 3 orders of magnitude power/performance benefit from realizing an algorithm in hardware if it's suitable for that sort of thing. If you're dealing with random memory accesses from a large pool it won't be but streaming tasks like media codecs or encryption work really well.