1. 6
  1. 2

    It could be interesting to see if it is possible to use graalpython. It’s probably not compatible enough yet, but that could be solved. My guess (from Truffle’s results with other dynamic languages like ruby) is it will be faster than any other approach. E.g. being able to inline across the python/C boundary.

    1. 1

      Maybe. I hear that they still have long warmups though.

    2. 2

      How does Cinder differ from PyPy? Or more specifically why build Cinder when PyPy exists?

      1. 2

        Cinder:

        • is built on top of CPython, so no C-API compatibility issues
        • is method-at-a-time instead of tracing

        It also bundles Static Python, a type-checked and type-optimized subset of Python.

        There are also some vague internal reasons like “we tried PyPy and it wasn’t promising on our workload”.

        1. 2

          That’s interesting, as it implies that Cinder compares favorably to both CPython and PyPy on some representative benchmark. Would you be willing to submit a benchmark upstream to PyPy’s list of benchmarks? They generally treat slowness as a bug and would be interested in understanding.

          1. 2

            I don’t know if it’s that simple. It was a multi-person effort at least 5 years ago to port our workload to PyPy and I think all people involved have since moved on to greener pastures.

            I don’t mean to say that PyPy was necessarily slow; the problems could have been in the forking model, or memory consumption, or taking some time to warm up, or not being able to optimize across the C extension boundary… something in that realm.

            PyPy may well have been faster, even, but it’s an enormous task to try and internalize the whole runtime and see where we can make improvements :)