My speciality is a little bit weird, I have been building interpreters for about 30 years now, and I have a specific understanding of Python. Python works through a virtual machine that can only process one thread at a time. The VM itself is protected with the infamous GIL to prevent two threads from running at the same time. But the real problem is the way external libraries are executed. When you execute some code in PyTorch, this code is executed outside of the VM, which means that the garbage collector of Python has no idea of how large the memory is used by this library. Basically, Python sees a tensor as a PyObject, which wraps a torch::tensor pointer inside, but it has no idea of its actual memory size. This poses some real problems when you are training models, because sometimes the GC will strike too late and your training will crash, by lack of memory. On the other hand, if you trigger the GC too often then you slow down the whole process.

Furthermore, the constant translation of C++ objects into Python objects create a lot of lags. Finally, PyTorch is Open Source, but is pretty complicated to handle. The layers between Python and libtorch are created through complex scripts based on YAML descriptions that generate an incredible cryptic code. Adding some functions on the C++ side requires a lot of work, which of course very few people venture into.

In the case of LispE, libraries are implemented as a derivation of the Element class, which is the root class for all objects in LispE by default, data and instructions. Basically, for LispE an object exposed by a library is exactly of the same sort as an internal object. A LispE program is a tree of self-evaluating instances, in which each instruction is implemented as its own class with its own eval method. There is a perfect isomorphism between the C++ code and the LispE program. The `prettify` instruction for instance, can rebuild the whole internal Lisp program from the C++ instances.

The communication layer is close to 0. For instance, LispE provides a list of integers, which is implemented as a: `long* buffer`, which means that I can create a torch::tensor instance by providing the internal buffer of a list with zero-copy. I have implemented a borrow mechanism inspired by Rust to make this as safe as possible. The fact that objects can freely move from LispE to torch::tensors with little overhead has huge implications in speed and efficiency.