9 ms·

Nooooo if Python gets faster then all the Mojo demos are going to sound so much less impressive nooo

albertzeyer 3y ago
JAX or torch.compile also do sth similar as Mojo, right?
npalli 3y ago
I don't know, looks like ~15% improvement [1]. Doubt the Mojo guys are going to lose much sleep (they claimed 35,000x improvement). [1] https://speed.python.org/comparison/?exe=12%2BL%2B3.11%2C12%2BL%2Bmaster&ben=741%2C742%2C743%2C744%2C745%2C746%2C747%2C748%2C749%2C799%2C800%2C750%2C751%2C802%2C752%2C753%2C754%2C755%2C756%2C757%2C758%2C759%2C760%2C761%2C762%2C763%2C764%2C765%2C766%2C767%2C768%2C769%2C770%2C771%2C772%2C773%2C774%2C775%2C776%2C777%2C778%2C779%2C780%2C781%2C782%2C783%2C784%2C785%2C786%2C788%2C787%2C789%2C790%2C791%2C792%2C793%2C794%2C797%2C796%2C795%2C798&env=1&hor=true&bas=12%2BL%2B3.11&chart=normal+bars https://speed.python.org/comparison/?exe=12%2BL%2B3.11%2C12%...
- TwentyPosts 3y ago
  Somehow I'm still skeptical! Feels like "strict superset of Python, all Python code works" and "several orders of magnitude faster" just sounds like you're trying to have your cake and eat it, too. I doubt that the Mojo developers have some sort of 'secret sauce' or 'special trick' that will get them there. And even if they have something, I don't see why the Python devs wouldn't just implement the same approach, considering they're currently trying to make Python faster. I assume that (as long as Mojo wants to stick to its goal of being a strict superset of Python), there will be a lot of things that just cannot be 'fixed'. For example, I'd be surprised if Python's Global Interpreter Lock isn't entangled with the language in a few nasty ways that'd make it really difficult to replace or improve upon (while retaining compatibility). Then again, the developer of Swift is working on it, right? I guess he's got the experience, at least.
  - School-Cotton 3y ago
    IDK about 35,000x but Python really is outrageously slow relative to other popular languages, even other interpreted ones. It's more comparable to something like Ruby than to something like JavaScript.
    - williamstein 3y ago
      From their FAQ: "How compatible is Mojo with Python really? Mojo already supports many core features of Python including async/await, error handling, variadics, etc, but… it is still very early and missing many features - so today it isn’t very compatible. Mojo doesn’t even support classes yet!". Overall, pure Python seems to be about 100x slower than what you can reasonably get with a compiled language and some hard work. It's about 10x slower than what you can get from JITs like Pypy and Javascript, when such comparisons makes sense. I agree that Mojo remind me of Cython, but with more marketing and less compatibility with Python. Cython aspired to be a nearly 99% superset of Python, at least that's exactly what I pushed my postdocs and graduate students to make it be back in 2009 (e.g., there were weeks of Robert Bradshaw and Craig Citro pushing each other to get closures to fully work). Mojo seems to be a similar modern idea for doing the same sort of thing. It could be great for the ecosystem; time will tell. Cython could still also improve a lot too -- there is a major new 3.0 release just around the corner!: https://pypi.org/project/Cython/#history https://pypi.org/project/Cython/#history
      - deleted 3y ago
        [deleted]
  - wiseowise 3y ago
    Isn’t Mojo compiled? While Python needs to be interpreted.
    - TwentyPosts 3y ago
      Mojo bothers offers Just-In-Time and Ahead-Of-Time models. Proper AOT compilation is going to offer a significant speedup, but probably not enough to get to their stated goals. And good luck carrying all of Python's dynamic features across the gap.
- tgma 3y ago
  That comparison seems quite cherry picked. Unlikely that it is generalizable. In my tests with Mojo, it doesn’t seem to behave like Python at all so far. Once they add the dynamism necessary we can see where they land. I’m still optimistic (mostly since Python has absolute garage performance and there’s low hanging fruit) but it’s no panacea. I feel their bet is not to have to run Python as is but have Python developers travel some distance and adapt to some constraints. They just need enough momentum to make that transition happen but it’s a transition to a distinct language, not a Python implementation. Sort of what Hack is to PHP.
  - SOLAR_FIELDS 3y ago
    Hack as a comparison is probably not a great thing for Mojo, since no one outside of Facebook uses Hack.
    - tgma 3y ago
      Safe to say no one outside of Modular uses Mojo either at the moment.
