The changelog looks reasonable, seems like the language is moving in the right direction. I'm excited to try it out once it's open sourced. The dependency on glibc is an unfortunate limitation as it means you can't install Mojo on musl-based systems.
Mojo 1.0 Beta
221–230 of 252 posts
Re: Mojo 1.0 Beta
#222Earlier quoted context omitted.
Watch Chris Lattner's interview with Lex Fridman. He talks about mojo as a 36,000x speedup over Python without any indication that you need to think about vectorization to achieve it.
I'm looking at this transcript and I'm getting a different picture than what you describe https://podscripts.co/podcasts/lex-fridman-podcast/381-chris... . Yea, he doesn't specifically say vectorization and multi-threading or whatever but he also doesn't say you don't need some skill to get to huge speedups.
Does he say that you _do_ need skill to get huge speedups?
In fairness it's been a long time since I watched this, but I remember being struck by how obviously dishonest Lattner was throughout. For example at one point he talks about approachin mojo from a first principles perspective, using the speed of light as a limiting factor for what's computationally possible. Complete bullshit. You'd have to be working at the hardware layer for that to begin to be relevant, and even then photonic computation is years away. It's essentially technobabble.
Re: Mojo 1.0 Beta
#223Earlier quoted context omitted.
I still don’t understand why we lack a language that will take uncomplicated computation heavy code and turn it into SIMD / multi thread / multiprocessing / GPU code with minimal additional syntax. Surely this is the sort of thing compiler / language design nerds dream about? It doesn’t have to guarantee efficiency or provide cutting edge performance in any context … it should just exist! My understanding is that we…
>I still don’t understand why we lack a language that will take uncomplicated computation heavy code and turn it into SIMD / multi thread / multiprocessing / GPU code with minimal additional syntax. It's already (partly) existed called D language, by default it's garbage collected (GC), can also be program without it or hybrid. It's a modern, backward compatible with C and it's included in GCC. The linear algebra sys…
I don't think mojo depends on OpenBLAS or other BLAS implementation. I remember that they took a lot of pride in the early days how
linalg primitives like matmul which was completely written in mojo was faster than MLK, openBLAS and other implementations.
Re: Mojo 1.0 Beta
#224Earlier quoted context omitted.
The people that write the libraries care, why do you think Python is where we’re writing ML code and not MATLAB?
Because MATLAB isn't free to use... (Among other reasons, but that's easily the main one.)
Most of the scientific libraries of note originate in academia where MATLAB is effectively free to users. The cross over to Python was well under way by ~2014
Re: Mojo 1.0 Beta
#225Earlier quoted context omitted.
> All these "Performance friendly" python dialects (Tryton, Pythran, CuTile, Numba, Pycell, cuPy, ...) appears like Python but are nothing like Python as soon as you scratch the surface. Which is the whole point. Python has properties that make it bad for massive, fast number twiddling. However, it’s exceptionally nice for doing all the command line parsing and file loading and setup and other wrapping tasks required…
I wouldn't call it "exceptionally nice". Decentish if you use uv & strict Pyright... sure. > most Python code spends a huge chunk of its time waiting for other code to execute. Highly dependent on what you are doing. That hasn't been my experience most of the time.
> I wouldn't call it "exceptionally nice"
I guess depends on your reference point :-) I recall in the beginning, python offering an easier/more readable alternative to Perl, which itself was a step up from awk/sed/sh script (for the tasks/uses GP mentions)
Re: Mojo 1.0 Beta
#226Earlier quoted context omitted.
That’s like saying “surely a high level language can solve the halting problem.” Yes, it can, but only by eliminating the features that make it Turing complete. It’s relatively easy to vectorize map with a closure that can’t mutate anything but once you have nontrivial control flow, the compiler can’t make those kinds of assumptions.
It’s really not! We’re not requiring the language to make optimal choices, just that it convert the same code to these different paradigms (and honestly you could just brute force run the 12 versions and choose the fastest one). Absolutely no theory barriers apply!
You should design it!
Re: Mojo 1.0 Beta
#227Modular is going to open source the entire mojo SDK later this year, including the compiler.
> Mojo 1.0 will be finalized later this year, along with opening the compiler and providing language stability.
https://www.modular.com/blog/modular-26-3-mojo-1-0-beta-max-...
Re: Mojo 1.0 Beta
#228As someone in ML who's interested in performance, I'm keen for Mojo to succeed - especially the prospect of mixing GPU and CPU code in the same language. But I do wonder if the changes they're making will dissuade Python devs. The last time I booted it up, I tried to do some basic string manipulation just to test stuff out, but spent an hour puzzling out why `var x = 'hello'; print(x[3])` didn't work, and neither did…
I still don’t understand why we lack a language that will take uncomplicated computation heavy code and turn it into SIMD / multi thread / multiprocessing / GPU code with minimal additional syntax. Surely this is the sort of thing compiler / language design nerds dream about? It doesn’t have to guarantee efficiency or provide cutting edge performance in any context … it should just exist! My understanding is that we…
julia StaticCompiler.jl is the closest to doing this but its buggy, the error messages are terrible, theres no documentation and its ambiguous whether its still in development. but ive looked, nothing better exists.
Re: Mojo 1.0 Beta
#229Earlier quoted context omitted.
> 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…
> 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? 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 hardw…
> Ah, it seems impossible to you. These are very different hardwares...
In effect, they are completely different hardware. The only thing any of them have in common is rasterization primitives, so unless you're focused on render workloads you're nearly better off software-accelerating the language for CPUs instead. As a point of comparison, go look at early ray tracing implementations on GPUs that have no dedicated RT blocks or hardware-accelerated denoising. They were oftentimes slower than software-accelerating the same thing on a cheaper CPU.
> I'm asking you to imagine how much easier everything would have been if Cuda was cross-platform
...you are aware of what CUDA actually does, right? Mojo is not a cross-platform version of it. At risk of repeating myself, creating an OpenCL-style library without a Khronos-style consortium does not address the problem. CUDA is a hardware solution, you need to define standards around GPGPU programming because that's what Nvidia does internally. Ignoring industry-wide standardization is the express bet that Nvidia and Google are making, investing in Mojo. Without any hardware stakeholders, Mojo's only opportunity is to become a DirectML/ONNX-style middleware like @pjmlp suggested. Spoiler: that's not a super disruptive or successful goal. Certainly not an LLVM scale opportunity.
> So much information could be passed during compile time which the compiler uses to specialize.
Like what? None of this is a rhetorical question, explain to me what information would help bring GPUs and TPUs up to parity with CUDA. What information are you thinking of that isn't currently expressed in SPIR-V and MLIR? What optimizations do you have in mind?
Re: Mojo 1.0 Beta
#230Earlier quoted context omitted.
It’s really not! We’re not requiring the language to make optimal choices, just that it convert the same code to these different paradigms (and honestly you could just brute force run the 12 versions and choose the fastest one). Absolutely no theory barriers apply!
You should design it!
Some kind soul pointed to Intel’s https://ispc.github.io/ which is basically this.
Missing some features but roughly has the idea. Keep faith with human ingenuity!