(Trivial) optimized dsdot implementation for HASWELL

[martin-frbg]

For #1326

[kohr-h]

Would the same change in the microkernel work for other architectures, too? They all look very similar, apart from the number of floats they process at a time.

[martin-frbg]

I expect so, but did not want to mess with all of them at once.

[kohr-h]

Sure. I'm asking because in the overarching Numpy issue, people won't be happy with Haswell support only. And by "support" I mean "optimized microkernel".
Although it seems to me that the part in the microkernel that is removed for dsdot really doesn't make any difference in runtime. Does that agree with your experience?

[martin-frbg]

The small optimization in the microkernel may well be immesurable, the important part is the declaration in KERNEL.HASWELL that tells the build system to use the modified sdot.c file for dsdot as well instead of falling back to the slow generic C. This should work equally well for all the other x86_64 cpus that have their own sdot microkernels, and only a little bit slower for those that fallback to the C implementation of sdot_kernel_16. And it probably would work also for arm, power etc. once their local implementations of sdot.c are adapted.

[kohr-h]

That's what I was guessing, too. Most of the gain for little work (at least for one platform :-)).