- KeplerBoy 3y ago
  I don't buy the mojo hype. The concept of compiling python has been tried again and again. It has its moments, but anything remotely important is glued in from compiled code anyways.
  - ptx 3y ago
    From a quick reading of the Mojo website, it sounds like gluing in compiled code is exactly what they're doing, except this time the separate compiled language happens to look sort of like Python a bit. For the actual Python code it still uses CPython, so that part doesn't get any faster.
    - morelisp 3y ago
      Pyrex, Cython, mypyc, Codon... we've been down this road before plenty too. If Mojo succeeds it will be purely based on quality of implementation, not a spark of genius.
      - pdpi 3y ago
        The "spark of genius" might very well be a novel implementation strategy.
        neolefty 3y ago
        It leverages the Multi-Level Intermediate Representation (MLIR) https://mlir.llvm.org/ https://mlir.llvm.org/ which is a follow-on from LLVM, with lots of lessons learned: https://www.hpcwire.com/2021/12/27/lessons-from-llvm-an-sc21-fireside-chat-with-chris-lattner/ https://www.hpcwire.com/2021/12/27/lessons-from-llvm-an-sc21...
        morelisp 3y ago
        Again, "compile to an IR" isn't exactly ground-breaking. The devil will be in the details.
      - deleted 3y ago
- klyrs 3y ago
  I've been rewriting Python->C for nearly 20 years now. The expected speedup is around 100x, or 1000x for numerical stuff or allocation-heavy work that can be done statically. Whenever you get 10,000x or above, it's because you've written a better algorithm. You can't generalize that. A 35k speedup is a cool demo but should be regarded as hype.
  - nomel 3y ago
    > The expected speedup is around 100x, or 1000x for numerical stuff What if you stay in the realm of numpy? What's the biggest offender that you see?
    - klyrs 3y ago
      > What if you stay in the realm of numpy? You mean, what if you're only doing matrix stuff? Then it's probably easier to let numpy do the heavy lifting. You'll probably take less than a 5x performance hit, if you're doing numpy right. And if you're doing matrix multiplication, numpy will end up faster because it's backed by a BLAS, which mortals such as myself know better than to compete with. > What's the biggest offender that you see? Umm... every line of Python? Member access. Function calls. Dictionaries that can fundamentally be mapped to int-indexed arrays. Reference counting. Tuple allocation. One fun exercise is to take your vanilla python code, compile it in Cython with the -a flag to produce an HTML annotation. Click on the yellowest lines, and it shows you the gory details of what Cython does to emulate CPython. It's not exactly what CPython is doing (for example, Cython elides the virtual machine), but it's close enough to see where time is spent. Put the same code through the python disassembler "dis" to see what virtual machine operations are emitted, and paw through the main evaluation loop [1]; or take a guided walkthrough at [2]. [1] https://github.com/python/cpython/blob/v3.6.14/Python/ceval.c#L1274 https://github.com/python/cpython/blob/v3.6.14/Python/ceval.... (note this is an old version, you can change that in the url) [2] https://leanpub.com/insidethepythonvirtualmachine/read https://leanpub.com/insidethepythonvirtualmachine/read
      - vbarrielle 3y ago
        Due to the possibility to fuse multiple operations in C++ (whereas you often have intermediate arrays in numpy), I routinely get 20x speedups when porting from numpy to C++. Good libraries like eigen help a lot.
- ehsankia 3y ago
  35,000x suddenly becomes 30,000x, not as impressive!
- Alex3917 3y ago
  How does that reconcile with the benchmarks here, which say that Python 2.12 is currently somewhere between 5% slower to 5% faster? https://github.com/faster-cpython/benchmarking-public https://github.com/faster-cpython/benchmarking-public
- make3 3y ago
  if it's an improvement that big it needs to be with GPUs, & gpus can be used normally with torch etc
traverseda 3y ago
Meh, mypyc and codon both do the same thing as mojo. Codon seems to have similar speed improvements and the source code is available.
- jjtheblunt 3y ago
  Do they compile to MLIR so when Alteryx writes a code generator you can target FPGAs, for example?
  - traverseda 3y ago
    LLVM ir. So probably there are some flags somewhere. Also supports openmp and gpu compute through decorators.

