Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A look at the Mojo language for bioinformatics

viralinstruction.com

Post reply on HN
Print view View original

21–30 of 124 posts

Re: A look at the Mojo language for bioinformatics

#21

Post by alpaca128 »

tehsauce wrote: post #11
mcqueenjordan wrote: post #9

Another point of clarification that is of great importance to the results, and is a common Rust newcomer error: The benchmarks for the Rust implementation (in the original post that got all the traction) were run with a /debug/ build of rust, i.e. not an optimized binary compiled with --release. So it was comparing something that a) didn't do meaningful parsing against b) the full parsing rust implementation in a non…

How much does this particular result change when running in release mode?

Depending on the code I've seen performance increases above 100x in some cases. While that's not exactly the norm, benchmarking Rust in debug mode is absolutely pointless even as a rough estimate.

Re: A look at the Mojo language for bioinformatics

#22

Post by pjmlp »

coldtea wrote: post #17
pjmlp wrote: post #15

Earlier quoted context omitted.

I used to be quite sceptical given how Swift for Tensorflow went, however since NVidia decided to partner with Modular, alongside their ongoing CUDA JIT bindings for Python, I think Mojo might actually work out.

"Swift for Tensorflow" never had any real backing apart from the announcement though.

Apparently it had Google's money backing, for what it is worth.

I never believed into it, because Swift is as relevant as Objective-C outside NeXT/Apple's platforms, and not the kind of programming language that the research community cares about.

Re: A look at the Mojo language for bioinformatics

#23

Post by refulgentis »

jakobnissen wrote: post #18
refulgentis wrote: post #10

I felt like I learned more about the author than Mojo. - Never actually runs it. Seriously. - Wants us to know it's definitely not a real parser as compared to Needlepoint...then 1000 words later, "real parser" means "handles \r\n...and validates 1st & 3rd lines begin with @ and +...seq and qual lines have the same length". - At the end, "Julia is faster!!!!" off a one-off run on their own machine, comparing it to be…

I feel like if you believe my conclusion was that "Julia is faster" then you are missing the point. The point is that the original blogs claims of "Mojo is faster" isn't right - it's comparing different programs. That implementation in Mojo is faster than Needletail - but that doesn't say very much and I prove it by also beating Needletail in Julia by using the same algorithm as Mojo does. So it's the algorithm. Not…

Yeah, I got the joke, and understood the parser.

It's just, the content length : content ratio is high - all I got out of it was you don't like the Mojo speed claim & genomics parsing is text parsing*

Don't take that the wrong way, I feel bad. It's just bad for me - I'm a mobile developer, so I was way out of my domain, I've barely written Python, Julia is a complete abstraction to me outside of HN. An alternative way to think about it is, I shouldn't have expected an in-depth analysis of Mojo.

* i mean, everything is bytes parsing, but it always tickles me when I find out other domains aren't castles in the sky, speaking an alien language

Re: A look at the Mojo language for bioinformatics

#24

Post by frou_dh »

akkad33 wrote: post #8
jimbob45 wrote: post #2

Crystal was never able to find traction as a Ruby clone that could compete with C speeds. Why would a Python clone have any better luck? I don’t think anyone would accuse Python of being dramatically more usable than Ruby.

Crystal is an entirely different language with a similar syntax. Valid Python is valid Mojo

Apparently that is the goal, but not the reality:

> Mojo is still early and not yet a Python superset, so only simple programs can be brought over as-is with no code changes. We will continue investing in this and build migration tools as the language matures.

https://docs.modular.com/mojo/faq.html#how-do-i-convert-pyth...

Re: A look at the Mojo language for bioinformatics

#25

Post by jakobnissen »

refulgentis wrote: post #23
jakobnissen wrote: post #18

Earlier quoted context omitted.

I feel like if you believe my conclusion was that "Julia is faster" then you are missing the point. The point is that the original blogs claims of "Mojo is faster" isn't right - it's comparing different programs. That implementation in Mojo is faster than Needletail - but that doesn't say very much and I prove it by also beating Needletail in Julia by using the same algorithm as Mojo does. So it's the algorithm. Not…

Yeah, I got the joke, and understood the parser. It's just, the content length : content ratio is high - all I got out of it was you don't like the Mojo speed claim & genomics parsing is text parsing* Don't take that the wrong way, I feel bad. It's just bad for me - I'm a mobile developer, so I was way out of my domain, I've barely written Python, Julia is a complete abstraction to me outside of HN. An alternative wa…

I yeah I get that. If you were expecting a review of Mojo, then the post falls short. Maybe the title should have emphasized the benchmark as being in question, not Mojo itself.

Re: A look at the Mojo language for bioinformatics

