WIP::ENH:SIMD Improve the performance of comparison operators

[seiko2plus]

Don't merge! Work in progress

Summary of the changes, performance achievements, TODO list will be written later.

NOTE: Feel free to leave comment/review while I'm working on it

[Qiyu8]

comparison

[eric-wieser]

I suspect this would make sense in a standalone PR, along with tests and documention.

[seiko2plus]

yes, indeed. it's under experiments right now. sure I will move it later into a seprate pr along with doc and testing unit.

[eric-wieser]

It would be good to look around and see if there are existing template solutions that can be reused. tempita I think is used in some places in numpy, and jinja may be an option too.

[seiko2plus]

I tried almost everything until I figure out the most flexible template engine is the one who doesn't bring new language syntax or philosophies and that what "pyas" does "Python as a template language", its simply treat Python as a PHP and f-strings as a template. it also provides a simple translation mechanism.

[seiko2plus]

And the reason why I drop repeat template is the generated source size almost hit 9mb without finishing the rest of the work also it can't be used for generating C macros.

[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.

[mattip]

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

[seiko2plus]

@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)

[seiko2plus]

@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!.

[seiko2plus]

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++