> A major goal of Clang was to be a “compatible replacement” for GCC, MSVC and other existing compilers. It is hard to make a direct comparison, but the complexity of the Clang problem appears to be an order of magnitude bigger than implementing a compatible replacement for Python. The journey there gives good confidence we can do this right for the Python community
Is it though? For Mojo to be a compatible replacement for Python, it would need to match the Python C ABI and the greater set of the standard library in a bug-for-bug compatible way.
The real question is whether it's bug-for-bug compatible or whether it's not. Numerical functions have a lot of nuances that effect that performance quite a bit. Are they constrained so that Python numpy log(x) gives the same as Mojo log(x)? Will C bindings act the same way as in CPython? Whole list of related questions. If there is a no to any of these questions, then code acts subtly differently in a way that is sometimes hard to detect. These differences are of course what have held back "standard code" from being numba/pypy/etc. compatible in many instances.
That said, if the answer isn't yes to anything, then it is very difficult to make optimizations. Not allowing hard to optimize Python behavior is precisely what has allowed Numba, Julia, etc. to achieve accelerations. There were some attempts at that kind of thing with R, which Jan Vitek gives some very interesting talks about (https://www.youtube.com/watch?v=VdD0nHbcyk4).
What I would find worrisome too is that this approach sounds like compile time city. A lot of the recent advancements in Julia have been by sending less to LLVM: optimizations are done in Julia and dead code is eliminated, calls are found to be the same and check caches, and then with v1.9 those caches use precompiled binaries to avoid having to call LLVM again. And the timeline of improvements shows that making LLVM be in the picture as little as possible has lead to some dramatic improvements in Julia's latency (https://viralinstruction.com/posts/latency/). Given what was seen from that, I'm weary of an approach that does everything in LLVM (via MLIR) on an even more dynamic representation (i.e. Python). My guess is that only things with explicit types will compile, and the rest is probably hitting some Python interpreter to avoid this issue.
[If part is using Python/GC through an interpreter though, wouldn't that part be harder to target to accelerators since it wouldn't compile through LLVM? That would mean only the code that is explicitly typed gets the nice new features, but not the Python parts?]
But hey, if this gets Chris Lattner and crew a reason to start taking LLVM compile times more seriously, then it's a win for Julia as well. I'm excited to see how the communities can benefit from one another, especially if Mojo is open source then it can be a win for all (which was definitely not clear in the presentation). And I do think that some of the ideas of lower level memory control are cool and should be added similarly to languages like Julia and Numba.
Thanks for your interest, I'm pretty confident we can do this. I've been working on compilers and languages for awhile. :)
Your point about LLVM compile time is great one. Mojo is architected from the beginning for fast compile times, including deeply integrated caching and distributed compilation. LLVM "isn't slow" if you don't keep asking it to do the same thing over and over again.
> Is it though? For Mojo to be a compatible replacement for Python, it would need to match the Python C ABI and the greater set of the standard library in a bug-for-bug compatible way.
Isn't this going backwards? If Mojo delivers what it is trying to do, then these libraries would be rewritten in Mojo, and the issue of having to use two languages and continuously switching between them will be avoided.
I saw your talk in London a few weeks ago and immediately thought of your discussions on python accelerators when I heard about Mojo - glad to see your thoughts here!
Is it though? For Mojo to be a compatible replacement for Python, it would need to match the Python C ABI and the greater set of the standard library in a bug-for-bug compatible way.
The real question is whether it's bug-for-bug compatible or whether it's not. Numerical functions have a lot of nuances that effect that performance quite a bit. Are they constrained so that Python numpy log(x) gives the same as Mojo log(x)? Will C bindings act the same way as in CPython? Whole list of related questions. If there is a no to any of these questions, then code acts subtly differently in a way that is sometimes hard to detect. These differences are of course what have held back "standard code" from being numba/pypy/etc. compatible in many instances.
That said, if the answer isn't yes to anything, then it is very difficult to make optimizations. Not allowing hard to optimize Python behavior is precisely what has allowed Numba, Julia, etc. to achieve accelerations. There were some attempts at that kind of thing with R, which Jan Vitek gives some very interesting talks about (https://www.youtube.com/watch?v=VdD0nHbcyk4).
What I would find worrisome too is that this approach sounds like compile time city. A lot of the recent advancements in Julia have been by sending less to LLVM: optimizations are done in Julia and dead code is eliminated, calls are found to be the same and check caches, and then with v1.9 those caches use precompiled binaries to avoid having to call LLVM again. And the timeline of improvements shows that making LLVM be in the picture as little as possible has lead to some dramatic improvements in Julia's latency (https://viralinstruction.com/posts/latency/). Given what was seen from that, I'm weary of an approach that does everything in LLVM (via MLIR) on an even more dynamic representation (i.e. Python). My guess is that only things with explicit types will compile, and the rest is probably hitting some Python interpreter to avoid this issue.
[If part is using Python/GC through an interpreter though, wouldn't that part be harder to target to accelerators since it wouldn't compile through LLVM? That would mean only the code that is explicitly typed gets the nice new features, but not the Python parts?]
But hey, if this gets Chris Lattner and crew a reason to start taking LLVM compile times more seriously, then it's a win for Julia as well. I'm excited to see how the communities can benefit from one another, especially if Mojo is open source then it can be a win for all (which was definitely not clear in the presentation). And I do think that some of the ideas of lower level memory control are cool and should be added similarly to languages like Julia and Numba.