3 ms·
"can be", if taken as modestly as needed for it to be correct here, is pretty much a completely useless statement. Of course [insert modern sort] is [a ton] fas
by dzaima 3y ago
"can be", if taken as modestly as needed for it to be correct here, is pretty much a completely useless statement. Of course [insert modern sort] is [a ton] faster than [some other unspecified old sort that might not even be targeting perf for sorting plain integers]. So I'd assume most would think that's clearly the wrong interpretation, and read it as a stronger assertion, i.e. any currently known scalar sort is ~10x slower than vqsort/avx512sort, for at least some (this "some" being the justification for "can be" over "will be") input. (and naively this makes sense - 512-bit SIMD processes 16 32-bit elements in a single instruction, so a 10x improvement doesn't sound unreasonable)
- janwas 3y agoI do not understand how one would jump from the readme's "As of 2022-06-07 this sorts large arrays of built-in types about ten times as fast as `std::sort`" (and this is now being clarified to add LLVM's std::sort) to 'any scalar sort is 10x slower'.
- dzaima 3y agoThat's about the number in the post here. The readme is better at this, as it does actually mention std::sort, whereas here it's just "Intel's sort and ours can be about 10x as fast as scalar.". (not that I expect everyone to provide 100% of the necessary details on everything on every post anywhere on the internet, but here it's been explicitly pointed out to you that it's quite misleading)