Re:Rust is now overall faster than C in benchmarks
by TheNewAndy on Sunday January 03, 2021 @04:55PM
(#25625610)
The poster you are replying to didn't suggest hardcoding intcmp into qsort - just making it so the implmentation of qsort is available to the compiler when the comparison function is known (i.e. just like with C++).
When this is done, the compiler can inline qsort, and replace the indirect function call with an inlined version of intcmp, and then things are equivalent.
Re:Rust is now overall faster than C in benchmarks
by bluGill on Sunday January 03, 2021 @10:06PM
(#25627552)
Only if inlining qsort is best. Sometimes it is sometimes it isn't, based on complex rules that I trust the compiler to know.
Re:Rust is now overall faster than C in benchmarks
by marvy on Sunday January 03, 2021 @04:43PM
(#25625538)
I think mh7 did not mean to hard-code intcmp into qsort. The idea is to move the definition of qsort directly into the stdlib.h header file. That way, the compiler can see the definition of qsort and intcmp at the same time.
In that case, the compiler could make a specialized qsort using intcmp automatically.
You could do some macro magic instead of templates e.g. `DEFINE_QSORT(int, intcmp)` which could stamp out `qsort_int` but that's not a part of the stdlib.
C++ arguably gets this right since sort<int> and sort<string> will be separate functions, although templates are of course a footgun. And of course duping the logic for std::sort<T> for a bunch of different T impls increases the binary size.