7 ms·
That doesn’t make sense unless you have only 1 or 2 physical CPUs with contention. In a modern CPU the latter should be faster and I’m left unsatisfied by the c
by anonymous-panda 2y ago
That doesn’t make sense unless you have only 1 or 2 physical CPUs with contention. In a modern CPU the latter should be faster and I’m left unsatisfied by the correctness of the explanation. Am I just being thick or is there a more plausible explanation?
- DougBTX 2y agoIt depends on where the timing code is. If the timer starts after all the data has already been loaded, the time recorded will be lower (even if the total time for the whole process is higher).
- anonymous-panda 2y agoI’m not following how that would result in a 10x discrepancy. The amount of data we’re talking about here is laughably small (it’s like 32 bytes or something)
- masklinn 2y ago> The amount of data we’re talking about here is laughably small So is the runtime.
- deleted 2y ago[deleted]
- DougBTX 2y agoI’ll admit to not having looked at the details at all, but a possible explanation is that almost all the time is spent on inter process communication overhead, so if that also happens before the timer starts (eg, the data has been transferred, just waiting to be read from a local buffer) then the measured time will be significantly lower.
- masklinn 2y agoThe latter is faster in actual CPU time, however note that TFA the measurement only starts with the program, it does not start with the start of the pipeline. Because the compilation time overlaps with the pipes filling up, blocking on the pipe is mostly excluded from the measurement in the former case (by the time the program starts there’s enough data in the pipe that the program can slurp a bunch of it, especially reading it byte by byte), but included in the latter.
- anonymous-panda 2y agoMy hunch is that if you added the buffered reader and kept the original xxd in the pipe you’d see similar timings. The amount of input data is just laughably small here to result in a huge timing discrepancy. I wonder if there’s an added element where the constant syscalls are reading on a contended mutex and that contention disappears if you delay the start of the program.
- vlovich123 2y agoGood hunch. On my machine (13900k) & zig 0.11, the latest version of the code: > INFILE="$(mktemp)" && echo $INFILE && \ echo '60016000526001601ff3' | xxd -r -p > "${INFILE}" && \ zig build run -Doptimize=ReleaseFast < "${INFILE}" > execution time: 27.742µs vs > echo '60016000526001601ff3' | xxd -r -p | zig build run -Doptimize=ReleaseFast > execution time: 27.999µs The idea that the overlap of execution here by itself plays a role is nonsensical. The overlap of execution + reading a byte at a time causing kernel mutex contention seems like a more plausible explanation although I would expect someone better knowledgeable (& more motivated) about capturing kernel perf measurements to confirm. If this is the explanation, I'm kind of surprised that there isn't a lock-free path for pipes in the kernel.
- rofrol 2y agoThis @mtlynch
- vlovich123 2y agoTo sanity check myself, I reran this without the buffered reader and still don't see the slow execution time: > echo '60016000526001601ff3' | xxd -r -p > | zig build run -Doptimize=ReleaseFast > execution time: 28.889µs So I think my machine config for whatever reason isn't representative of whatever OP is using. Linux-ck 6.8 CONFIG_NO_HZ=y CONFIG_HZ_1000=y Intel 13900k zig 0.11 bash 5.2.26 xxd 2024-02-10 Would be good if someone that can repro it compares the two invocation variants with buffered reader implemented & lists their config.