Why is this a language superset of python rather than a python library? Genuinely asking and not trying to bash
How Mojo gets a speedup over Python – Part 2
21–30 of 66 posts
Re: How Mojo gets a speedup over Python – Part 2
#2235Kx speedup is not scaled speedup. Throw this, naively parallelizable task at a bigger computer and get 70kx speedup, etc. While i think there are tons of optimizations to be done for python (looking at you GIL) giving access to low level cpu primitives is not one I think that will be broadly adopted by the python community. That's one of the joys of python: system agnostic, looks pretty close to pseudocode, coding.…
> 35Kx speed up is not scaled speed up.
Right. However, this is a comparison versus Python and the GIL, which can’t do that at all.
> While i think there are tons of optimizations to be done for python (looking at you GIL) giving access to low level cpu primitives is not one I think that will be broadly adopted by the python community.
It doesn’t need to be, any more than writing Numba or Pyrex is done on a large scale.
> That's one of the joys of python: system agnostic, looks pretty close to pseudocode, coding. If you want speed, glue together a bunch of compiled code calls, and hope the call overhead isn't too large. Or write cpu intensive operations in numba, or pyrex. At the end of the day, mojo's pay to play programming language harkens back to the early 90's Borland days.
The appeal is having a high level language that compiles to efficient machine (and GPU!) code. One can “drop down” to Python for non performance intensive parts.
I think this will be much more of a draw for people coming from C++, Fortran and other older, jankier languages. It looks to hit a sweet spot for real time embedded development VERY well, especially given Rust-like memory safety!
Mojo will also be a worthy competitor to Julia in the HPC scientific arena I think…we’ll see!
Re: How Mojo gets a speedup over Python – Part 2
#23They lost me with the emoji for file extension. That’s not a world I want to live in.
Re: How Mojo gets a speedup over Python – Part 2
#24Why is this a language superset of python rather than a python library? Genuinely asking and not trying to bash
That sounds intractable.
How would you differentiate mojo code from vanilla python without a ton of boilerplate at language boundaries.
Re: How Mojo gets a speedup over Python – Part 2
#25They lost me with the emoji for file extension. That’s not a world I want to live in.
You don’t have to, “.mojo” is equivalent.
Re: How Mojo gets a speedup over Python – Part 2
#26I don't understand the play here for Modular. If this is a worthwhile improvement that is broadly applicable, won't it at some point make it's way into Python, numpy, etc? In Java land we had a bunch of other JVMs over the years offering better performance. Most important things got absorbed into what is now OpenJDK, and the other JVMs, if they even exist at all, are niche players. Performance is a huge focus in Pyth…
If they've figured out how to deliver performance that Python might get around to in 5-10y, shouldn't they tout that, for people who might want that now? Ultimately promoting the possibility for better performance, & current contrast, is good for prodding other languages/runtimes like Python to match these options. The "important things [get] absorbed" process you mention relies on teams making some "play for" altern…
Totally, just trying to understand why this is a $100MM of VC money investment. Is the market that big for this? (Honest question)
Re: How Mojo gets a speedup over Python – Part 2
#27I'm pretty excited about Mojo and have been keeping an eye on it's development. I feel like the team has learned a lot from their experience, and are taking the best from languages like Python, Rust, Swift, Hylo (Formerly known as Val), and are taking a really nice pragmatic approach in implementing them so that the language is approachable , but also very safe and fast. Once it's out, I hope someone sits down and ma…
Yeah, I've been following and am interested too.
Actually more interested in things like UIs, quick API servers, stuff like that than the AI/ML use cases. The idea of most of the ease and approachability of Python, a proper type system, and access to the entire ecosystem of Python libs in a compiled language is pretty compelling.
Re: How Mojo gets a speedup over Python – Part 2
#28Cool, but it has very little to do with Python, except some similar looking syntax. So for a Python programmer with a performance problem, it doesn't look like a solution.
They are also building in pretty serious Python interop. You should be able to at least somewhat mix the two or migrate gradually, and still use Python libs for less performance critical code (or if the libs do their performance critical stuff in C++ or whatever and are therefore fast enough).
Re: How Mojo gets a speedup over Python – Part 2
#29Still waiting if all of this will be another Swift for Tensorflow, or actually make a difference.
[deleted]
Re: How Mojo gets a speedup over Python – Part 2
#30I'm pretty excited about Mojo and have been keeping an eye on it's development. I feel like the team has learned a lot from their experience, and are taking the best from languages like Python, Rust, Swift, Hylo (Formerly known as Val), and are taking a really nice pragmatic approach in implementing them so that the language is approachable , but also very safe and fast. Once it's out, I hope someone sits down and ma…
Yeah, I've been following and am interested too. Actually more interested in things like UIs, quick API servers, stuff like that than the AI/ML use cases. The idea of most of the ease and approachability of Python, a proper type system, and access to the entire ecosystem of Python libs in a compiled language is pretty compelling.
I agree, I'm excited to use it as a General Purpose language, and see how far the Autotuning feature can go for just normal old apps and servers.