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

61–66 of 66 posts

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

#61

Post by mathisfun123 »

nvm0n2 wrote: post #60
mathisfun123 wrote: post #18

Earlier quoted context omitted.

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

It's not 10x but GraalPy can speed up unmodified Python by 3.4x on average: https://www.graalvm.org/python/ And they've not been going at it that long. A few years at most.

graalpy does not fully support C extensions and will have just as hard a time extending support as anyone else. maybe even the hardest because they're plumbing through the JVM which, notoriously, has bad C FFI (at least until recently?).

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

#62

Post by chrislattner »

pjmlp wrote: post #53
CoreyFieldens wrote: post #42

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

They already failed once with Swift for Tensorflow, so I am currently curious if there will be some lessons learned from that effort. For the time being, my chips are still on the Julia horse.

I was responsible for the S4TF effort at Google. In my opinion, it validated that some of the ideas are good (e.g. Graph Program Extraction is the algorithm that torch dynamo uses internally), that an efficient compiled language has benefits etc. However, I also learned that it should not be based on Swift and should not be based on TensorFlow. Other than those two things, everything is great ;-)

More on GPE if you're curious: https://llvm.org/devmtg/2018-10/slides/Hong-Lattner-SwiftFor...

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

#63

Post by pjmlp »

chrislattner wrote: post #62
pjmlp wrote: post #53

Earlier quoted context omitted.

They already failed once with Swift for Tensorflow, so I am currently curious if there will be some lessons learned from that effort. For the time being, my chips are still on the Julia horse.

I was responsible for the S4TF effort at Google. In my opinion, it validated that some of the ideas are good (e.g. Graph Program Extraction is the algorithm that torch dynamo uses internally), that an efficient compiled language has benefits etc. However, I also learned that it should not be based on Swift and should not be based on TensorFlow. Other than those two things, everything is great ;-) More on GPE if you'r…

Thanks for replying, and the clarification.

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

#64

Post by nvm0n2 »

mathisfun123 wrote: post #61
nvm0n2 wrote: post #60

Earlier quoted context omitted.

It's not 10x but GraalPy can speed up unmodified Python by 3.4x on average: https://www.graalvm.org/python/ And they've not been going at it that long. A few years at most.

graalpy does not fully support C extensions and will have just as hard a time extending support as anyone else. maybe even the hardest because they're plumbing through the JVM which, notoriously, has bad C FFI (at least until recently?).

It's incomplete but it does support C extensions and can run code with NumPy and other science modules.

Their approach is unique which is why it can work (they proved out the idea with ruby already). They compile the modules with LLVM and then extend the Python interpreter/JIT compiler with support for LLVM bitcode. So the JITC compiles both Python and C extensions together as one unit. The interpreter API is then virtualized so that code that looks like a structure read or method call from C is compiled directly down to the optimized machine code being used by the rest of the JITC. In this way the interop overhead can be optimized out.

This is all separate tech that goes well beyond a normal FFI. JNI doesn't even get involved at all.

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

#65

Post by mathisfun123 »

nvm0n2 wrote: post #64
mathisfun123 wrote: post #61

Earlier quoted context omitted.

graalpy does not fully support C extensions and will have just as hard a time extending support as anyone else. maybe even the hardest because they're plumbing through the JVM which, notoriously, has bad C FFI (at least until recently?).

It's incomplete but it does support C extensions and can run code with NumPy and other science modules. Their approach is unique which is why it can work (they proved out the idea with ruby already). They compile the modules with LLVM and then extend the Python interpreter/JIT compiler with support for LLVM bitcode. So the JITC compiles both Python and C extensions together as one unit. The interpreter API is then vi…

from reading, some of this isn't quite correct (it's graalvm that supports bitcode), but i have to say i didn't realize that that's what they were doing (compiling python and llvm bitcode to graalvm both). interesting but okay you have to admit that's a fairly "beyond scope" approach - ie they solve the problem of C extensions not by compiling python to C but by compiling both to JVM. anyway thanks.

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

#66

Post by balencpp »

aidenn0 wrote: post #34
Certhas wrote: post #13

Earlier quoted context omitted.

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

But people use numpy for matrix multiplies in Python. Unless they are claiming to be 35k times faster on general-purpose code, the 35k number is absurd.

A lot of ugly,unreadable code has come into existence because of the need to twist it into NumPy calls. If you can replace these with good old for loops and achieve similar performance, then you've already won. Besides that, there are a lot of code that involves looping that isn't matrix multiplication or covered by NumPy.
Post reply on HN