LLVM support

[gtusr]

Are there any plans to introduce support for compiling Mathics code down to LLVM?

If so, this would allow Mathics to leverage work that is taking place to bring automatic differentiation to the platform:

Automatic Differentiation for LLVM-hosted languages

[TiagoCavalcante]

The link is off

[gtusr]

Link is now updated.

Adding a link to a native Wolfram Language AD package that may also work in Mathics:

Dual Numbers Package for Automatic Differentiation in Mathematica

[rocky]

Thanks for the link, information and idea.

In the short term though I don't think this can be done in the code base as is. To first approximation, think of Mathics as just a front-end to SymPy, SciKit, PIL, mpmath and so on. We would most benefit if this were done inside one of these other packages that we depend on, rather than doing it one level removed from that.

Let me elaborate a little on this. We do have the ability to compile down to LLVM via Cython and compiled functions. But at the LLVM level Mathics variables are seen as being not typed. I guess they would be seen as pointers to objects. The way you get the variable would be the result of a call.

Right now, the Mathics interpreter is a tree interpreter of M-expressions. For this to have conceivable benefit we would have to somehow turn a Mathics expression into an equivalent Python expression with types included and then that could be compiled down to LLVM and then this work would see enough structure to be able to do something with it.

The Dual Numbers Package that you site uses Automatic Differentiation that is already built into Mathematica. It reimplements Numbers in a way that Mathematica's engine can use its existing Automatic Differentiation on.

[mmatera]

Actually, we have a llvmlite compiler with a limited support for arithmetic functions as well as some loop and control keywords. Look at the mathics.builtin.compile module

[rocky]

Actually, we have a llvmlite compiler with a limited support for arithmetic functions as well as some loop and control keywords. Look at the mathics.builtin.compile module

I don't think that will be very useful for exactly the reasons cited above: wishful thinking that a compiler is going to untangle levels of abstraction, some of which are the root cause of the inefficiency in the first place .

But prove me wrong!

[mmatera]

The inneficient part is the standard evaluation. Then, if you evaluate Compile over the evaluated expression, of the expression is not too complicated, you can get a llvmlite compiled code, that you could take and use in another place. So, the inneficient evaluation process translates into an inneficient compiler, but the resulting object code should be ok.

[mmatera]

This could be useful
https://eli.thegreenplace.net/2015/calling-back-into-python-from-llvmlite-jited-code/