JAX or torch.compile also do sth similar as Mojo, right?

I don't know, looks like ~15% improvement [1]. Doubt the Mojo guys are going to lose much sleep (they claimed 35,000x improvement). [1] https://speed.python.org/comparison/?exe=12%2BL%2B3.11%2C12%2BL%2Bmaster&ben=741%2C742%2C743%2C744%2C745%2C746%2C747%2C748%2C749%2C799%2C800%2C750%2C751%2C802%2C752%2C753%2C754%2C755%2C756%2C757%2C758%2C759%2C760%2C761%2C762%2C763%2C764%2C765%2C766%2C767%2C768%2C769%2C770%2C771%2C772%2C773%2C774%2C775%2C776%2C777%2C778%2C779%2C780%2C781%2C782%2C783%2C784%2C785%2C786%2C788%2C787%2C789%2C790%2C791%2C792%2C793%2C794%2C797%2C796%2C795%2C798&env=1&hor=true&bas=12%2BL%2B3.11&chart=normal+bars https://speed.python.org/comparison/?exe=12%2BL%2B3.11%2C12%...

TwentyPosts 3y ago
Somehow I'm still skeptical! Feels like "strict superset of Python, all Python code works" and "several orders of magnitude faster" just sounds like you're trying to have your cake and eat it, too. I doubt that the Mojo developers have some sort of 'secret sauce' or 'special trick' that will get them there. And even if they have something, I don't see why the Python devs wouldn't just implement the same approach, considering they're currently trying to make Python faster. I assume that (as long as Mojo wants to stick to its goal of being a strict superset of Python), there will be a lot of things that just cannot be 'fixed'. For example, I'd be surprised if Python's Global Interpreter Lock isn't entangled with the language in a few nasty ways that'd make it really difficult to replace or improve upon (while retaining compatibility). Then again, the developer of Swift is working on it, right? I guess he's got the experience, at least.
- School-Cotton 3y ago
  IDK about 35,000x but Python really is outrageously slow relative to other popular languages, even other interpreted ones. It's more comparable to something like Ruby than to something like JavaScript.
  - williamstein 3y ago
    From their FAQ: "How compatible is Mojo with Python really? Mojo already supports many core features of Python including async/await, error handling, variadics, etc, but… it is still very early and missing many features - so today it isn’t very compatible. Mojo doesn’t even support classes yet!". Overall, pure Python seems to be about 100x slower than what you can reasonably get with a compiled language and some hard work. It's about 10x slower than what you can get from JITs like Pypy and Javascript, when such comparisons makes sense. I agree that Mojo remind me of Cython, but with more marketing and less compatibility with Python. Cython aspired to be a nearly 99% superset of Python, at least that's exactly what I pushed my postdocs and graduate students to make it be back in 2009 (e.g., there were weeks of Robert Bradshaw and Craig Citro pushing each other to get closures to fully work). Mojo seems to be a similar modern idea for doing the same sort of thing. It could be great for the ecosystem; time will tell. Cython could still also improve a lot too -- there is a major new 3.0 release just around the corner!: https://pypi.org/project/Cython/#history https://pypi.org/project/Cython/#history
    - deleted 3y ago
      [deleted]
- wiseowise 3y ago
  Isn’t Mojo compiled? While Python needs to be interpreted.
  - TwentyPosts 3y ago
    Mojo bothers offers Just-In-Time and Ahead-Of-Time models. Proper AOT compilation is going to offer a significant speedup, but probably not enough to get to their stated goals. And good luck carrying all of Python's dynamic features across the gap.
tgma 3y ago
That comparison seems quite cherry picked. Unlikely that it is generalizable. In my tests with Mojo, it doesn’t seem to behave like Python at all so far. Once they add the dynamism necessary we can see where they land. I’m still optimistic (mostly since Python has absolute garage performance and there’s low hanging fruit) but it’s no panacea. I feel their bet is not to have to run Python as is but have Python developers travel some distance and adapt to some constraints. They just need enough momentum to make that transition happen but it’s a transition to a distinct language, not a Python implementation. Sort of what Hack is to PHP.
- SOLAR_FIELDS 3y ago
  Hack as a comparison is probably not a great thing for Mojo, since no one outside of Facebook uses Hack.
  - tgma 3y ago
    Safe to say no one outside of Modular uses Mojo either at the moment.
