Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Mojo gets a speedup over Python – Part 2

modular.com

Post reply on HN
Print view View original

11–20 of 66 posts

Re: How Mojo gets a speedup over Python – Part 2

#11

Post by sebzim4500 »

dandiep wrote: post #10

I 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…

They aren't just speeding up existing python code, they are making a superset of python which has additional performance features.

I guess it's possible that these features will be introduced into cpython etc. but I doubt it.

Re: How Mojo gets a speedup over Python – Part 2

#12

Post by gojomo »

dandiep wrote: post #10

I 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" alternatives, to create the impetus to get new things integrated.

Re: How Mojo gets a speedup over Python – Part 2

#13

Post by Certhas »

frakt0x90 wrote: post #8

At least they included numpy in this one. On their last post, after all their optimizations, numpy.matmul() produced almost the exact same throughput as their most optimized example. Would still need to dig in to see if this one has issues. Benchmarks are always such a minefield.

matmul is a wrapper for BLAS. If you're faster than BLAS you're beating handwritten assembler code specialized per CPU architecture.

Re: How Mojo gets a speedup over Python – Part 2

#14

Post by zengid »

I'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 makes a SwiftUI-like cross platform UI library with it ;).

Re: How Mojo gets a speedup over Python – Part 2

#15

Post by bjourne »

deepsquirrelnet wrote: post #9

I don’t understand this from a goals perspective. What is an “AI compiler” - and why aren’t they comparing benchmarks with technologies more commonly used in AI? I think I should be impressed, but I feel like I’m missing the point.

I guess the point is that getting the same performance in most other languages requires hundreds of lines of code. Here they are ostensibly achieving that performance using very succinct code. That is pretty nice especially if it integrates well with Python.

Re: How Mojo gets a speedup over Python – Part 2

#17

Post by leecarraher »

35Kx 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. 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.

Re: How Mojo gets a speedup over Python – Part 2

#18

Post by mathisfun123 »

melling wrote: post #3
Kelteseth wrote: post #2

So TL;DR: Using SIMD and multithreading is faster than doing no optimization in python. The only real comparison here is when not doing any optimization is: > The above code produced a 90x speedup over Python and a 15x speedup over NumPy as shown in the figure below: Am I missing something?

Getting >10x speed up isn’t exciting enough for many people? I’ll take it. This is all pretty impressive if I can take my unmodified (slightly modified?) Python code and get that sort of improvement.

> This is all pretty impressive if I can take my unmodified (slightly modified?) Python code and get that sort of improvement.

it'll never work as smoothly as they advertise. just hands down, beyond a shadow of a doubt, their claims about supporting "unmodified" Python code are startup hype. how do i know? i could give you a bunch of technical reasons about Python as a language and CPython as the de facto implementation (thereby informing tons of code already written, re extensions) but there's a much simpler way to reason about it: because there are already >10 attempts at this and no one has been able to do it. there's no magic here that any number of dollars or brains could pull off. instead each such project picks a point on the pythonicperformant design-space tradeoff curve and then asks/expects you to live with that choice.

and taking ^ into consideration, mojo is not that special. only thing going for it is chris lattner isn't bad at designing languages so maybe, on its own, it'll be a nice language (but it needs to be open to get any traction on its own).

Re: How Mojo gets a speedup over Python – Part 2

#19

Post by pjmlp »

dandiep wrote: post #10

I 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…

Plenty of OpenJDK alternatives still exist, just like there are several C and C++ compilers.
Post reply on HN