5 ms·
I think this is originally to avoid any possible plagiarism claims by Unix--if a Unix tool was originally optimized for one of size/efficiency/speed/memory use,
by creatornator 8y ago
I think this is originally to avoid any possible plagiarism claims by Unix--if a Unix tool was originally optimized for one of size/efficiency/speed/memory use, the GNU tools were optimized for one of the others. This is part of why the `yes` utility is so freakin fast in GNU, despite being kind of a weird use case for speed.
Mac builtin:
yes | pv > /dev/null
139MiB 0:00:05 [28.4MiB/s]
GNU:
gyes | pv > /dev/null
3.31GiB 0:00:06 [ 584MiB/s]
- zorked 8y agoI don't know if it is or isn't the plagiarism thing but GNU tools were written with a very different, way more modern style than Unix tools. Unix was pretty much "do a quick loop using terse code" and "see what fits in this static small buffer, and if it doesn't, quietly truncate". GNU would reallocate buffers to fit, and take reasonable precautions on performing well on tiny/huge inputs. GNU was actually considered bloated by the Unix crowd ("why so many more kilobytes of code?" ). It's an approach that scaled better for the future though.
- creatornator 8y agoSee section 2.1 of [0] and the top response to this comment [1]. You'll note in the GNU standards there, it encourages optimizing for the opposite of Unix to avoid collisions in strategy. [0] https://www.gnu.org/prep/standards/standards.html#Reading-Non_002dFree-Code https://www.gnu.org/prep/standards/standards.html#Reading-No... [1] https://news.ycombinator.com/item?id=14543536 https://news.ycombinator.com/item?id=14543536
- kccqzy 8y agoIt obviously has a bit of work put into it to make it fast: https://github.com/coreutils/coreutils/commit/35217221c211f3116f374f305654462195aa634a https://github.com/coreutils/coreutils/commit/35217221c211f3...