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 th

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