cinder VS prysm

Meta is actually contributing directly to upstream cpython. If you really wanted to, the internal fork is also open source: https://github.com/facebookincubator/cinder

Just one example: last year Meta open-sourced Cinder, which powers Instagram and provides sizeable speedups compared to CPython.

I used to work on the Cinder JIT and can help document any passes you find interesting or confusing.

You might enjoy Cinder then. It's based on CPython so it is nearly 100% compatible.

https://github.com/facebookincubator/cinder/

Disclaimer: I used to work on it.

I think Cinder's Static Python, which also performs runtime type checking, is more ambitious. Though it's not production ready yet.

Here's a fork that implements that https://github.com/facebookincubator/cinder - it might be nice to one day get that up streamed but obviously it'll be controversial and it certainly needs more time to bake. Hopefully at some point we can make it a pip installable extension though.

The other thing that was interesting to me, was the potential of type annotations to help make for a faster, safer experience on the compiler end of things. One example is seen in Meta’s Cinder project, on the docs it explains how typing can be used to reduce the number of steps for the compiler ([cinder/static_python.rst at cinder/3.8 · facebookincubator/cinder · GitHub](https://github.com/facebookincubator/cinder/blob/cinder/3.8/CinderDoc/static_python.rst)), making it more effective.

My current concept is to just combine zernike polynomials with a random factor and calculate the PSF from that, which can be somewhat easily be done with the prysm library. These PSFs can then be convolved with circular and gaussian kernels for modelling additional defocus and accounting for other stuff like the AA filter. Then I'd add chromatic aberration by offseting/scaling the PSFs for each channel. Some generated kernels already look pretty good when comparing them to stars in astrophotography images, but others not so much.

https://github.com/brandondube/prysm (caveat emptor: mine)

You can trace about 1 billion raysurfaces per second in pure python with CuPy, or a few million raysurfaces per second on CPU.

New paper from /u/BDube_Lensman using prysm to model NASA's Roman Coronagraph

This free book is what this free code is based on

Prysm Originally for diffraction type optics but seems to able to handle...everything? Performance as a priamary concern, GPU acceleration, proven JPL heritage :) Raytracing is however still experimental and without docs, generally whilst the library looks excellent if you're an optics person already I think I lack a bit of the base fundamental knowledge to really use it powerfully from just the API reference. I can see BDube has some raytracing example code in some of the issues I could probably adapt and muddle my way through at least. No guis is mildly annoying for a noob like myself, but I can work my way around matplotlib-ing just fine instead i'm sure.

You may want to steal my shim set since it lets you hot swap Numpy<-->cupy at runtime

I do computational diffraction with large manycore servers and GPUs at a FFRDC. The difference between MKL and not MKL is the difference between hitting enter and getting a result in an hour or two vs tomorrow.