There HAS to be a better way to do this.

I'm open to ANY other way you may have for this. I don't like it either. But right now, this is the only way its going to compile well on all architectures.

You can make multiple .o targets and pass a different -D flag to each one using the same source file. It will require some changes to the CMake files but it will be hell of a lot better then adding 20 files.

Ok, that might work. I'll look into it.

build arrayfire tegrak1 ci
build arrayfire tegrax1 ci

I don't know if there's anything that can be done, but it became extremely slow to compile arrayfire after this merge.

Well, actually it became slow after #1373 because its like adding a bunch of new kernels as sort_by_key requires All-to-All mapping for types. With #1373 the number of instantiations per file were so many that NVCC was crashing even on the best machines. This fixed the crashing part.

I have been thinking about this and it might make a difference if we remove the dim template from the batched function. The dim template is not actually used in any of the actual sort calls. I'm looking into the time saved - its about a minute and a half reduction (mostly on the CUDA backend).

@FilipeMaia Can you verify if it is after this PR ? We had other PRs with similar names.

@shehzan10 is probably correct. I haven't tried just after #1373 but it's the new sort kernels that cause the slowness, so the reason must be #1373.
I have no solution, just pointing out that the slowness is at a level where it becomes a practical concern.

@FilipeMaia that is a problem we have to deal with because of using a template based library like thrust.. :-/ Too many instantiations.

Need to figure out if there is any easier way to deal with this.