bu

This is basically the philosophy of https://github.com/c-blake/bu/blob/main/doc/tim.md , but it uses a somewhat fancier estimator of the minimum than the sample min of dt's (which in some sense is guaranteed to be "a little" high). There are other benchmarking points in that document about measurement footguns that can arise from targeting a specific duration like the 200..400ms of TFA with an easy but careless problem scale-up (like the Ben Hoyt example of footnote 4). With that tool, in user space with just CPU freq pinning, I routinely see CPU bound times that are stable to single digit microseconds month to month on the same machine and see 0.01% to 0.2% effects on 10ms scale activity (yes, 1..20 bps) and the reported uncertainty usually captures the variation all right, but the distribution is not really Gaussian/Normal and instead h

Something Dan does not observe in his article (perhaps Jamie does elsewhere? edit: or even Dan elsewhere) is that the same problem which makes the memory latency benchmark unrealistic (or at least misleading) often impacts hash table lookup benchmarks as mentioned at https://github.com/c-blake/bu/blob/main/doc/memlat.md and probably many other benchmarks. Essentially, CPU work prediction/speculative execution has become so good that much care is often required to measure latency rather than reciprocal throughput. This all started in the 1990s (or probably earlier with Cray), but I guess there's been an ongoing educational failure/oversimplification tendency. Of course, throughput at one "level of work" is often latency at a higher level (like command-to-command execution, for example). So, "what matters" might be throughput or "latency

Yeah. The Flask web-page prototype was indeed in Python. (The prequel shirt was Go.) { Also, it was my own Py version which I mostly did in case anyone wanted to actually run the thing after such interest was expressed on this thread. :-) } I already said regular devs and LLMs can both gen copy-pasta. That said, being "mostly" a Python dev, asking some LLM to translate to bash for him seems even more likely to me. Only he or those close to him knows for sure. You & I cannot settle it here conclusively (as also said). I also noted from the video that the ♥s (hearts) worked on whatever version of bash he tested with though it failed for me (which is why I wrote that Python). And his terminal title bar is switching between `tput` and `bc` and such meaning that what he was demoing was not some Python script. ¯\_(ツ)_/¯ EDIT: Ah..another

One of the coolest tricks is using tcc to compile "on demand." This allows you to use a compiled language like Nim for scripting, with almost no noticeable performance difference compared to interpreted languages. #!/usr/bin/env -S nim r --cc:tcc -d:useMalloc --verbosity:0 --hints:off --tlsEmulation:on --passL:-lm echo "Hello from Nim via TCC!" Here's a comparison (bash script at [1]) of a minimal binary compiled this way with different interpreters. First line is the noise. Measured by tim[2] written by @cb321. 1.151 +- 0.028 ms (AlreadySubtracted)Overhead 1.219 +- 0.037 ms bash -c exit 2.498 +- 0.040 ms fish --no-config --private -c exit 1.682 +- 0.058 ms perl -e 'exit 0' 1.621 +- 0.043 ms gawk 'BEGIN{exit 0}' 15.8 +- 2.2 ms python3 -c 'exit(0)' 20.0 +- 5.7 ms node -e 'process.exit(0)