Me too! I've been using it for bioinformatics related work, and it is absolutely fantastic. I can't wait for it to hit fully open source status so it can be easily recommended.
"requires" is a strong word, but I implemented an alignment kernel that can do alignments on the GPU.
Overall I think there is going to be a lot of "old" gpu compute hanging around, and now that writing kernels is a lot easier than it has been, we might as well try and see what algorithms we can get working there.
I originally picked up Mojo for the SIMD, not for the GPU kernels. The SIMD usability in Mojo is outstanding.
I have been pretty hopeful about Mojo as I find many of the modern compiled languages these days requires an surprisingly excessive amount of ceremony just to open a file and read it line by line. At least this is the case with Go, as I've written about [1].
If Mojo is providing any kind of python like experience in this matter, I will be all into it again (it lacked these features when I last tried).
I'm really quite divided about Rust vs Mojo for bioinformatics in the future.
The syntax i Mojo really seems to shine a lot ... though I still wonder if the train has already left now that so much bioinfo work is already done in Rust.
What's "alignment" in your context. In bioimaging it usually refers to aligning something to a reference atlas (like the Allen Reference Mouse Brain Atlas) or aligning two microscope channels (like the red channel and green channel)
Having written a lot of Mojo over the last two year, just for fun, it's a really cool language. Ownership model adjacent to Rust, comptime that is more powerful than Zig, Rich type system, first class SIMD support, etc.
Performance wise it's the first language in long time that isn't just an LLVM wrapper. LLVM is still involved, but they are using it differently than say, Rust or Zig.
Very excited for Mojo once it's open sourced later this year.
Not OP, but see the entire section on metaprogramming: https://mojolang.org/nightly/docs/manual/metaprogramming/. Mojo's compile-time programming is influenced by Zig, but has features that are not in Zig e.g traits, generics (real generics), and constraints, that work together.
That's fair, I think I should have just said "comparable to Zig". The type'd ness is what I was thinking of, but having actually written some zig in the last few days to play with their Io model / see what passing around an allocator is like, Zig is pretty fantastic.
I still prefer the structure in Mojo, but boy do I miss if/switch as expressions.
Removing the wrapping newline from the FASTA/FASTQ convention also dramatically improves parsing perf when you don't have to do as much lookahead to find record ends.
Unfortunately, when you write a program that doesn't wrap output FASTAs, you have a bunch of people telling you off because SOME programs (cough bioperl cough) have hard limits on line length :)
I've only tested this when writing my own parser where I could skip the record end checks, so idk if this improves perf on a existing parser. Excited to see what you find!
> a testament to the massive gap in perceived vs actual programming ability of the average bioinformatician.
This is not really a fair statement. Literally all of software bears the weight of some early poor choice that then keeps moving forward via weight of momentum. FASTA and FASTQ formats are exceptionally dumb though.
I have used Mojo quite a bit. It’s fantastic and lives up to every claim it makes. When the compiler becomes open source I fully expect it to really start taking off for data science.
Modular also has its paid platform for serving models called Max. I’ve not used that but heard good things.
Not OP but I think this could be an instance of leaky abstraction at work. Most of the time you hand-write an accelerator kernel hoping to optimize for runtime performance. If the abstraction/compiler does not fully insulate you from micro-architectural details affecting performance in non-trivial ways (e.g. memory bank conflict as mentioned in the article) then you end up still having per-vendor implementations, or compile-time if-else blocks all over the place. This is less than ideal, but still arguably better than working with separate vendor APIs, or worse, completely separate toolchains.
Because I was originally writing some very CPU intensive SIMD stuff, which Mojo is also fantastic for. Once I got that working and running nicely I decided to try getting the same algo running on GPU since, at the time, they had just open sourced the GPU parts of the stdlib. It was really easy to get going with.
I have not used Triton/Cute/Cutlass though, so I can't compare against anything other than Cuda really.
The blog post is about using an NVIDIA-specific tensor core API that they have built to get good performance.
Modular has been pushing the notion that they are building technology that allows writing HW-vendor neutral solutions so that users can break free of NVIDIA's hold on high performance kernels.
From their own writing:
> We want a unified, programmable system (one small binary!) that can scale across architectures from multiple vendors—while providing industry-leading performance on the most widely used GPUs (and CPUs).
They allow you to write a kernel for Nvidia, or AMD, that can take full advantage of the Hardware of either one, then throw a compile time if-statement in there to switch which kernel to use based on the hardware available.
So, you can support either vendor with as-good-vendor-library performance. That’s not lock-in to me at least.
It’s not as good as the compiler being able to just magically produce optimized kernels for arbitrary hardware though, fully agree there. But it’s a big step forward from Cuda/HIP.
I can't speak to Gleam, but for Elixir I just used Burrito to create a single executable: https://github.com/burrito-elixir/burrito I think it works for just Erlang too.
I haven't used it, but from the docs, I don't see why this wouldn't work for any language that compiles to beam files. You might need to adjust the build setup a bit.
Personally, I think I'd prefer something that worked without unpacking, but I don't actually need something like this, so my preferences aren't super important :D
reply