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

41–50 of 66 posts

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

#41

Post by leecarraher »

ElectronCharge wrote: post #22
leecarraher wrote: post #17

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

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

> Right. However, this is a comparison versus Python and the GIL, which can’t do that at all.

Single process python does not take advantage of a multicore architecture but neither would single process mojo. Embarrassingly parallel operations like mandlebrot can trivially be written with multiprocessing (https://github.com/DipanshuSehjal/Mandelbrot-set/blob/master...), or joblib to run in parallel in otherwise vanilla python. It would be trivial to implement this in jax and run on a gpu or tpu, but i wouldn't say that jax is the reason for the speed up.

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

#42

Post by CoreyFieldens »

I'm really interested in Mojo not for its AI applications, but as an alternative to Julia for high performance computing. Like Julia, Mojo is also attempting to solve the two-language problem, but I like that Mojo is coming at it from a Python perspective rather than trying to create new syntax. For better or for worse, Python is absolutely dominating in the field of scientific computing, and I don't see that changing anytime soon. Being able to write optimizations at a lower level in a Python-like syntax is really appealing to me.

Furthermore, while I love Julia the language, I'm disappointed in how it really hasn't taken off in adoption by either academia or industry. The community is small and that becomes a real pain point when it comes to tooling. Using the debugger is an awful experience and the VSCode extension that is recommended way to write Julia is very hit-or-miss. I think it would really benefit from a lot more funding that doesn't actually seem to be coming. It's not a 1-to-1 comparison, but Modular has received 3 times the amount of funding as JuliaHub despite being much younger.

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

#43

Post by ElectronCharge »

dandiep wrote: post #26
gojomo wrote: post #12

Earlier quoted context omitted.

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)

Modular is mainly focused on improving AI related workflows as its business model. That market is easily many $billions, and I think most expect the AI industry to experience explosive growth.

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

#45

Post by Takennickname »

dandiep wrote: post #26
gojomo wrote: post #12

Earlier quoted context omitted.

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)

This is an investment in the team not the idea.

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

#46

Post by Takennickname »

mathisfun123 wrote: post #18
melling wrote: post #3

Earlier quoted context omitted.

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

> i could give you a bunch of technical reasons about Python as a language and CPython as the de facto implementation

Please do. I'm very interested.

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

#47

Post by brrrrrm »

I just want to see real un-hyped benchmarks. Comparing random Python native code makes no sense and seems dishonest, deterring me from actually trying out the tool.

I want a Python that can statically plan underlying GPU allocations, avoids CUDA kernel dispatch overhead and enables a multi-GPU API that isn't some multiprocessing abomination.

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

#49

Post by ElectronCharge »

leecarraher wrote: post #41
ElectronCharge wrote: post #22

Earlier quoted context omitted.

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

> Right. However, this is a comparison versus Python and the GIL, which can’t do that at all. Single process python does not take advantage of a multicore architecture but neither would single process mojo. Embarrassingly parallel operations like mandlebrot can trivially be written with multiprocessing ( https://github.com/DipanshuSehjal/Mandelbrot-set/blob/master... ), or joblib to run in parallel in otherwise vanil…

> Single process python does not take advantage of a multicore architecture but neither would single process mojo.

That is exactly not the case. The Mandelbrot demo IS a single process, multi-threaded, SIMD-enabled Mojo program that uses 88 processor cores.

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

#50

Post by ElectronCharge »

anonymouse008 wrote: post #4
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?

So does this mean Swift and Metal offers the same if not better performance enhancements? SIMD is very much a first class citizen as a type there

No, Lattner learned from Swift and is avoiding anything except zero-cost abstractions.

Also, Swift isn’t very interesting outside the Apple ecosystem, and Metal doesn’t exist outside the Apple ecosystem. Mojo has a real shot at widespread, general-purpose, language adoption!

Post reply on HN