Description
The beginnings 🐣
-
This project was initially created (2023) to accelerate a MeTTa subset by factors of hundreds for use in MeTTa-NARS.
-
With guidance by Alexey Potapov, it evolved into a compiler package for Hyperon-Experimental, enabling performance-critical code to be compiled to efficient native code and called as easily as regular MeTTa functions.
-
As the primary developer Patrick Hammer focuses on AI, broader use was encouraged, though not officially supported.
-
With the development of a bi-directional MeTTa interface for the even more efficient and feature-complete C implementation of NARS, MeTTa-Morph’s primary use became obsolete. Nevertheless, MeTTa-Morph fulfilled its goal, supporting a substantial MeTTa subset and offering a stable solution.
Current status 🔥
- As of June 2025, the project has been updated for compatibility with Hyperon-Experimental v0.2.5.
In the MeTTa jungle 🌴🐒🌴
-
MeTTa-Morph was never intended to replace the main MeTTa implementation, but to accelerate a significant and practical subset to extreme performance levels.
-
MeTTa-Morph currently integrates with Hyperon-Experimental, though adaptation for MeTTa-WAM is feasible.
-
MeTTa-WAM is promising, supporting the full MeTTa language and interpreting it at speeds typically 10× faster than Hyperon-Experimental, as has been consistently observed for complex AI codes. However purely-interpreted code will always have performance limitations compared to AOT or JIT compiled code, and due to execution model differences, a feature-complete source translation to Prolog has not yet been achieved (but is in the works). If accomplished, native code compilation (as with GNU Prolog) could follow, important, as interpreted Prolog code does not match the speed of true native code (e.g., GHC, native Scheme compilers). Even then, MeTTa-WAM would realistically remain about 2-5x slower than MeTTa-Morph due to Prolog’s runtime overhead (evident in generated assembly comparisons of GNU Prolog vs. GHC/Scheme). Building a compiler specifically for the MeTTa language would also be possible, but why would the dozens of optimizations that are performed by Scheme/C compilers (or the JVM for that matter or GNU Prolog even) not apply to MeTTa and how many years would it take to implement them to a comparable level?
-
Jetta, which compiles MeTTa to JVM (Kotlin), can make use of the many optimizations of modern JVM implementations. So far Jetta targets numeric code but is unlikely to match MeTTa-Morph’s efficiency especially when the compiler gets invoked. MeTTa-Morph already works for a broader subset of MeTTa, far beyond tail-recursive numeric code, and source translation to Scheme is more straightforward than a translation to JVM languages.
-
MM2 is a S-expression-based language that significantly diverges from classical MeTTa. It shows promise but is not included in this comparison for that reason.
-
🚀 Benchmarks to evaluate runtime performance are crucial for objective comparisons. These should include both simple idealized cases and complex, established MeTTa source codes. Some benchmarks are already included in this repository. A more general benchmark repository for comparing different MeTTa implementations would be desirable.