4 ms·
> 4x slower coreutils I doubt this is true in practice. The majority of coreutils spend the majority of their time waiting for the results of IO/syscalls. (The
by wavemode 10mo ago
> 4x slower coreutils
I doubt this is true in practice. The majority of coreutils spend the majority of their time waiting for the results of IO/syscalls. (The exception would probably be, the hashing utilities like md5sum.)
- stefan_ 10mo agoI tried md5sum and sha256sum and there was exactly zero difference in runtime (the Fil-C version of sha256sum was consistently faster, in fact..)
- josephg 10mo agoWhy 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 10mo 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 10mo 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_ 10mo 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.