py2many VS functorch

> Another problem is that there are hundreds of built-in library functions that need to be compiled from Python from C

An approach I've advocated as one of the main authors of py2many is that all of the python builtin functions be written in a subset of python[1] and then compiled into native code. This has the benefit of avoiding GIL, problems with C-API among other things.

Do checkout the examples here[2] which work out of the box for many of the 8-9 supported backends.

[1] https://github.com/py2many/py2many/blob/main/doc/langspec.md

https://github.com/py2many/py2many/blob/main/doc/langspec.md

Reimplement a large enough, commonly used subset of python stdlib using this dialect and we may be in the business of writing cross platform apps (perhaps start with android and Ubuntu/Gnome)

For py2many, there is an informal specification here:

https://github.com/py2many/py2many/blob/main/doc/langspec.md

Would be great if all the authors of "python-like" languages get together and come up with a couple of specs.

I say a couple, because there are ones that support the python runtime (such as cython) and the ones which don't (like py2many).

It'd not fully solve your issue, but have you ever seen https://github.com/py2many/py2many ?

Cython doesn't consume python3 type hints and needs special type hints of its own. But it's certainly more mature than other players in the field.

What we need is a rpython suitable for app programming and a stdlib written in that dialect.

https://github.com/py2many/py2many/blob/main/doc/langspec.md

No intermediate AST. To understand the various stages of transpilation and separation of language specific and independent rewriters, this file is a good starting point:

https://github.com/adsharma/py2many/blob/main/py2many/cli.py...

Link to the test that's relevant for this discussion:

https://github.com/adsharma/py2many/blob/main/tests/cases/in...

This is an explicit deviation from python's bigint, which doesn't map very well to systemsey languages. The next logical step is to build on this to have dependent and refinement types.

Work in progress here:

https://github.com/adsharma/Typpete

I would suggest checking https://pytorch.org/functorch/ and https://github.com/metaopt/torchopt for efficient inference and training with ensembles (e.g., t be independent actors in a multi-agent setting or multiple critics).

There were some bugs still with advanced indexing in an older release of functorch, I believe they should be fixed now though: https://github.com/pytorch/functorch/pull/862

Tangentially related but there is an effort to get some of the features of JAX into PyTorch: https://pytorch.org/functorch/

Fwiw, composable vmap and stuff like that have also been implemented in PyTorch now - see functorch :) https://github.com/pytorch/functorch

Fwiw, it’s not like Pytorch’s design prevents function transformations from being implemented. See functorch for an example of grad/vmap function transforms: https://github.com/pytorch/functorch

You may find vmap from functorch to be quite useful: https://github.com/pytorch/functorch

If you're interested in function transformations in PyTorch, try out functorch :) https://github.com/pytorch/functorch

The pytorch programming model is just really hard to adapt to an XLA-like compiler. Imperative python code doesn't translate to an ML graph compiler particularly well; Jax's API is functional, so it's easier to translate to the XLA API. By contrast, torch/xla uses "lazy tensors" that record the computation graph and compile when needed. The trouble is, if the compute graph changes from run to run, you end up recompiling a lot.

I guess in Jax you'd just only apply `jax.jit` to the parts where the compute graph is static? I'd be curious to see examples of how this works in practice. Fwiw, there's an offshoot of pytorch that is aiming to provide this sort of API (see https://github.com/pytorch/functorch and look at eager_compilation.py).

(Disclaimer: I worked on this until quite recently.)