Outperforming Rust DNA sequence parsing benchmarks by 50% with Mojo(modular.com)
modular.com
Outperforming Rust DNA sequence parsing benchmarks by 50% with Mojo
https://www.modular.com/blog/outperforming-rust-benchmarks-with-mojo
11 comments
Everything about Mojo is suspicious to me. Maybe I'm paranoid, but Modular has made wild performance claims in the past without releasing much information in regard to implementation [citation needed], plus leaning so far into the AI stuff smells of a marketing-first project IMO.
I think you're being paranoid here :-). I encourage you to download mojo and try it out. This code is all OSS, so go nuts validating it yourself. If you'd like to know how mojo works there is a lot of information on the Modular blog:
https://www.modular.com/blog
e.g. these might be interesting:
https://www.modular.com/blog/mojo-llvm-2023 https://www.modular.com/blog/what-is-loop-unrolling-how-you-...
If you still have doubts, you could join the 20,000+ people in discord chatting about Mojo stuff: https://discord.com/invite/modular
-Chris
https://www.modular.com/blog
e.g. these might be interesting:
https://www.modular.com/blog/mojo-llvm-2023 https://www.modular.com/blog/what-is-loop-unrolling-how-you-...
If you still have doubts, you could join the 20,000+ people in discord chatting about Mojo stuff: https://discord.com/invite/modular
-Chris
Chris, how would you respond to the remark that the article is comparing a flawed Mojo implementation against a more correct Rust implementation? https://news.ycombinator.com/item?id=39296559
> Insightful Reddit comment https://old.reddit.com/r/rust/comments/1al8cuc/modular_commu...
> > The TL;DR is that the Mojo implementation is fast because it essentially memchrs four times per read to find a newline, without any kind of validation or further checking. The memchr is manually implemented by loading a SIMD vector, and comparing it to 0x0a, and continuing if the result is all zeros. This is not a serious FASTQ parser. It cuts so many corners that it doesn't really make it comparable to other parsers (although I'm not crazy about Needletails somewhat similar approach either).
> > I implemented the same algorithm in < 100 lines of Julia and were >60% faster than the provided needletail benchmark, beating Mojo. I'm confident it could be done in Rust, too.
> Insightful Reddit comment https://old.reddit.com/r/rust/comments/1al8cuc/modular_commu...
> > The TL;DR is that the Mojo implementation is fast because it essentially memchrs four times per read to find a newline, without any kind of validation or further checking. The memchr is manually implemented by loading a SIMD vector, and comparing it to 0x0a, and continuing if the result is all zeros. This is not a serious FASTQ parser. It cuts so many corners that it doesn't really make it comparable to other parsers (although I'm not crazy about Needletails somewhat similar approach either).
> > I implemented the same algorithm in < 100 lines of Julia and were >60% faster than the provided needletail benchmark, beating Mojo. I'm confident it could be done in Rust, too.
Here is a cache of valid and invalid FASTQ files for unit tests
https://github.com/biojava/biojava/tree/master/biojava-genom...
https://github.com/biojava/biojava/tree/master/biojava-genom...
As far as I know, the Mojo implementation is doing the same algorithm as the baseline rust implementation. The person commenting on that is complaining about the rust impl as well.
I will certainly dig deeper and give it the in-depth look it deserves. Thanks Chris :)
[deleted]
Is this comparing normal Rust vs Moji with SIMD? I don't see how Mojo can produce faster code than C/C++/Rust. Must all be in the implementation details, I feel this is a misleading title if so.
[deleted]
see https://viralinstruction.com/posts/mojo/. this compares a Rust parser that does some validation to a Mojo "parser" that doesn't do any.
Good point, and also from the article you provided :
I'm sorry but this is not a serious parser. To be fair, the repo is pretty clear that:
Disclaimer: MojoFastTrim is for demonstration purposes only and shouldn't be used as part of bioinformatic pipelines
Disclaimer: MojoFastTrim is for demonstration purposes only and shouldn't be used as part of bioinformatic pipelines
Insightful Reddit comment https://old.reddit.com/r/rust/comments/1al8cuc/modular_commu...
> The TL;DR is that the Mojo implementation is fast because it essentially memchrs four times per read to find a newline, without any kind of validation or further checking. The memchr is manually implemented by loading a SIMD vector, and comparing it to 0x0a, and continuing if the result is all zeros. This is not a serious FASTQ parser. It cuts so many corners that it doesn't really make it comparable to other parsers (although I'm not crazy about Needletails somewhat similar approach either).
> I implemented the same algorithm in < 100 lines of Julia and were >60% faster than the provided needletail benchmark, beating Mojo. I'm confident it could be done in Rust, too.
> The TL;DR is that the Mojo implementation is fast because it essentially memchrs four times per read to find a newline, without any kind of validation or further checking. The memchr is manually implemented by loading a SIMD vector, and comparing it to 0x0a, and continuing if the result is all zeros. This is not a serious FASTQ parser. It cuts so many corners that it doesn't really make it comparable to other parsers (although I'm not crazy about Needletails somewhat similar approach either).
> I implemented the same algorithm in < 100 lines of Julia and were >60% faster than the provided needletail benchmark, beating Mojo. I'm confident it could be done in Rust, too.
The article sheds light on Mojo's potential, but with every such article, I'm cautious not to get overly hyped. Many key factors will come into play; long-term support and community growth will be crucial for its adoption. Additionally, I'm curious about the learning curve for Python developers looking to switch or integrate Mojo into their workflows.
Still looking forward to all new information about Mojo's development and its source code getting published someday soon
Since Chris is lurking: will Mojo on GPUs be more like using Jax (relying on compiler), Triton (more control, but abstracted), or more like CUDA (close to maximal control)? Combination? Nvidia and AMD support out of box?
Modular is enabling all of the above for different audiences. MAX provides an operator-graph level abstraction like PyTorch or JAX have, and we expect a bunch of high level libraries like nn.module to get built out over time by the community. You can also go directly to the GPU with a classical CUDA-like programming model for maximal control.
In between we have something we're cooking that I think will be pretty interesting for GPU kernel authors, but it isn't public yet. :-)
The nice thing about this is that it is one system that scales, instead of a bunch of different/inconsistent tech built by different teams over many years, held together with duct tape. Simple and consistent makes it much easier to do the kinds of research and experimentation that power AI ecosystem.
In between we have something we're cooking that I think will be pretty interesting for GPU kernel authors, but it isn't public yet. :-)
The nice thing about this is that it is one system that scales, instead of a bunch of different/inconsistent tech built by different teams over many years, held together with duct tape. Simple and consistent makes it much easier to do the kinds of research and experimentation that power AI ecosystem.
Thanks for the reply. Sounds exciting, looking forward to the future of Modular!
Surely the Mojo implementation doesn't miss something like maybe error handling?
It definitely does, see the reddit link in this thread.
Given that Mojo is a very Python-compatible language, this is incredible! Mojo gives most of the benefits of Python (immense ecosystem, short and clear code), with incredible speed.
Any theories why the compiler didn't manage to use SIMD without the manual SIMD code?
LLVM has an autovectorizer which is quite good, but such tech is limited because (eg) it can't change memory layout.
Speaking as someone who has spent more than 20 years writing compilers (e.g. LLVM, MLIR, etc), my opinion is that autovectorizers are a class of tech that are best applied to get speedups on legacy code bases. If you care about performance a lot, you shouldn't use them IMO - they are unpredictable and have performance cliffs.
-Chris
Speaking as someone who has spent more than 20 years writing compilers (e.g. LLVM, MLIR, etc), my opinion is that autovectorizers are a class of tech that are best applied to get speedups on legacy code bases. If you care about performance a lot, you shouldn't use them IMO - they are unpredictable and have performance cliffs.
-Chris
Is the Mojo compiler restricted from changing the memory layout for some semantic reason or is it just llvm missing functionality? I know for other languages the semantics tends to be a major hinderance. IIRC your PhD thesis was about this stuff!
Regardless, the code in this post seems to use the same input in both versions and the change looks loop local at first blush, but maybe I'm missing something.
Regardless, the code in this post seems to use the same input in both versions and the change looks loop local at first blush, but maybe I'm missing something.
Has anyone here integrated MOJO into a real industry workflow.
I am looking for a language not called C++ that I can write some bottlenecked modules in and wrap it around in python.
I want the code base to feel like python with a few files offloaded to this language.
Any suggestions ?
I am looking for a language not called C++ that I can write some bottlenecked modules in and wrap it around in python.
I want the code base to feel like python with a few files offloaded to this language.
Any suggestions ?
Nim?
Rust?
Rust is the most common one that comes up. Im going to spare some time to learn it this year.
The website (perhaps innocently) animates the cookie popup on ios such that attempting to reject presses on accept. Please fix.
I want to see some comparisons with other python libraries like numpy, jax, and numba.