211–220 of 252 posts
> We have committed to open-sourcing Mojo in Fall 2026. https://docs.modular.com/mojo/faq/#will-mojo-be-open-sourced
Nice. I'd love to see the source of an actual state of the art MLIR program.
IREE [2] is very actively developed ML compiler + runtime, also MLIR-based.
Earlier quoted context omitted.
And for not staying behind, Intel and AMD are doing similar efforts, and then we have the whole CPython JIT finally happening after so many attempts. Not to mention efforts like GraalPy and PyPy. And all these efforts work today in Windows, which is quite relevant in companies where that is the assigned device to most employees, even if the servers run Linux distros. I keep wondering if this isn't going to be another…
The CPython JIT has barely had any impact on its performance. CPython is always going to be dog slow.
It only has to be good enough, to keep the ecosystem going, and the porting cost not be worthwhile, when Mojo finally reaches parity.
Earlier quoted context omitted.
The point still stands as middleware.
Have you ever wondered how much work would have been saved by the Pytorch team if they could have used just Cuda for all the platforms they support? If they didn't have to write compatibility abstractions or layers, and instead just focused on the problem of training neural networks? What if all the primitives they used from Cuda and cuDNN worked just as well on AMD GPUs, Apple GPUs, and probably Google's TPUs as the…
Python is basically the master glue language at this point. If more than a few percent of execution time is spent in Python you are probably doing it wrong. Personally I don't even understand why Cython is a thing, just write performance critical functions in other languages: https://pypi.org/project/rustimport/ > https://pypi.org/project/import-zig/ > Note that you can even start threads in those languages and use f…
Cython and PyBind and Nanobind are good for wrapping an existing library written in C++ and crafting an interface that doesn’t feel like it’s a C++ one. They were a big step from ctypes and SWIG
Already available on GCC 16.
Earlier quoted context omitted.
Nice. I'd love to see the source of an actual state of the art MLIR program.
HEIR [1] is a homomorphic encryption compiler built on modern MLIR. IREE [2] is very actively developed ML compiler + runtime, also MLIR-based. [1] https://github.com/google/heir [2] https://github.com/iree-org/iree
Things like optimizing away object allocations, pure function inlining, tail call optimization?
Earlier quoted context omitted.
Have you ever wondered how much work would have been saved by the Pytorch team if they could have used just Cuda for all the platforms they support? If they didn't have to write compatibility abstractions or layers, and instead just focused on the problem of training neural networks? What if all the primitives they used from Cuda and cuDNN worked just as well on AMD GPUs, Apple GPUs, and probably Google's TPUs as the…
> What if all the primitives they used from Cuda and cuDNN worked just as well on AMD GPUs, Apple GPUs, and probably Google's TPUs as they did on Nvidia GPUs? Why should they? CUDA is a GPGPU paradigm, AMD/Apple/Intel all ship diverse raster-focused hardware, and TPUs are a systolic array. How much can you realistically expect to abstract with unified primitives? How much performance do you perceive to be left on the…
Ah, it seems impossible to you. These are very different hardwares... It is hard enough to make compatibility among different hardwares of the same vendor. Very difficult to imagine building primitives for hardwares with completely different memory layouts.
> How much performance do you perceive to be left on the table with native CUDA-based implimentations?
Zero is the idea. And I wasn't saying there should be a native cuda-based implementation, I'm asking you to imagine how much easier everything would have been if Cuda was cross-platform without any performance or ergonomic penalties.
Mojo is a foundational step here. The big HOW is powerful parametric programming. So much information could be passed during compile time which the compiler uses to specialize.
Earlier quoted context omitted.
So? What point are you making? A different language with different design philosophy, has success in a different niche than Mojo is targeting?
One is used in production already by key laboratories in HPC research, the other wants to be and is far away from being 1.0. Chapel current version is 2.8.0.
Earlier quoted context omitted.
They claim you can easily mix them so there is some degree of compatibility.
Every reasonable language has a Python interop story. All it takes is C FFI. But what Mojo promised early on was the eventuality of compiling a large amount of Python code if not entire wheels as Mojo.
Earlier quoted context omitted.
> We're committed to open-sourcing all of Mojo Translated from corporatese it means "it will never happen".
With Chris Lattners track record, there is little reason to doubt they actually will open source this.