Hacker News Reader

Comment by readingnews | Hacker News Reader

I wonder if Brainfuck wins by his 100th of a second since he already called a program with words.txt, and therefore it was already loaded into memory, thus saving just a slice of time, as it would already be in the cache.

View on HN

Could also be that their version of wc is doing Unicode-aware counting by default; it could be a lot faster with LANG=C set in the environment.

https://unix.stackexchange.com/a/96580

For some reason, wc is even slower with LANG=C.

    cat words.txt | time wc -w
    13018291
    0.76 user 0.01 system 0:00.78 elapsed

That's on the default wc build of void linux, and not in a proper benchmark environment, but that's still strange.

I prefer setting LC_ALL=C for to be sure, though LANG may be sufficient, as running "LANG=C locale" confirms LC_CTYPE=C is set.

For a #shitpost, one need only observe the fastest run of program A being faster than the slowest run of program B, to declare A is faster than B.

With a sufficiently powerful static evaluator, you could embed the input into the program and get an even faster runtime.

> With a sufficiently powerful static evaluator, you could embed the input into the program and get an even faster runtime.

If you feel the need to cheat, you could do something like I used for dumb_cat [0] and dump the resulting executables into a cache somewhere.

[0] https://git.sr.ht/~shakna/dumb_cat

Wait... is that a Sourcehut user in the wild?

Of course. I love what Drew has built. I'm much happier (as a paying customer) with it as a platform than most of the others.

To avoid the caching bias, I think a fairer test condition would be to use multiple files and do it over a number of times. The lowest average time would be the winner.

You can manually clear the cache:

`echo 3 | sudo tee /proc/sys/vm/drop_caches`

But the file is loaded in cat, which isn't timed

But the timed program still has to wait for cat to load the file. Both programs are launched (almost) simultaneously by the shell.

The article only listed user and sys time usage, so technically that doesn't matter.

That being said, in my experience those timings are not very accurate at this time scale; timing a program which takes just a few tenths to execute may report halving or doubling the user time between subsequent runs (and vice versa for systime).

Reply on news.ycombinator.com