Multithreading

[RagnarGrootKoerkamp]

I'm just trying a quick benchmark to get an idea of the speed of ish vs sassy.

Running against a 3Gbp human genome, I can't get the average CPU usage to go above 300%, even though I have 6 physical cores. (Larger or smaller batch sizes also don't work.) Interestingly the number of active threads seems to go up and down between 1 and 4.

Maybe this is something that can be improved?

---

Anyway, I'm getting around 60s wall-time or 200s CPU time to search a 23bp long pattern across a human genome. Does that sound reasonable?

Sassy does the same (with up to 4 errors) in 2s wall time or 8s CPU time, so I guess the bitpacking and edit-distance-only really make quite a big difference.

[sstadick]

Hi @RagnarGrootKoerkamp!

First - regarding the 300% issue, I believe that is a standing bug with the parallelize implementation in mojo / their async runtime that backs the parallelize method.

I call this opaque fn num_physical_cores, to get the number of cores and pass that that to parallelize, but I think that the async runtime still caps itself internally at just 1/2 the number of available cores.

I have admittedly not raised the issue with Modular past adding to this thread modular/modular#2398. The whole parallelize construct and asyncrt should be getting torn out in favor of a full concurrency model here in the near future.

---

Second - yes, that does sound reasonable. ish will do better at long queries (if installed from source and not conda!) and/or when a GPU is available (AMD or Nvidia, latest generations). It's just a slightly improved striped-simd semi-global alignment algo at its core. If you specify --match-algo striped-local it should look a bit better for ish on short seqs, but it won't stand up to bitpacking+edit-distance-only.

[RagnarGrootKoerkamp]

Uhhh, interesting. So what you're saying is that mojo 'knows' that hyperthreading is bad, and caps to half the available threads? That's reasonable, but not great when I disabled hyperthreading in bios already so that I have 6 cores and 6 threads 😅 (and also, modern hardware more and more often just doesn't have hyperthreading I think?)

---

I did install from source, assuming that pixi run build does that and not some download ;)

Ah, maybe I try again with GPU just for fun. In sassy we don't do local alignment, so it doesn't really make too much sense to compare with that.

[sstadick]

Basically yes, and since their (Modular's) primary user is still themselves, and the use-case is serving models on cloud instances, I can see why it is the way it is, but it's super annoying for general use for now.

---

Yep! pixi run build should auto detect the widest simd feature width available and use that. There's more work to be done to send different length queries to the optimal-width striped simd impls.

RE GPUs after thinking about it after walking away - I don't think it will help (and might just hurt) for vs the whole genome. GPU will help when there are many reference seqs to align to at once. For stuff like a protein database, that's great, but assuming you have some sane version of "3Gbp human genome", that's probably not going to be parallel enough to be faster than the CPU SIMD version.

But if you try it LMK how it goes! I'd love some more datapoints, even if they are slow/sad!