Don't use Vector<byte>.Dot

[benaadams]

23% improvement in RPS

Faster implementation than using Vector<byte>.Dot

Resolves #493

Before

Running 30s test @ http://.../plaintext
32 threads and 1024 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 8.68ms 14.73ms 333.56ms 95.18%
Req/Sec 47.81k 4.58k 122.10k 90.28%
44317883 requests in 30.10s, 5.45GB read
Socket errors: connect 35, read 0, write 0, timeout 0
Requests/sec: 1472388.96

After

Running 30s test @ http://.../plaintext
32 threads and 1024 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 11.18ms 28.91ms 558.18ms 94.56%
Req/Sec 59.52k 8.66k 282.83k 93.10%
54796839 requests in 30.10s, 6.74GB read
Socket errors: connect 35, read 0, write 0, timeout 0
Requests/sec: 1820474.06

[halter73]

23%! That's great. We're going to run this in our perflab along with the StringValues change to a class (dotnet/extensions#68) and report back with the combined results.

[davidfowl]

why this change?

[benaadams]

Read that it's Jitted to a const, so can use it directly rather than cacing in variable; will try to find reference

[darcythomas]

What is the environment that you ran these tests on? (So I can make some apple to apple comparisons)

[halter73]

It's hard to make apple-to-apple comparisons unless you run the baseline on the exact same machine.

[darcythomas]

Apple to pear comparisons perhaps :P

I was wondering if it was something "Standard-ish" like a A3 VM instance on Azure, or something...

[benaadams]

@darcythomas you need to run in release (SIMD optimizations are weakened in debug; so its possible to debug them). Vector<float>.Dot is hardware accelerated, but there isn't an equivalent cpu instruction for Vector<byte>.Dot.

On a A3 VM you might max out its network first; I'm testing with G4 VMs as already above 2.3GBps sends.