Cythonize part of the code about imaged11 HOT 3 CLOSED

Hi Younes - I would not like to learn cython but speedups are generally welcome. You can usually get a much bigger speedup by using a different algorithm. Grid index is an especially bad example of using a poor algorithm which is sensitive to parameter selection. There is a testcase simul_1000_grains which can be used for profiling. The methods from Sharma's PhD work should go a lot faster anyway (match up Friedel pairs and look at position constraints as part of indexing).

There are some issues about load balancing between openmp versus multiprocessing depending on the problem size and machine you are running on. It is very bad to have lots of processes that all start lots of threads.

If you think some routine is "slow" you can try adding @numba.jit before a function call and see if it makes any difference.

from imaged11.

Thank you Jon for these interesting insights. Indeed, xrd indexing algorithms are not time consuming, compared to 3D tomography, finite elements and other heavy scientific computing tasks.
I saw a little talk where cython improved speed by x100 simply by declaring c-like variables and writing python code, but I'm not sure how steep is its learning curve though (when it comes to advanced optimization).
I will take a closer look to Sharma's work and I would like to do some profiling with numba, cython, openmp/multiprocessing if I find a free cloud cpu service (my local machine has 8 threads, a rather ordinary processor).
I like the ImageD11 algorithm, and all the useful function the software offers. If I may ask, are you planning to refactor it using a new algorithm in the future or you would prefer to focus on adding additional features / continuous improvements to the current software?
Thanks a lot!

from imaged11.

So I will close this for now - numba has been creeping into the code lately.

from imaged11.