Speed up build_ellipse_model

[taranu]

Like #1288 (which seems abandoned), this speeds up build_ellipse_model to address #1168 . However, it is entirely written in Cython and does not require a separate shared library. In local testing on Python 3.12, it's about 130x faster than the current pure Python implementation. I also made the tolerance for one of the unit tests much stricter, because I found that it was passing even when the output was incorrect.

There is a potentially premature optimization to specialize the function depending on whether harmonic arrays are passed or not. The C code generated on my system looked correct, but I didn't actually find any difference in performance between high_harmonics=False and True.

I also attempted to parallelize it with Cython's prange. However, in my testing on multiple Linux systems, I found it never actually used more than one thread. Additionally, I couldn't figure out how to allow for a num_threads=None value in the Cython build_ellipse_model_c function, since it's typed as an int. Thus, I'm making this a draft PR to start. If someone more versed in Cython/prange could have a look at that, it would be helpful. Otherwise, the parallel support could simply be dropped.

[taranu]

I tested this on two different systems and found that num_threads does nothing because it was compiling without -fopenmp and not linking against libomp (or libgomp). After manually recompiling, parallelism works fine - or at least, runtimes are about ~3.2x faster with 4 threads.

I see that there are openmp helpers in extension-helpers, which is a requirement and enabled in pyproject.toml here, but I'm unclear on how to encourage pip install to add the relevant compiler flags. @astrofrog, could you advise?

[astrofrog]

Even though extension-helpers includes some OpenMP-related helpers, we haven't really been using them in astropy packages, as we haven't really done much investigation of how this works in terms of building wheels and whether it could cause issues on some platforms. I would personally suggest removing the parallel aspect from this PR for now until we understand better whether we should be using OpenMP or other mechanisms.

[taranu]

I would personally suggest removing the parallel aspect from this PR for now until we understand better whether we should be using OpenMP or other mechanisms.

Thanks for the reply. I was able to compile and install the parallel version via CFLAGS="${CFLAGS} -fopenmp" LDFLAGS="${LDFLAGS} -lomp" pip install ., but like you said, I have no idea how to test that across platforms, so I dropped the parallel part from the PR, which should be reviewable now. I'll re-add it on a separate branch if anyone wants to use it in the meantime.