Josef Dean's GPUsnek ported MicroPython to GPUs (& C++)

[jepler]

I'm just reading the proceedings of SIGBOVIK 2026 and I arrived at @jndean's paper "GPU-Parallelizing Arbitrary Python Code By Running 1 Million Python Interpreters on a GPU". Looks inside -> It's MicroPython, but ported to build with the CUDA C++ compiler.

Besides being a very interesting feat to run MicroPython on a GPU, it's somewhat interesting that the author fixed all the little poblems that exist in the core when you try to build it with a C++ compiler instead of a C compiler. This is something I'd started on but quickly noped out about.

I wonder what the trade-offs were, and whether there's interest & utility in bringing the C++ portability changes into the core.

[Josverl]

Thanks, an interesting read.
Exception handling and GC are still to be solved - but interesting none the less.

This is all very well, but
unfortunately CUDA does not provide an implementation of
setjmp and longjmp.

Without setjmp and longjmp, MicroPython’s exception han
dling mechanism cannot function. Currently in gpusnek
we simply do not support exception handling: when an
exception is raised, the exception message is printed di
rectly to stderr, and the thread unceremoniously exits. As a
workaround, we recommend writing Python code that does
not raise any exceptions.

See also : https://github.com/jndean/gpusnek

[jndean]

The version of the paper submitted to SIGBOVIK is missing the performance profiling section (because I fell ill just before the submission deadline and couldn't get it finished). You can read the finished version here: https://josefdean.co.uk/gpusnek.pdf.

The profiling shows what a phenomenally bad idea it is to run Python on a GPU (or ar least to do a naive port in this way) if performance is in any way important :) .

But, to your point @jepler, I don't recall the changes required for C++ compatibility in the core being particularly invasive, just small tweaks repeated in a lot of places.

[dpgeorge]

@jndean that's a great write up! Nice to read about the technical details of the difficulties you hit when porting it to CUDA.

You might be interested to know that we did seriously attempt both the following:

1. removal of setjmp/longjmp and just use return values, see [proof of concept] completely remove nlr from py, extmod and unix port #4131
2. track GC root pointers explicitly, see WIP: use a root stack to explicitly track root pointers #4723

But you can see that they are very difficult, and so far we didn't see a real need for them.

[jndean]

@dpgeorge Oh awesome, thanks I'll have a look through these. I would have had no idea how difficult removing NLR was going to be, but seeing that PR makes it look vaguely achievable (at least at the scale I would need to get just my scrappy CUDA POC working). Maybe I'll have a go at it some time.

[dpgeorge]

Removing NLR is still something I'd like to do, but the reasons listed at the end of that PR still hold.