If you had said, "The perf difference isn't enough for me to care about," then I wouldn't have responded or said anything. That's totally fair and reasonable. Who am I to say what you should care about? If you want to spend more time waiting for shit to finish, that's your prerogative.
But what you said is (emphasis mine):
> For these tools, you won’t notice.
> None of these tools that they’re oxidizing is compute bound
just blatantly wrong and a >2x difference in perf is absolutely relevant and something I would notice personally. Maybe I'm the only one who likes sorting to be as fast as possible, but I'd guess not.
> You should try that benchmark with sort compiled with Fil-C.
Feel free to post a complete MRE for doing this and I'd be happy to run it.
I don't know what two sorts you're comparing, but I'm guessing neither one of them is compiled in Fil-C. Is it really the case that the Rust one is 2x faster? Or is it that the C one is 2x faster? 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.
The interesting question - going back to my original post - is what the Fil-C slow down would be. Just because a program takes 100% CPU doesn't mean it'll experience bad overheads when compiled with Fil-C.
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.
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).
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!
But what you said is (emphasis mine):
> For these tools, you won’t notice.
> None of these tools that they’re oxidizing is compute bound
just blatantly wrong and a >2x difference in perf is absolutely relevant and something I would notice personally. Maybe I'm the only one who likes sorting to be as fast as possible, but I'd guess not.
> You should try that benchmark with sort compiled with Fil-C.
Feel free to post a complete MRE for doing this and I'd be happy to run it.