KeplerBoy 3y ago
I don't buy the mojo hype. The concept of compiling python has been tried again and again. It has its moments, but anything remotely important is glued in from compiled code anyways.
- ptx 3y ago
  From a quick reading of the Mojo website, it sounds like gluing in compiled code is exactly what they're doing, except this time the separate compiled language happens to look sort of like Python a bit. For the actual Python code it still uses CPython, so that part doesn't get any faster.
  - morelisp 3y ago
    Pyrex, Cython, mypyc, Codon... we've been down this road before plenty too. If Mojo succeeds it will be purely based on quality of implementation, not a spark of genius.
    - pdpi 3y ago
      The "spark of genius" might very well be a novel implementation strategy.
      - neolefty 3y ago
        It leverages the Multi-Level Intermediate Representation (MLIR) https://mlir.llvm.org/ https://mlir.llvm.org/ which is a follow-on from LLVM, with lots of lessons learned: https://www.hpcwire.com/2021/12/27/lessons-from-llvm-an-sc21-fireside-chat-with-chris-lattner/ https://www.hpcwire.com/2021/12/27/lessons-from-llvm-an-sc21...
        morelisp 3y ago
        Again, "compile to an IR" isn't exactly ground-breaking. The devil will be in the details.
    - deleted 3y ago
klyrs 3y ago
I've been rewriting Python->C for nearly 20 years now. The expected speedup is around 100x, or 1000x for numerical stuff or allocation-heavy work that can be done statically. Whenever you get 10,000x or above, it's because you've written a better algorithm. You can't generalize that. A 35k speedup is a cool demo but should be regarded as hype.
- nomel 3y ago
  > The expected speedup is around 100x, or 1000x for numerical stuff What if you stay in the realm of numpy? What's the biggest offender that you see?
  - klyrs 3y ago
    > What if you stay in the realm of numpy? You mean, what if you're only doing matrix stuff? Then it's probably easier to let numpy do the heavy lifting. You'll probably take less than a 5x performance hit, if you're doing numpy right. And if you're doing matrix multiplication, numpy will end up faster because it's backed by a BLAS, which mortals such as myself know better than to compete with. > What's the biggest offender that you see? Umm... every line of Python? Member access. Function calls. Dictionaries that can fundamentally be mapped to int-indexed arrays. Reference counting. Tuple allocation. One fun exercise is to take your vanilla python code, compile it in Cython with the -a flag to produce an HTML annotation. Click on the yellowest lines, and it shows you the gory details of what Cython does to emulate CPython. It's not exactly what CPython is doing (for example, Cython elides the virtual machine), but it's close enough to see where time is spent. Put the same code through the python disassembler "dis" to see what virtual machine operations are emitted, and paw through the main evaluation loop [1]; or take a guided walkthrough at [2]. [1] https://github.com/python/cpython/blob/v3.6.14/Python/ceval.c#L1274 https://github.com/python/cpython/blob/v3.6.14/Python/ceval.... (note this is an old version, you can change that in the url) [2] https://leanpub.com/insidethepythonvirtualmachine/read https://leanpub.com/insidethepythonvirtualmachine/read
    - vbarrielle 3y ago
      Due to the possibility to fuse multiple operations in C++ (whereas you often have intermediate arrays in numpy), I routinely get 20x speedups when porting from numpy to C++. Good libraries like eigen help a lot.
ehsankia 3y ago
35,000x suddenly becomes 30,000x, not as impressive!
Alex3917 3y ago
How does that reconcile with the benchmarks here, which say that Python 2.12 is currently somewhere between 5% slower to 5% faster? https://github.com/faster-cpython/benchmarking-public https://github.com/faster-cpython/benchmarking-public
make3 3y ago
if it's an improvement that big it needs to be with GPUs, & gpus can be used normally with torch etc

traverseda 3y ago

Meh, mypyc and codon both do the same thing as mojo. Codon seems to have similar speed improvements and the source code is available.

jjtheblunt 3y ago
Do they compile to MLIR so when Alteryx writes a code generator you can target FPGAs, for example?
- traverseda 3y ago
  LLVM ir. So probably there are some flags somewhere. Also supports openmp and gpu compute through decorators.