pjmlp
3 days ago
I was expecting that the C++ code would have been updated to C++23 best practices, and what are all those std::list doing in modern CPU cache lines?
npalli
3 days ago
Not only is it not C++23, the C++ code is from the 2011 paper!, so pre-C++11. Rust maybe better than code written before C++11 is not a strong take.
pjmlp
3 days ago
Yes it has a pretty much C++98/C++ARM feeling to the code style.
quietbritishjim
3 days ago
In fairness, updating to a range-based for loop would give the same effective code as using iterators manually in the loop as they have done. I'm not convinced any new features in C++23 (after C++11) would have given a performance improvement - was there something you had in mind?
The choice of std::list is a bit more dubious. Looking at the code (I found a mirror [1]), it seems like it's mostly for appending and iterating but there is pop_front in one place. Maybe std::deque would be better? Or std::vector with an iterator noting the effective start? Or maybe they were deliberately choosing a poor data structure to stress the compiler (and if so the OP should've used a linked list in Rust for fairness). The article doesn't comment so we can only guess their motivation.
[1] https://github.com/hundt98847/multi-language-bench/blob/mast...
pjmlp
3 days ago
> was there something you had in mind?
More like on how to write the code in more ergonomic way than the performance by itself, maybe some of that stuff could even be constepxr/eval.
npalli
3 days ago
std::list to std::vector should be the big one.
std::map to std::unordered_map could be next.
then, really ranges/constexpr/std::move could make a difference, hard to say definitely.
Beyond these, Modern C++ would have most definitely led to much shorter code as that was a metric for comparison.
quietbritishjim
3 days ago
> std::list to std::vector should be the big one
That is not a "C++23 best practice", which is what I was replying to. It doesn't even need C++11! And one use of this type uses pop_front() so std::vector is not obviously a good choice here.
> std::map to std::unordered_map could be next.
Again, I called out C++11 as possibly making a difference - sure this could help but it doesn't need C++23.
> then, really ranges/constexpr/std::move could make a difference, hard to say definitely.
How? Ranges are a nice syntax but what would they speed up here? There doesn't seem to be anything evaluated at compile time so what's the benefit of constexpr? (Even std::move doesn't have an obvious use in the benchmark code but that's C++11 anyway.)
> Beyond these, Modern C++ would have most definitely led to much shorter code as that was a metric for comparison.
I agree that would be interesting, but I'd be surprised if the code was much shorter. I'd guess something like 10%.