3 ms·
Why would it be faster? That seems suspicious to me. Is all the code being compiled with the same flags? Shasum probably benefits a lot from intrinsics that ar
by josephg 11mo ago
Why would it be faster? That seems suspicious to me.
Is all the code being compiled with the same flags? Shasum probably benefits a lot from intrinsics that are only available on newer CPU targets.
- 0cf8612b2e1e 11mo agoThose are also highly algorithmic tools. Probably few code paths and a lot of vector operations where competing compilers may not have much room to differentiate.
- josephg 11mo agoIt really depends based on how shasum is implemented. If its implemented in assembly, it'll perform the same no matter how its compiled. But if its written using C code, the compiler has a lot of latitude to vectorize based on target CPU features. And not just SSE2 and AVX. Even popcnt isn't even available in the baseline x86_64 target for llvm. The Fil-C compiler is a fork of llvm. There's no way all that garbage collection code would make fil-c faster. So if its faster, its probably using different target flags. And in that case, its not a fair benchmark comparison.
- stefan_ 11mo agoI'm sure theres a difference in the binary, for a real comparison you would need to compile the same coreutils version with the same options. I just think the assertion that "compute-heavy" tools like sha256sum would be especially affected by Fil-C is not true, and if that was true given the "baseline slowdown" of 4x, surely it would show up in this sloppy test.