111–120 of 124 posts
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.
Earlier quoted context omitted.
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.
Is there any compiled language that doesn't benefit heavily from release builds? That would be interesting if true.
Apple's Rosetta 2 translates x86-64 to aarch64 that runs surprisingly fast, despite being mostly a straightforward translation of instructions, rather than something clever like a recompiling optimizing JIT.
And the plain old C is relatively fast without optimizations, because it doesn't rely on abstraction layers being optimized out.
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_t…
Earlier quoted context omitted.
Too bad Julia doesn't have this theoretical "well written GC". I do not like GCs, so I agree with OP's sentiment. Why solve such a hard problem when you don't have to? I don't find ownership models that difficult. It's things one should be thinking of anyway. I think this provides a good example of where stricter checking/an ownership model like Rust has makes it easier than languages that do not have it (in this cas…
On the other hand, trying to represent graph structures in Rust (e.g. phylogenetic trees, pedigrees, assembly graphs) is absolutely horrible. The ownership models breaks completely apart, and while it can be worked around, it's just a terrible developer experience where I just wished I had a GC in those cases. Practically speaking I rarely find GC pauses to be an issue, neither latency wise nor speed wise. Though of…
Earlier quoted context omitted.
I can't take this language or company serious after reading stuff like: "Mojo may be the biggest programming language advance in decades" https://www.fast.ai/posts/2023-05-03-mojo-launch.html
Hard to remember the last language that felt so obviously sold by something other than an actual community. Even Swift tried its best to exist outside of xcode and mac/i os EDIT: perhaps I'm being too harsh—this was literally just announced. I'm just taken aback by the blatant marketing as everyone else is.
Open source Swift is as relevant as Objective-C was, never expect any big uptake if none of the key frameworks is open source.
Outside Apple platforms it only fulfills two goals, being good enough for Apple and iOS developers to deploy their server code on GNU/Linux, a bit of goodwill marketing, and that is about it.
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…
No Rust or Julia in their radar.
Earlier quoted context omitted.
> I really wish Julia had easy AOT compilation and no GC, that would be perfect I pretty strongly disagree with the no gc part of this. A well written GC has the same throughout (or higher) than reference counting for most applications, and the Rust approach is very cool, but a significant usability cliff for users that are domain first, CS second. A GC is a pretty good compromise for 99% of users since it is a minor…
Too bad Julia doesn't have this theoretical "well written GC". I do not like GCs, so I agree with OP's sentiment. Why solve such a hard problem when you don't have to? I don't find ownership models that difficult. It's things one should be thinking of anyway. I think this provides a good example of where stricter checking/an ownership model like Rust has makes it easier than languages that do not have it (in this cas…
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_t…
Hey, the Mojo parser author here. the test folder is just for the unit tests. All the benchmarking code is located in the /benchmark folder. It would be great if you can give it another go on your machine. https://github.com/MoSafi2/MojoFastTrim/tree/restructed/benc...
When running on the commit & code you point to here, here are my new results:
$ hyperfine -N --warmup 5 './benchmark/fast_parser data/fastq_test.fastq' './benchmark/needletail_benchmark/target/release/rust_parser data/fastq_test.fastq '
Benchmark 1: ./benchmark/fast_parser data/fastq_test.fastq
Time (mean ± σ): 675.0 ms ± 2.4 ms [User: 399.3 ms, System: 269.4 ms]
Range (min … max): 670.5 ms … 677.5 ms 10 runs
Benchmark 2: ./benchmark/needletail_benchmark/target/release/rust_parser data/fastq_test.fastq
Time (mean ± σ): 840.8 ms ± 3.0 ms [User: 578.0 ms, System: 257.0 ms]
Range (min … max): 837.0 ms … 847.7 ms 10 runs
Summary
./benchmark/fast_parser data/fastq_test.fastq ran
1.25 ± 0.01 times faster than ./benchmark/needletail_benchmark/target/release/rust_parser data/fastq_test.fastq
Earlier quoted context omitted.
Hey, the Mojo parser author here. the test folder is just for the unit tests. All the benchmarking code is located in the /benchmark folder. It would be great if you can give it another go on your machine. https://github.com/MoSafi2/MojoFastTrim/tree/restructed/benc...
Thanks for the pointer, I had only checked the 'main' branch, which doesn't have the benchmarking code present. When running on the commit & code you point to here, here are my new results: $ hyperfine -N --warmup 5 './benchmark/fast_parser data/fastq_test.fastq' './benchmark/needletail_benchmark/target/release/rust_parser data/fastq_test.fastq ' Benchmark 1: ./benchmark/fast_parser data/fastq_test.fastq Time (mean ±…
Earlier quoted context omitted.
Hard to remember the last language that felt so obviously sold by something other than an actual community. Even Swift tried its best to exist outside of xcode and mac/i os EDIT: perhaps I'm being too harsh—this was literally just announced. I'm just taken aback by the blatant marketing as everyone else is.
Swift isn't trying anything, Apple only cares about their platforms. Open source Swift is as relevant as Objective-C was, never expect any big uptake if none of the key frameworks is open source. Outside Apple platforms it only fulfills two goals, being good enough for Apple and iOS developers to deploy their server code on GNU/Linux, a bit of goodwill marketing, and that is about it.