GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | ||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | ||||||
GeezerVison is showing github.com — GH-100425: Timing experiment: For builtin_sum, try replacing Fast2Sum with 2Sum by rhettinger · Pull Request #100860 · python/cpython Conversation
|
|
I see no difference either, on Linux with an AMD Zen 2 chip |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
Both with and without optimizations I see no difference. System: Linux, gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1), Intel(R) Core(TM) i7-4710MQ CPU @ 2.50GHz |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
Thank you both. It would be nice to hear from a Windows person as well. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
On Windows (default PCbuild/build.bat, no PGO) the timings vary a lot on my system (Intel(R) Core(TM) i7-4710MQ CPU @ 2.50GHz, Windows 10, VS 2019). For this PR, measurements within 5 minutes: I can confirm that the minimum time for the test is roughly the same for main and this PR. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
Thank you. I appreciate it. @mdickinson Given that 2Sum and Fast2Sum have the same performance in the context of builtin.sum(), do we have a non-performance reason to choose one over the other? Or should I leave the |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
@rhettinger Leaving as-is sounds good to me. The two should be functionally identical, so performance is just about the only thing that would justify choosing one over the other. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
There was an error while loading. Please reload this page.