> I don't know what two sorts you're comparing I showed you in my original comment. Both are C. One is the `sort` that comes with macOS, as shown at `/usr/bin/

> I don't know what two sorts you're comparing I showed you in my original comment. Both are C. One is the `sort` that comes with macOS, as shown at `/usr/bin/sort`, and the other is from GNU coreutils. > Also, it's just one benchmark of sort, so for all we know the two sort implementations really have the same perf if you test a broader set of cases. Sure, you're welcome to come up with a more comprehensive benchmark suite to support YOUR claim that tools like `sort` are not "compute bound" and you won't "notice" a difference in speed. I agree that 1 benchmark is insufficient to make generalized claims about performance. But it is very obviously better than 0 benchmarks (which is the number you have provided to support your claim). See also: https://en.wikipedia.org/wiki/Burden_of_proof_(philosophy) https://en.wikipedia.org/wiki/Burden_of_proof_(philosophy) In the interest of over-communicating, please note the qualification I gave originally: for files cached in RAM. > I don't know what you mean by "complete MRE". You can download the Fil-C binaries and point coreutils' configure script at the compiler and see what happens. It's not hard. Cool, then you should be able to show me a transcript of the precise commands necessary to do this very easily!