4 ms·

As we discussed on the Nim forum¹, the Nim programs could definitely be improved a lot. elcritch did some optimization and managed to make Nim's time roughly eq

by xigoi 5y ago

As we discussed on the Nim forum¹, the Nim programs could definitely be improved a lot. elcritch did some optimization and managed to make Nim's time roughly equal to Rust. ¹ https://forum.nim-lang.org/t/8868 https://forum.nim-lang.org/t/8868

duckerude 5y ago
That speedup is accomplished by using a third-party LRU implementation. I can also speed up the Rust version by 30% by plugging in https://lib.rs/crates/lru https://lib.rs/crates/lru. (The thread points out that the Nim version uses a doubly-linked list from the standard library while you'd need unsafe in Rust, and the lru crate does indeed use unsafe. So take that into account.)
- elcritch 5y ago
  Note that using the third party LRU makes the Nim version faster than the Rust one by 15%. Fixing the Deque/Table Nim version results in the same times as the Rust Dec/HashMap one.
- staticassertion 5y ago
  Doesn't that just kinda lend further support to the benchmarks being a bit silly?
  - igouy 5y ago
    Please show the previous support for which that may be "further support". Meanwhile: it may suggest the comparison is a work in progress, not finished or definitive. Can data be "silly" or is it what people say about the data that is "silly"?
- josephg 5y ago
  > you'd need unsafe in Rust Unsafe is part of the rust language. Theres nothing wrong with using it if you know what you’re doing. The value of unsafe is that it boxes your unsafe code - so you can direct extra care to those functions when writing, reviewing and auditing. (As opposed to C where memory corruption could happen anywhere, so you need to be careful everywhere.) I could imagine a separate language on the programming languages shootout which is “safe rust”. It’d be interesting how the best unsafe and the best safe programs compare in speed and size.
  - A-Train 5y ago
    If you believe Rust zero cost abstraction - being safe doesn't mean it has to be compared to safe languages because Rust and C can translate into same assembler code. But in Rust the compiler gives you more guarantees. I would say that a proper way to rephrase it would be to use idiomatic code vs unidiomatic. If you start using any high-level language in a non intended fashion (writing non idiomatic code) probably most of them would be faster.
staticassertion 5y ago
I think people may not know or may not remember that ~6 years ago or so there was a fairly significant effort to increase rust's position in the benchmarks. I remember it coming up a lot on /r/rust when the language had stabilized. "C or C++ is first place? Isn't Rust supposed to be fast?" etc. I assume nim has gotten a lot less attention in these benchmarks and there's probably huge wins available to it.
- igouy 5y ago
  > … position in the benchmarks. In the benchmarks game — https://benchmarksgame-team.pages.debian.net/benchmarksgame/index.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... This is not the benchmarks game, although "some of the benchmark problems and implementation are borrowed from it".
  - staticassertion 5y ago
    Ah, I recognized some of the names from the benchmarks game so I sort of just assumed it was a reposting of them.

by xigoi 5y ago

duckerude 5y ago

That speedup is accomplished by using a third-party LRU implementation. I can also speed up the Rust version by 30% by plugging in https://lib.rs/crates/lru https://lib.rs/crates/lru. (The thread points out that the Nim version uses a doubly-linked list from the standard library while you'd need unsafe in Rust, and the lru crate does indeed use unsafe. So take that into account.)

elcritch 5y ago
Note that using the third party LRU makes the Nim version faster than the Rust one by 15%. Fixing the Deque/Table Nim version results in the same times as the Rust Dec/HashMap one.
staticassertion 5y ago
Doesn't that just kinda lend further support to the benchmarks being a bit silly?
- igouy 5y ago
  Please show the previous support for which that may be "further support". Meanwhile: it may suggest the comparison is a work in progress, not finished or definitive. Can data be "silly" or is it what people say about the data that is "silly"?
josephg 5y ago
> you'd need unsafe in Rust Unsafe is part of the rust language. Theres nothing wrong with using it if you know what you’re doing. The value of unsafe is that it boxes your unsafe code - so you can direct extra care to those functions when writing, reviewing and auditing. (As opposed to C where memory corruption could happen anywhere, so you need to be careful everywhere.) I could imagine a separate language on the programming languages shootout which is “safe rust”. It’d be interesting how the best unsafe and the best safe programs compare in speed and size.
- A-Train 5y ago
  If you believe Rust zero cost abstraction - being safe doesn't mean it has to be compared to safe languages because Rust and C can translate into same assembler code. But in Rust the compiler gives you more guarantees. I would say that a proper way to rephrase it would be to use idiomatic code vs unidiomatic. If you start using any high-level language in a non intended fashion (writing non idiomatic code) probably most of them would be faster.

staticassertion 5y ago

I think people may not know or may not remember that ~6 years ago or so there was a fairly significant effort to increase rust's position in the benchmarks. I remember it coming up a lot on /r/rust when the language had stabilized. "C or C++ is first place? Isn't Rust supposed to be fast?" etc. I assume nim has gotten a lot less attention in these benchmarks and there's probably huge wins available to it.

igouy 5y ago
> … position in the benchmarks. In the benchmarks game — https://benchmarksgame-team.pages.debian.net/benchmarksgame/index.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... This is not the benchmarks game, although "some of the benchmark problems and implementation are borrowed from it".
- staticassertion 5y ago
  Ah, I recognized some of the names from the benchmarks game so I sort of just assumed it was a reposting of them.