LWN: Comments on "Cuni: PyPy for low-latency systems"

Cuni: PyPy for low-latency systems

k8to — Fri, 11 Jan 2019 17:05:55 +0000

Classic cpython works fine for graphic user interface type stuff. Those types of workloads worked fine on 4mhz cpus after all.

If you're building a videogame, then there are certainly limits and I would not reach for python.

Cuni: PyPy for low-latency systems

auc — Wed, 09 Jan 2019 11:14:30 +0000

Jython looks dead, also irrelevant to PyPy.

Also, Cuni's strategy isn't about "peppering code with manual GC steps" but precisely adopting an incremental GC.

Cuni: PyPy for low-latency systems

tuna — Sun, 06 Jan 2019 10:42:36 +0000

If you are running something graphically interactive you do not want to > 16 ms frame times. So all pythons seems really bad for those workloads.

Cuni: PyPy for low-latency systems

mm7323 — Fri, 04 Jan 2019 14:58:08 +0000

Using Python and Garbage Collection seems like a poor footing for a low-latency system to me, though the article doesn't describe exactly what the target is for low-latency.

Also the article doesn't seem to agree with itself:

... on CPython the cost of memory management is spread all over the execution of the program,

and yet

To avoid excessively long pauses, the PyPy GC has been using an incremental strategy since 2013. The GC runs as a series of 'steps', letting the user program to progress between each step.

So spreading the cost of memory management all over the program?

There's already loads or research on parallel and incremental GC techniques which avoid peppering code with manual GC steps. This just looks like the bad old days of early Java before the GC was made quite good.

Perhaps they would be better looking a Jython?