Performances about lbm HOT 5 CLOSED

Hi @jviquerat,
nice! That is already a decent improvement! Yeah, that is what generally happens in Numba, you have to rewrite it in a C-style syntax with loops, losing the benefits of a lot of generic Numpy functions as most of them are only supported without additional parameters or not even supported at all. I'd do the same. If you happen to have some spare time port it to C++, after all you only have to think about the classes and not about the core functionality anymore and therefore it should take significantly less time.

In case you need anything then I can maybe give you some better advice as I have programmed several versions in C and C++. Just leave me a message over here in that case. I think in C++ you have to decide if you want to keep it generic or fast. I found manual loop unrolling there to be a lot faster than loops or loops with #pragma GCC unroll(n) but then the code turns into a ugly mess very soon. So in case you need it for training a net where performance is key, I'd choose basic C syntax. On the other hand if you want to have something that is easily maintainable I would use C++ with RAII. Basically isolate classes such as indexing, lattice and so on and create another class simulation that holds pointers to instances of those classes. Special features like the AA access pattern can then be implemented by inheritance. I have experimented with it a bit but I am still not sure what functions should be declared as virtual functions (and override in the derived class) and which I should simply declare non-virtual and inline. I have also started some month ago writing a new proprietary LBM framework for myself trying to make a more generic version, more generic than the C-style macro-based one I have done for university while trying to achieve the same performance and scalability. My current prototype achieves like 75% of the performance of the C-style one but is completely generic. I have not taken my time ever since but maybe I have further improved it until then.

You are welcome! I am really glad you improved the code that much and understand the method a lot better now. As already mentioned just hit me up if you decide to port it to C++. In the meanwhile I wish you good luck with your research and stay healthy. :)

from lbm.

As we are currently writing a much larger FEM code in cpp at the moment, you might find that article interesting, on the topic of the cost of virtualization and the cases where replacing with CRTP is interesting : https://eli.thegreenplace.net/2013/12/05/the-cost-of-dynamic-virtual-calls-vs-static-crtp-dispatch-in-c

from lbm.

Oh, nice, thanks! The article looks very informative. it is hard to find good resources and in particular benchmarks on the topic. :)

from lbm.

Nice, I was not aware of CRTP. This is actually a very smart strategy. I will try to compare it to devirtualisation (with virtual and final override) and see what impact it has on the performance on modern compilers. :) I think it might help me rewrite the indexing in a lot more generic way. Thanks a lot again!

from lbm.

Happy I could help :)
The FEM code I was talking about heavily relies on CRTP, and most often almost everything that would have been virtual gets inlined. The main downside is that compile time can rise rapidly.

from lbm.