-
-
Notifications
You must be signed in to change notification settings - Fork 31.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Specialize BINARY_MULTIPLY #89530
Comments
I'm having trouble setting up a rigorous benchmark (Windows doesn't want to install greenlet for pyperformance), but just running a couple of individual files, I got this: Mean +- std dev: [nbody_main] 208 ms +- 2 ms -> [nbody_specialized] 180 ms +- 2 ms: 1.16x faster Hopefully those are accurate. |
I had the *exact* same issues, I eventually found a workaround for it after many hours spent guessing. Initially, setuptools complained that I needed MSVC++ 14.0 or later (even after I had the latest one installed). I found that for some strange reason, *only* 14.0 worked, 14.2x etc. don't. After installing MSVC 14.0, there was then some strange complaint about missing some .exe/.dll. Searching that entire error message led me to a result on StackOverflow advising copying said files from the Windows SDK in Visual Studio over to the MSVC 14.0 folder. This finally allowed greenlet to compile. I've since lost the exact SO links, but I hope this leads you somewhere. Anyways, I don't recommend benchmarking on Windows for stable results (trust me, I've tried ;-). Eventually I gave up and just used Linux for stable benchmarking. pyperformance PS. are your numbers with PGO and LTO? If so, they're spectacular! |
Hm the above was not PGO. I tried again with PGO and it is not so good: Mean +- std dev: [nbody_main_pgo] 177 ms +- 4 ms -> [nbody_specialized_pgo] 190 ms +- 2 ms: 1.07x slower |
If some misses are caused by mixed int/float operands, it might be worth investigating whether these occur in loops. Most JIT compilers perform some sort of loop peeling to counter this form of type instability. E.g.
By unpeeling the first iteration, we get type stability in the loop x = 0
#first iteration
x += some_float()
for ... #Remaining iterations
x += some_float() # x is always a float here. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: