Repository navigation
GH-90997: Improve inline cache performance for MSVC - #96781
brandtbucher merged 3 commits into
Conversation
Sorry, something went wrong.
|
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? |
Sorry, something went wrong.
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
Sorry, something went wrong.
|
Looks like even GCC benefits on 64-bit ARM: https://godbolt.org/z/MTj3anj4c |
Sorry, something went wrong.
|
🤖 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. |
Sorry, something went wrong.
|
LGTM |
Sorry, something went wrong.
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 memcpy calls does exactly what we want, in a standard-defined way, on all three compilers. I think the memcpy version 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 pyperformance setup 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?)