#26

Post by fwip »

For what it's worth, I couldn't reproduce the benchmarks cited in the post, which claimed a 50% speedup over Rust on M1. The rust implementation was consistently about two to three times as fast as Mojo with the provided test scripts and datasets. It's possible I was compiling the Mojo program suboptimally, though.

  hyperfine -N --warmup 5 test/test_fastq_record 
  'needletail_test/target/release/rust_parser data/fastq_test.fastq'
  Benchmark 1: test/test_fastq_record
    Time (mean ± σ):      1.936 s ±  0.086 s    [User: 0.171 s, System: 1.386 s]
    Range (min … max):    1.836 s …  2.139 s    10 runs
  
  Benchmark 2: needletail_test/target/release/rust_parser data/fastq_test.fastq
    Time (mean ± σ):     838.8 ms ±   4.4 ms    [User: 578.2 ms, System: 254.3 ms]
    Range (min … max):   833.7 ms … 848.2 ms    10 runs
  
  Summary
    needletail_test/target/release/rust_parser data/fastq_test.fastq ran
      2.31 ± 0.10 times faster than test/test_fastq_record
(Edit: I built the Rust version with `cargo build --release` on Rust 1.74, and Mojo with `mojo build` on Mojo 0.7.0.)

Re: A look at the Mojo language for bioinformatics

#27

Post by disgruntledphd2 »

jakobnissen wrote: post #25
refulgentis wrote: post #23

Earlier quoted context omitted.

Yeah, I got the joke, and understood the parser. It's just, the content length : content ratio is high - all I got out of it was you don't like the Mojo speed claim & genomics parsing is text parsing* Don't take that the wrong way, I feel bad. It's just bad for me - I'm a mobile developer, so I was way out of my domain, I've barely written Python, Julia is a complete abstraction to me outside of HN. An alternative wa…

I yeah I get that. If you were expecting a review of Mojo, then the post falls short. Maybe the title should have emphasized the benchmark as being in question, not Mojo itself.

I'm a data scientist, not a bioinformatician and I really enjoyed the post. I too am sceptical of Mojo though, so maybe it just played to my biases...

Re: A look at the Mojo language for bioinformatics

#28

Post by fwip »

tehsauce wrote: post #11
mcqueenjordan wrote: post #9

Another point of clarification that is of great importance to the results, and is a common Rust newcomer error: The benchmarks for the Rust implementation (in the original post that got all the traction) were run with a /debug/ build of rust, i.e. not an optimized binary compiled with --release. So it was comparing something that a) didn't do meaningful parsing against b) the full parsing rust implementation in a non…

How much does this particular result change when running in release mode?

On my machine, running the debug executable on the medium-size dataset takes ~14.5 seconds, and release mode takes ~0.8 seconds.

Re: A look at the Mojo language for bioinformatics

#29

Post by WeatherBrier »

The language is far from stable, but I have had a LOT of fun writing Mojo code. I was surprised by that! The only promising new languages for low-level numerical coding that can dislodge C/C++/Fortran somewhat, in my opinion, have been Julia/Rust. I feel like I can update that last list to be Julia/Rust/Mojo now.

But, for my work, C++/Fortran reign supreme. I really wish Julia had easy AOT compilation and no GC, that would be perfect, but beggars can't be choosers. I am just glad that there are alternatives to C++/Fortran now.

Rust has been great, but I have noticed something: there isn't much of a community of numerical/scientific/ML library writers in Rust. That's not a big problem, BUT, the new libraries being written by the communities in Julia/C++ have made me question the free time I have spent, writing Rust code for my domain. When it comes time to get serious about heterogeneous compute, you have to drop Rust and go back to C++/CUDA, when you try to replicate some of the C++/CUDA infrastructure for your own needs in Rust: you really feel alone! I don't like that feeling ... of constantly being "one of the few" interested in scientific/numerical code in Rust community discussions ...

Mojo seems to be betting heavy on a world where deep heterogeneous compute abilities are table stakes, it seems the language is really a frontend for MLIR, that is very exciting to me, as someone who works at the intersection of systems programming and numerical programming.

I don't feel like Mojo will cause any issues for Julia, I think that Mojo provides an alternative that complements Julia. After toiling away for years with C/C++/Fortran, I feel great about a future where I have the option of using Julia, Mojo, or Rust for my projects.

Re: A look at the Mojo language for bioinformatics

#30

Post by jdiaz97 »

Great post. I think Mojo's claims like the speedup over Rust are a problem, like the 65000x speedup over Python. How can we differentiate between good new tech and Silicon Valley shenanigans when they use claims like that? They do nice titles and slogans but are shady in substance
Post reply on HN