On 11/7/22 9:50 AM, Carter Kozak wrote:
On Mon, Nov 7, 2022, at 11:57, Anthony Scarpino wrote:
Yes, I was able to reproduce this.
Glad to hear it.
The memory usage is related to a
necessary java change for the AVX512 intrinsic. It doesn't show up much
in the crypto performance tests, but TLS triggers it more often, driving
up the memory usage even though the performance is only slightly affected.
In my synthetic benchmark, TLS_AES_128_GCM_SHA256 average time increased from
90ms/op to 160ms/op, a 78% regression. TLS_AES_128_GCM_SHA256 increased from
100ms/opt o 170ms/op, a 70% regression. I don't think this is an entirely
accurate of standard TLS usage (especially because connections aren't reused)
but I do believe the regression in practice is greater than 10%. I don't have
much data from jdk19 in production, but historically, heavy allocations have
impacted latency (or resource utilization depending on the GC) across an
application, especially one that's already allocating heavily.
I've seen differences of 77ms/ops vs 90ms/ops between jdk17 & jdk19, so
not as dramatic as yours, but I think I saw more memory usage than you
did with other tools. Benchmarks seldom, if ever, show real world usage.
Using the same jdk releases, I can show AES/GCM output went from 4.8GB/s
to 6.8GB/sec between 17 and 19, but that is under difference conditions
than this TLS benchmark. So everything gets taken in a case by case
basis and sometimes involve trade offs.
Tony
I have to see if I can change the code path without hurting the
decryption performance gains from the AVX512 intrinsic.
That would be fantastic, thank you!
Thanks,
Carter Kozak
