PageRenderTime 54ms CodeModel.GetById 27ms RepoModel.GetById 1ms app.codeStats 0ms

/talk/compiler-workshop-2016/pypy.rst

https://bitbucket.org/pypy/extradoc/
ReStructuredText | 73 lines | 54 code | 19 blank | 0 comment | 0 complexity | 65c8d2744d7b8aa192b1dfdc37a0bc4e MD5 | raw file
  1. PyPy - DRAFT
  2. ============
  3. A quick overview of PyPy for other Python-compiler developers
  4. What is Our Niche
  5. -----------------
  6. PyPy is a mature production-ready framework automatically speeding up pure
  7. python code by factors of 2-5, already used in commercial settings.
  8. The PyPy community offers several tools to inspect and optimize Python programs.
  9. Examples: vmprof, cffi
  10. What We Bring to the Table
  11. --------------------------
  12. Our core is based on cutting-edge JIT compiler
  13. research, written in Python. Being written in Python means we can quickly
  14. try out (and reject or incorporate) new ideas. For instance, our STM work has
  15. uncovered subtle bugs in CLANG and GCC, or the fact that we can easily try out
  16. new register allocation strategies.
  17. Our JIT is not only advanced, but runs on all major platforms (Linux, Windows, MacOS, ...) including
  18. four different CPU architectures (x86, arm, ppc, s390x).
  19. We have built a high level language to aid the construction of VMs (called *RPython*)
  20. It imports the complete program
  21. Flow graphs -> Annotation -> RTyping -> Code generation
  22. Advantages:
  23. * Whole program optimizations (take that, C)
  24. * Deliver features quickly, without sacrificing speed
  25. * Loosely coupled (JIT, Interp., RPython)
  26. Downsides:
  27. * Takes a while to translate
  28. What We Need Help With
  29. ----------------------
  30. We seem to be more successful in improving core technologies than creating a
  31. end-user friendly nicely packaged distribution. We are also extremely
  32. under-funded. For instance, we could be doing alot more for data science but
  33. are moving slowly forward on a volunteer basis with C-API compatibility.
  34. Our interests lie in still providing the comfort of the Python ecosystem,
  35. without sacrificing execution time. Some details (e.g. garbage collection scheme)
  36. have some impact on user programs. We could use a lot more help in identifying and resolving
  37. these issues. If programs do not run out of the box, most users will just stick to CPython
  38. because their performance problems are not that big of an issue (at that point in time).
  39. If we could resolve those issues (funded, or externally contributed) we would create a much
  40. better user experience.
  41. We are also working on Micro NumPy, which provides the kernels for numerical operations.
  42. It is very usable, but still some features are missing. We would love to have a
  43. partner/company that would help us to complete NumPy for PyPy.
  44. We are open to changes to our JIT scheme. We are working on both high level optimizations and
  45. backend oriented changes. Ideas would be to mitigate some issues with our tracing JIT compiler
  46. (or even build a region based compiler) and many more. Most of these aspects are covered
  47. quite well by
  48. our core development team, but we will eventually take another big step in near
  49. future towards the 7th version of our JIT.
  50. Other Interesting Aspects
  51. -------------------------
  52. (Backup slides)
  53. Some words about how our JIT compiler works?
  54. We sprint 2-3 times a year (open to the public).