I wonder if we could refactor the dispatch mechanism to be much more limited: only have two loops: a baseline and an advanced loop, written in C. Then only use these loops via the current ufunc reassign-c-function-loops-at-import rather than the macro-based runtime mechanism via NPY__CPU_DISPATCH_CALL. I am worried about the maintenance burden moving forward and the intricies of adding yet another C code format to NumPy.

If the generated code is so large, maybe we need to rethink what we are trying to do here.

@mattip,

I wonder if we could refactor the dispatch mechanism to be much more limited: only have two loops: a baseline and an advanced loop, written in C. Then only use these loops via the current ufunc reassign-c-function-loops-at-import rather than the macro-based runtime mechanism via NPY__CPU_DISPATCH_CALL. I am worried about the maintenance burden moving forward and the intricies of adding yet another C code format to NumPy.

xref, mattip#46 (comment)

@mattip,

If the generated code is so large, maybe we need to rethink what we are trying to do here.

The issue in the conv_template(template repeater) that we had to count on C preprocessors for everything even with internal looping!
Do you know how that cost?

$ python numpy/numpy/distutils/conv_template.py einsum_sumprod.c.src
$ du einsum_sumprod.c
4576	einsum_sumprod.c

This PR is covering more and more kernels than einsum. So the best thing we can do is to cut the roots from the beginning
to avoid increasing the maintenance cost, it wouldn't hurt that much if we give it a try!.

closed in favor of #21483, while it doesn't contains all the improvements this pr has but we could add later during moving to C++