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.
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.
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:
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
> > 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.
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.
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.
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.
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.
> 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.
28 comments
[ 4.3 ms ] story [ 73.5 ms ] threadDisclaimer: MojoFastTrim is for demonstration purposes only and shouldn't be used as part of bioinformatic pipelines
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
> 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.
https://github.com/biojava/biojava/tree/master/biojava-genom...
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
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.
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.
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 ?
> 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.