Repository navigation
GH-90997: Improve inline cache performance for MSVC - #96781
Conversation
|
I'm reluctant to spend time getting stable benchmarks for this on Windows, last time it took me an afternoon to run the benchmarks several times with and without the patches. Let's wait until we have a Windows benchmarking machine, please? |
markshannon
left a comment
There was a problem hiding this comment.
The changes in MSVC output are a clear improvement, and seems to have a positive effect elsewhere.
Even on RISC-V which doesn't support unaligned access, the code is a bit better: https://godbolt.org/z/Ydx5roTa7
|
Looks like even GCC benefits on 64-bit ARM: https://godbolt.org/z/MTj3anj4c |
|
🤖 New build scheduled with the buildbot fleet by @brandtbucher for commit 5985a4a 🤖 If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again. |
|
LGTM |
This Compiler Explorer snippet suggests that MSVC doesn't optimize away our cache read/write utilities the way that Clang and GCC do. However, it also shows that replacing our current shifting implementations with
memcpycalls does exactly what we want, in a standard-defined way, on all three compilers. I think thememcpyversion is a bit nicer, especially since we don't need to maintain two differently-endian versions of the same code.I'm curious if this moves the benchmarks at all, but I don't have a good Windows
pyperformancesetup figured out yet. So maybe somebody else could help me out with some numbers on this? (@gvanrossum, I think I remember that you were able to get kinda-stable MSVC numbers a while back?)