PyPy v7.3.6rc1 is available for testing
The release candidates for pypy v7.3.6rc1 for python2.7, python3.7, and python3.8 are up. This is our first release of 3.8. This release also includes a backend for HPy0.0.2 (may be upgraded to 0.0.3 by the final release). This release has a number of enhancements and speed-ups, as well as the usual bug fixes. The win64 rollout on conda is going well, over 600 packages are already built. Many of the bug fixes in this version were discovered while building those packages. Thanks to all who contributed code, comments, or otherwise support PyPy. The downloads are at https://downloads.python.org/pypy/ and the checksums https://www.pypy.org/checksums.html Please try them out. The directory layout of the 3.8 release has changed, so I hope it still builds c-extension modules on your platform. The release notice https://doc.pypy.org/en/latest/release-v7.3.6.html As always, edits are welcome. Matti
On Mon, 13 Sep 2021, Matti Picus wrote:
The release notice https://doc.pypy.org/en/latest/release-v7.3.6.html As always, edits are welcome.
It would be very interesting to know, how the amazing translation speedup has been achieved (I hope not by removing the fractal rendering, right?), but in this version of release notes, the issues are mostly not linked... -- Sincerely yours, Yury V. Zaytsev
On 13.09.21 17:29, Yury V. Zaytsev wrote:
Not to worry, the fractal is still there :-) – computing it takes ~1s of the total runtime. The speedup was achieved in relatively boring ways: - there was an algorithm that was (weakly) quadratic in one of the translation phases, in the number of functions analyzed. Making this linear already helped a lot. - many minutes were saved by implementing a graph algorithm in a somewhat more clever way: the algorithm finds cycles in the call graph to insert stack checks. The algorithm walks the call graph many times. I managed to speed that up by first removing all obvious leaves and trees of leaves from the call graph, that can definitely not contribute to a cycle. - When GCC is used we now use a pre-compiled shared header. This also helps massively, because the C code that we produce shares a single enormous header that hundreds of other files include. This leads to the header being parsed and analyzed again and again, which is particularly annoying if the .c file that includes it is itself tiny. In summary, nothing deep, lots of legwork. Cheers, Carl Friedrich
On Mon, 13 Sep 2021, Carl Friedrich Bolz-Tereick wrote:
The speedup was achieved in relatively boring ways. In summary, nothing deep, lots of legwork.
Hi Carl, Thank you very much for the summary, it was very interesting to read! Congratulations to the PyPy Team even (or even more so) if the speedup has been achieved by doing "boring" work, and not by applying some crazy algorithms or clever tricks! -- Sincerely yours, Yury V. Zaytsev
On Mon, 2021-09-13 at 18:21 +0300, Matti Picus wrote:
I really appreciate the effort on standardizing the install layout. However, could you also move lib_pypy inside lib/pypy3.8? Right now it seems to imply installing /usr/lib_pypy which is a no-go per FHS. -- Best regards, Michał Górny
On Mon, 13 Sep 2021, Matti Picus wrote:
The release notice https://doc.pypy.org/en/latest/release-v7.3.6.html As always, edits are welcome.
It would be very interesting to know, how the amazing translation speedup has been achieved (I hope not by removing the fractal rendering, right?), but in this version of release notes, the issues are mostly not linked... -- Sincerely yours, Yury V. Zaytsev
On 13.09.21 17:29, Yury V. Zaytsev wrote:
Not to worry, the fractal is still there :-) – computing it takes ~1s of the total runtime. The speedup was achieved in relatively boring ways: - there was an algorithm that was (weakly) quadratic in one of the translation phases, in the number of functions analyzed. Making this linear already helped a lot. - many minutes were saved by implementing a graph algorithm in a somewhat more clever way: the algorithm finds cycles in the call graph to insert stack checks. The algorithm walks the call graph many times. I managed to speed that up by first removing all obvious leaves and trees of leaves from the call graph, that can definitely not contribute to a cycle. - When GCC is used we now use a pre-compiled shared header. This also helps massively, because the C code that we produce shares a single enormous header that hundreds of other files include. This leads to the header being parsed and analyzed again and again, which is particularly annoying if the .c file that includes it is itself tiny. In summary, nothing deep, lots of legwork. Cheers, Carl Friedrich
On Mon, 13 Sep 2021, Carl Friedrich Bolz-Tereick wrote:
The speedup was achieved in relatively boring ways. In summary, nothing deep, lots of legwork.
Hi Carl, Thank you very much for the summary, it was very interesting to read! Congratulations to the PyPy Team even (or even more so) if the speedup has been achieved by doing "boring" work, and not by applying some crazy algorithms or clever tricks! -- Sincerely yours, Yury V. Zaytsev
On Mon, 2021-09-13 at 18:21 +0300, Matti Picus wrote:
I really appreciate the effort on standardizing the install layout. However, could you also move lib_pypy inside lib/pypy3.8? Right now it seems to imply installing /usr/lib_pypy which is a no-go per FHS. -- Best regards, Michał Górny
participants (4)
-
Carl Friedrich Bolz-Tereick -
Matti Picus -
Michał Górny -
Yury V. Zaytsev