PyPy v7.3.22

PyPy 7.3.22 버전이 출시되어 Python 2.7과 3.11 인터프리터를 지원하며, 주요 JIT 버그 수정과 CPython 호환성 개선이 포함되었습니다. 특히 RPython _pickle 모듈과 json 인코더가 도입되어 피클링과 JSON 처리 속도가 크게 향상되었고, 멀티프로세싱 환경에서의 성능도 개선되었습니다. 이번 마이크로 릴리스는 기존 7.3 시리즈와 API 호환성을 유지하며, PyPy의 빠른 JIT 컴파일러 기반 성능을 더욱 강화합니다. PyPy는 다양한 플랫폼 바이너리를 제공하며, 개발자 커뮤니티 참여와 C 확장 라이브러리의 HPy/CFFI 변환을 권장하고 있습니다.

https://pypy.org/posts/2026/04/pypy-v7322-release.html

#pypy #python #jit #rpython #performance

PyPy v7.3.22 release

PyPy v7.3.22: release of python 2.7, 3.11 The PyPy team is proud to release version 7.3.22 of PyPy after the previous release on March 13, 2026. This is a bug-fix release that fixes several issues in

PyPy
🌗 RPython GC 的分配速度有多快?
➤ 深入分析 RPython 垃圾回收器的分配效率
https://pypy.org/posts/2025/06/rpython-gc-allocation-speed.html
本文探討了 RPython 垃圾回收器 (GC) 的分配速度。作者透過一個簡單的基準測試程式,測量了在 64 位元架構上分配包含單一整數欄位的物件的效能。測試結果顯示,RPython GC 在沒有初始化欄位的情況下,可以以高達 34.35 GB/s 的速度分配物件,即使初始化欄位,也能達到 29.7 GB/s。作者將 RPython GC 的效能與 Boehm GC 進行比較,並使用 perf 工具分析了快取命中率、指令週期和分支等指標。研究發現,RPython GC 的分配速度非常快,且垃圾回收佔總執行時間的比例相對較小。
+ 這篇文章對於瞭解 RPython 垃圾回收器的效能非常有幫助,提供了詳細的測試數據和分析結果。
+ 我一直很好奇 PyPy 的效能,這篇文章讓我對 RPython
#程式設計 #垃圾回收 #PyPy #RPython #效能分析
How fast can the RPython GC allocate?

While working on a paper about allocation profiling in VMProf I got curious about how quickly the RPython GC can allocate an object. I wrote a small RPython benchmark program to get an idea of the ord

PyPy
🚀🚀 "Tech genius discovers the astonishing speed of #RPython GC allocation... by writing *another* benchmark program. Because, clearly, the world was waiting with bated breath for this groundbreaking revelation instead of solving actual problems. 🙄"
https://pypy.org/posts/2025/06/rpython-gc-allocation-speed.html #TechGenius #Benchmarking #GCAllocation #GroundbreakingRevelation #ProblemSolving #HackerNews #ngated
How fast can the RPython GC allocate?

While working on a paper about allocation profiling in VMProf I got curious about how quickly the RPython GC can allocate an object. I wrote a small RPython benchmark program to get an idea of the ord

PyPy
How fast can the RPython GC allocate?

While working on a paper about allocation profiling in VMProf I got curious about how quickly the RPython GC can allocate an object. I wrote a small RPython benchmark program to get an idea of the ord

PyPy

I finally think I've figured out a basic #Nix heap using the #Haskell/#GHC technique of flagging every heap object to detect infinite loops. Cache invalidation really is hard... Fortunately, Nix is pure, so I don't have to invalidate any heap objects directly. #RPython makes it easy to hack, although it's still a bit of a slog to debug segfaults.

I think I might have to actually look at #CppNix now, or at least reread Eelco's thesis. I need to understand the differences between evaluation and instantiation.

I apparently was overly emotional last night and started an #RPython version of #Nix. I have about half a parser so far.

If I keep working on this, the goals will be to have a smaller footprint in terms of code and CPU (but not necessarily RAM) than CppNix. This sounds quite achievable because the RPython toolkit comes with a JIT generator: insert interpreter, receive JIT.

Contributions will be welcome once everything is available to the public. Wait a day or two, please.

Germane to the current #NixOS / #nixpkgs drama, I think.

What would be a good and punny name for an #RPython implementation of a #Nix evaluator?

New blog post: Which Interpreters are Faster, AST or Bytecode?

It gives a high-level overview over our OOPLSA paper, which investigates interpreters on top of metacompilation systems.
Will be presented next week at @splashcon.

https://stefan-marr.de/2023/10/ast-vs-bytecode-interpreters/

#graalvm #truffle #rpython

Which Interpreters are Faster, AST or Bytecode?

A brief overview of our study of abstract-syntax-tree and bytecode interpreters on top of RPython and the GraalVM metacompilation systems.

Apparently not a joke. A lot of people seem to be quite enthused about this.

#Pypy, a Python runtime in Python, tried this ages ago. Their #RPython cross-compilation toolchain was extremely useful, built up to target #WASM as a back-end. Really helped push Web Assembly forward.

Conclusion: it's not worth it. It's almost never worth it.

Instead: transpile to ES6 for native runtime, zero download overhead, and zero startup overhead. JavaScripthon is an excellent one I've even contributed to.