Jpeg encoding code optimization - #1632

@saucecontrol did a little research about 8x4 -> 4x2 downscaling based on your ideas.

1. A lot of total method time was spent on the final permutation. I guess line crossing was a thing, your approach with vpermq works 25% faster:

Note that this benchmark uses current add(shuffle, shuffle) implementation, not horizontal add.

2. vhaddps doesn't really give any performance boost:

vpermq gives a little to no performance boost but it reduces code by a lot, it completely eliminates 2 custom methods and looks cleaner!

3. Horizontal adds are slower than usual adds as far as I know. Your implementation uses 2 hadd & 1 add, we can change it to 1 hadd and 2 add:

//v0 = 0 | 1 | 2 | 3 || 4 | 5 | 6 | 7
//v1 = 8 | 9 | a | b || c | d | e | f
//v2 = g | h | i | j || k | l | m | n
//v3 = o | p | q | r || s | t | u | v

v0 = vaddps v0 ,v2
v1 = vaddps v1, v3
//v0 = 0g | 1h | 2i | 3j || 4k | 5l | 6m | 7n
//v1 = 8o | 9p | aq | br || cs | dt | eu | fv

v0 = vhaddps v0, v1
v0 = vmulps v0, 0.25f
//v0 = 01gh|23ij|89op|abqr||45kl|67mn|cdst|efuv

vpermq v0, mask 0,2,1,3
//v0 = 01gh|23ij|45kl|67mn||89op|abqr|cdst|efuv

And it runs almost 50% faster:

The only thing that bothers me is quad word permutation:

...
Vector256<float> avg2x2 = ...; // average for 4 values
...
var per = Avx2.Permute4x64(Unsafe.As<Vector256<float>, Vector256<double>>(ref avg2x2), 0b11_01_10_00);
return Unsafe.As<Vector256<double>, Vector256<float>>(ref per);

I guess without manual IL code injection (which is not that easy by itself) it's impossible to write it better?

That's great! I had the same thought about the horizontal adds late last night but was too lazy to go back upstairs to my computer 😆

Horizontal add is implemented in microcode in the processor, and it's effectively broken down into a shift (with an order that doesn't map to an instruction exposed publicly), an add, and an unpack. So it's actually only one cycle faster than the current code that does 3 shifts and an add. But yeah, doing the vertical portion first really cleans it up.

And hopefully the smaller code makes it possible to get rid of the code in the outer method that spills those to the stack. (I didn't spend enough time looking at that to figure out what it's doing entirely).

Oh, and you don't need Unsafe.As to cast between vector types. avg2x2.AsDouble() is the same as Unsafe.As<Vector256<float>, Vector256<double>>(ref avg2x2). All the AsXXX methods on the vector types are intrinsics that compile to a no-op.

Yep, code is much cleaner and smaller with your additions. Didn't know about no-op for those casts.

Thank you for your contribution to this pr, getting smarter everyday! 😄

@JimBobSquarePants waiting for new commits to be built & checked and we are ready to merge I guess!
If fresh pre/post full encoding benchmarks are needed - will gladly execute and provide them tomorrow.

@br3aker Looks like you've got a PlatformNotSupportedException around System.Runtime.Intrinsics.X86.Avx2.Permute4x64 on macOS .NET 5.

https://github.com/SixLabors/ImageSharp/pull/1632/checks?check_run_id=2789197791#step:10:256

Edit.
Are we looking at a potential regression in the .NET runtime? Our usage of Permute4x64 appears to be protected by
Avx2.IsSupported and we're building and testing against 5.300 version of the SDK.

dotnet/runtime#43812

@JimBobSquarePants my bad, did check for Avx, not Avx2. Pushed fixes for this and your comment about SimdUtils class.

@JimBobSquarePants fixed disposable thingy in benchmarks & updated them:

BenchmarkDotNet=v0.12.1, OS=Windows 10.0.19042
Intel Core i7-6700K CPU 4.00GHz (Skylake), 1 CPU, 8 logical and 4 physical cores
.NET Core SDK=6.0.100-preview.3.21202.5
  [Host]     : .NET Core 3.1.13 (CoreCLR 4.700.21.11102, CoreFX 4.700.21.11602), X64 RyuJIT  [AttachedDebugger]
  DefaultJob : .NET Core 3.1.13 (CoreCLR 4.700.21.11102, CoreFX 4.700.21.11602), X64 RyuJIT

Already beating System.Drawing in the 75 quality scenario. Looks like 90-100 have a constant delta betweem them. Will work on this on a separate PR. I think this is doable 😄

Waaaat, first time ever seeing OutOfMemory exception in tests in this PR for... decoding?

Looks like the ImageMagick reference decoder is also very greedy on memory, don't mind it, nothing to do with your code.

Lets get this merged!! 🎉