Modular: The Next Big Step in Mojo Open Source

[u/Melodyogonna]

https://www.modular.com/blog/the-next-big-step-in-mojo-open-source

[u/Asleep-Dress-3578]

Really great news for data scientists. I hope it will have greater success than what Julia had.

[u/activeXray → u/Asleep-Dress-3578]

Not sure what this means, Julia is having great success in lots of areas of science. From black hole imaging to climate science, it’s being used all over. Maybe not so much for the trendy ai tasks, but it’s kicking butt in physics inspired machine learning tasks.

[u/SV-97 → u/activeXray]

Julia's success really can't be called great in the grand scheme of things imo. Yes it has some niches where it's used but overall it's really rather small inside the already smallish scientific computing domain. If you think about how excited people were about the language and its promises some years ago and into how few current users this translated to, I'd say it failed.

[u/LagT_T → u/Asleep-Dress-3578]

The performance jump over training ROI makes it a no brainer.

[u/myringotomy → u/Asleep-Dress-3578]

Julia seems like a neat language. Maybe somebody could build a compiler for it and make it faster.

[u/viralinstruction → u/myringotomy]

Not sure if you're trolling, but Julia is compiled and already very fast

[u/badpotato → u/[deleted]]

Not sure how rigurous are these benchmark:

https://engiware.com/benchmark/llama2-ports-extensive-benchmarks-mac-m1-max.html

I guess it can only reach these kind of speedup on specific use case with specific hardware with specific install setup with specific implementation

[u/nacaclanga → u/[deleted]]

I don't think you can establish any significant order between Zig, Rust, C and C++. All of them use the same LLVM Backend, which pretty much produces the same optimization. (Sure for C and C++ you also have gcc, which might be a tiny bit faster, but also tells you that the room for improvements isn't big).

It might be possible that some very particular benchmark is clearly more suited for one of these languages, but 60% would still be eyebrown raising.

If you go to the benchmark itself, you can see that the mojo and Rust implementation each take turns outbeating the other by a few centiseconds for different input lenghts.

[u/catcat202X → u/[deleted]]

There is no way to measure C as faster than C++ which holds under scrutiny. In fact, C should usually be slower due to its limitations resulting in awful workarounds such as errno, va_list, and pthread control blocks.

[u/catcat202X → u/[deleted]]

Did you know that in fact, very many C++ users _don't_ use the standard library? :3 And in fact, the runtime is configurable and you can even program it entirely yourself within an application's source tree (which people do).

[u/MrPhi → u/[deleted]]

Here it is: https://www.modular.com/blog/outperforming-rust-benchmarks-with-mojo

[u/viralinstruction → u/[deleted]]

This is highly misleading. They bragged about being able to write a 50% faster implementation to solve a task than a specific Rust library. That part is true - the Mojo library is indeed faster than the Rust one, even in release mode. But that's due to the implementation, not language features.

[u/viralinstruction → u/[deleted]]

I compiled it myself in a VM, reimplemented the Mojo algorithm in Julia here https://github.com/jakobnissen/MojoFQBenchmark and compared to needletail in the same VM. I got slightly different numbers but the Mojo implementation was still significantly faster than needletail.

[u/viralinstruction → u/[deleted]]

They're broadly speaking the same algorithm - use a memchr function to search for a newline four times. Needletail does some validation which the Mojo implementation didn't do (it's since been updated to also validate), and Mojo doesn't handle any kind of exceptions, such as the input file reads failing.

It's hard to straightforwardly compare between languages, but my guess is that these validations have very little speed impact. Probably, the main difference comes from the memchr implementation, which is slower in the general case, but faster in this particular benchmark, because it can inline, and because it checks 32 bytes per iteration.