
How is GNU `yes` so fast? - ruleabidinguser
https://www.reddit.com/r/unix/comments/6gxduc/how_is_gnu_yes_so_fast/?st=j3v3iw3c&sh=5651ea3c
======
exxo_
Speed vs readability:

[https://github.com/coreutils/coreutils/blob/master/src/yes.c](https://github.com/coreutils/coreutils/blob/master/src/yes.c)

[https://github.com/openbsd/src/blob/master/usr.bin/yes/yes.c](https://github.com/openbsd/src/blob/master/usr.bin/yes/yes.c)

~~~
avar
One thing to keep in mind when looking at GNU programs is that they're often
intentionally written in an odd style to remove all questions of Unix
copyright infringement at the time that they were written.

The long-standing advice when writing GNU utilities used to be that if the
program you were replacing was optimized for minimizing CPU use, write yours
to minimize memory use, or vice-versa. Or in this case, if the program was
optimized for simplicity, optimize for throughput.

It would have been very easy for the nascent GNU project to unintentionally
produce a line-by-line equivalent of BSD yes.c, which would have potentially
landed them in the 80/90s equivalent of the Google v.s. Oracle case.

~~~
exxo_
This is the first revision:

[https://github.com/coreutils/coreutils/blob/ccbd1d7dc5189f46...](https://github.com/coreutils/coreutils/blob/ccbd1d7dc5189f4637468a8136f672e60ee0e531/src/yes.c)

~~~
h2hn
And here is the madness: :)

[https://github.com/coreutils/coreutils/commit/35217221c211f3...](https://github.com/coreutils/coreutils/commit/35217221c211f3116f374f305654462195aa634a)

~~~
alkonaut
And the motivation: it's used as test inputs. Not sure I agree with completely
destroying the readability of a perfectly readable file - but ok.

~~~
acqq
The motivation, as far as I see, was only that it "may be used."

But see the post of belorn where he argues that the error handling seems to be
good.

------
tzs
The /r/programming discussion of this is interesting [1].

Someone does a Go version and gets the same speed as GNU yes. Someone else
tries several languages. This person got the same speed in luajit, and faster
in m4 and php. Ruby and perl about 10% slower, python2 about 10% slower still,
and python3 about half that. The code is given for all of these, and
subsequent comments improved python3 about 50% from his results, but still not
up to python2.

[1]
[https://www.reddit.com/r/programming/comments/6gxf02/how_is_...](https://www.reddit.com/r/programming/comments/6gxf02/how_is_gnus_yes_so_fast_xpost_runix/)

~~~
acomjean
I had to smile, as this thread is a microcosm of programming language
stereotypes: with the python programmers tweaking code to get that extra 10%
(nobody mentioned pypy..), someone trying to get javascript to work in a long
running program, of course a rust implementation that isn't working well just
yet (but we're all rooting for it.. set that compiler flag and rerun).. One
comment about perl (turns into a one liner..). Nobody bothering to redo the
Lua, Ruby and PHP. And for fun somebody throws down some fortran.

what is going on with the m4 code?

~~~
jrimbault
One night for fun, I wrote a fizzbuzz (without actual printing) in almost all
of the languages mentionned here (except fortran), and benchmarked it with
10000 executions each.

~~~
simon83
Pretty sure none of your implementations will beat the
FizzBuzzEnterpriseEdition [1].

[1]:
[https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...](https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition)

~~~
jrimbault
That link is always marked as already visited and yet I always forget it
exists.

------
pixelbeat__
The recent commit that sped up GNU yes has a summary of the perf measurements

[https://github.com/coreutils/coreutils/commit/3521722](https://github.com/coreutils/coreutils/commit/3521722)

------
mooktakim
If anyone, like me, is wondering what "yes" is used for. You can use to pipe
"y" to commands that require interactivity, so if you just want to say "y" to
all the inputs, you can use "yes" to do this:

    
    
      yes | rm -r large_directory
    
      yes | fsck /dev/foo

~~~
teapot01
I know its only an example but why

    
    
       yes | rm -r <>
    

and not

    
    
        rm -rf <>

~~~
x1798DE
I think rm -rf would also suppress errors in addition to confirmation
messages, so presumably if you want a "soft" force...

~~~
eridius
No it doesn't.

    
    
      > rm -rf foo/bar
      rm: foo/bar: Permission denied

~~~
mnarayan01
If foo/bar does not exist, it should be silent. Via
[http://pubs.opengroup.org/onlinepubs/007904975/utilities/rm....](http://pubs.opengroup.org/onlinepubs/007904975/utilities/rm.html)
on the -f option:

> [...] Do not write diagnostic messages or modify the exit status in the case
> of nonexistent operands. [...]

~~~
eridius
Yes, but that's the only error it suppresses, and that's because "not
existing" isn't really an error for a tool that's trying to delete something.
In my example foo/bar existed but I didn't have permissions to delete it, and
as you'll see it printed out that error.

------
madeofpalk
Back when I worked at the Genius Bar at Apple Stores I saw a customer come in
and talk to a 'Genius' about their MacBook being "slow". After a quick bit of
troubleshooting, he just opened up 4 terminal windows an ran yes in all of
them, and did some hand wavy explanation about diagnostics.

~~~
noobermin
I'm curious why he did it. To impress people who work at the apple store?

OK, may be I misunderstood, who ran yes, the customer or the genius?

~~~
Vinnl
I just read this on Wikipedia
([https://en.wikipedia.org/wiki/Yes_(Unix)#Uses](https://en.wikipedia.org/wiki/Yes_\(Unix\)#Uses)):

> In 2006, the yes command received publicity for being a means to test
> whether or not a user's MacBook is affected by the Intermittent Shutdown
> Syndrome. By running the yes command twice via Terminal under Mac OS X,
> users were able to max out their computer's CPU, and thus see if the failure
> was heat related.

~~~
jscheel
Now if I could just prove to Apple that my computer randomly shuts down all
the time... problem is, it doesn't appear to be heat related.

~~~
kawsper
Mine just freezes, the last 0.3 second of sound is just repeated until it
reboots by itself.

~~~
_red
For reference, I had that exact same issue on my MBA - went on for years. Many
times while watching youtube or doing something Garageband related.

At the time I had 10.11 on it, but that OS had itself been upgraded from
10.10.

When 10.12 came out, I decided to install fresh - so I backed everything up
and installed onto a new SSD drive. The issue has now gone away completely....

------
joosters
_the limit isn 't the processor, it's how fast memory is. With DDR3-1600, it
should be 11.97 GiB/s (12.8 GB/s)_

I don't understand this reasoning. Why is it being limited to main memory
speed? Surely the yes program, the fragments of the OS being used, and the
program reading the data, all fit within the L2 cache?

~~~
pandaman
In general, only the CPU itself sees the L2 cache. Anything you see on another
device (screen, disk, NIC etc) has been flushed out of cache.

~~~
joosters
Sure, but this is a pipe between two tiny processes, hopefully with very
little else being run on the computer at the time (otherwise all bets are off
for any benchmarking). There's no kind of 'real' I/O going on (in terms of
stuff like screen, disk, NIC, and so on)

There's no reason that the L2 cache _needed_ to be flushed at any point - the
caches are all dealing with physical memory, rather than virtualised address
space, so the fact that there are two processes here shouldn't stop the
caching from working.

~~~
pandaman
I am probably way behind the current state of the CPU judging by the downvotes
I got so if you are saying there is no reason and the data can be written into
a device without leaving the CPU I will just concede my ignorance.

~~~
joosters
Don't fret about the downvotes, these magic internet points aren't redeemable
anywhere :)

It's completely possible for the data to not (all) leave the CPU. If the
caches are large enough, then the pages full of "y\n" will be still resident
in the cache when the next iteration of the program overwrites the same pages
again. Then the CPU has no need to send the original page out to main memory.

~~~
pandaman
If you did for(;;) buffer[(i++)%size] = 'y'; then you'd be correct. However,
you do i/o. And the 'y's appear at the i/o driver and have to be made visible
for the device it's driving, which can be anything, including a process on
another CPU core in another socket. If they remained in the issuing CPU cache,
I fail to see how the destination device could possibly see them. There are
some devices which can snoop the cache (like SoC GPUs and other CPU sockets on
some archs) but the snooping is much slower than memory bus. Writing to memory
is the only way which a) guarantees the data is available elsewhere and b) is
the fastest.

------
mkj
You could make "yes" faster with the tee() syscall. Keep duplicating data from
the same fdin (doesn't actually copy) and it becomes entirely zero-copy.

~~~
mrb
Actually yes should use vmsplice().

And pv on the other side of the pipe should use splice().

Now that would be a complete zero-copy I/O path, purely limited by the CPU,
not by memory bandwidth. It would benchmark at hundreds of GB/s :)

~~~
gpderetta
Someone posted an implementation which uses vmsplice on the reddit thread:

[https://www.reddit.com/r/unix/comments/6gxduc/how_is_gnu_yes...](https://www.reddit.com/r/unix/comments/6gxduc/how_is_gnu_yes_so_fast/diu73y0/)

~~~
mrb
His code can further be optimized by having only 1 large element in the iovec
(vs. many 2-byte "y\n" elements).

~~~
nyanscat
from what i can see it's already in a large iovec buffer

~~~
mrb
Correct, I misread the code. However bumping the pipe size buffer bumps the
speed from 28 to 74 GB/s on my Skylake CPU (i5-6500).

Edit: I optimized further and now get 123 GB/s See
[https://www.reddit.com/r/unix/comments/6gxduc/how_is_gnu_yes...](https://www.reddit.com/r/unix/comments/6gxduc/how_is_gnu_yes_so_fast/diua761/)

~~~
gpderetta
next step is playing tricks with memory mapping so that the buffer is large in
virtual memory but only takes a single page in physical memory, fitting in L1
(at least on the read side).

------
tobik
FreeBSD's yes has just been updated because of this.

[https://github.com/freebsd/freebsd/commit/1d61762ca37c20ab6f...](https://github.com/freebsd/freebsd/commit/1d61762ca37c20ab6fa4f5de6e179fa530ec49f2)

It's about twice as fast as GNU yes now on my FreeBSD system here.

~~~
pixelbeat__
Looks like that may drop some data if you get a short write, possible when
writing to pipes etc.

Update: They fixed that issue with this follow up
[https://github.com/freebsd/freebsd/commit/2592fbb8](https://github.com/freebsd/freebsd/commit/2592fbb8)

------
sequoia
Let's not forget the most crossplatformest, purest `yes` of them all:
[https://www.npmjs.com/package/yes](https://www.npmjs.com/package/yes)

    
    
        # /usr/local/bin/yes | pv > /dev/null
        11.5MiB 0:00:09 [1.02MiB/s] [                             <=>]
        
        # /usr/bin/yes | pv > /dev/null
        1.07GiB 0:00:09 [ 142MiB/s] [                             <=>]
    

JavaScript wins again!!

~~~
sequoia
It's come to my attention that lower numbers are not better here. I have filed
a bug, we'll get to the bottom of this shortly. I want to apologize to all our
users, this issue does not reflect the values and principals we at Pure
JavaScript `yes` hold dear
[https://github.com/Sequoia/yes/issues/3](https://github.com/Sequoia/yes/issues/3)

------
luckydude
I was not going to post this because hacker news has this ethic (?) of down
voting anything that seen as not positive. Perhaps we should have discussion
about that, I'm not sure that's a good thing but I'm not in charge here.

The top comment is:

"It's a shame they didn't finish their kernel, but at least they got yes
working at 10GiB/s."

which as an OS guy, someone who has been working on Unix for 30+ years, as a
guy who was friends with one the QNX kernel guys (they had perhaps the only
widely used microkernel that actually delivered), that's hugely amusing and
spot on. The GNU guys never really stepped up to being kernel people. Bitch at
me all you want, they didn't get there. It's a funny comment, especially
coming from reddit.

~~~
mintplant
> hacker news has this ethic (?) of down voting anything that seen as not
> positive

We must not be reading the same Hacker News...

Anyway, the comment you're quoting is just a shallow jab that belittles the
GNU developers' work without contributing anything new or meaningful. It's
telling that you had to spend two paragraphs to justify cross-posting it here.

~~~
ruleabidinguser
You say that and then immediately become an example of what hes talking about.
This "shallow jab that contributes nothing new or meaningful" is, in some
circles, known as a "joke." I'm continually frustrated by people who think
that misinterpreting comments as harmful is a useful activity.

~~~
mintplant
Not really -- I didn't downvote that comment. And I still dispute the notion
that negativity is rare or always shunned on this board: to the contrary, it's
so commonplace that an actual rule [0] had to be added to try to sway things
in the other direction.

Jokes have their place, but bringing up the failure of Hurd in every GNU-
related post is banal. And saying they "never really stepped up" to your level
as a mighty kernel developer, as if the people who brought us glibc and
coreutils lack an understanding of OS internals, just seems rude and curiously
out of touch.

[0]
[https://news.ycombinator.com/item?id=9317916](https://news.ycombinator.com/item?id=9317916)

~~~
luckydude
So negativity here is not rare, when people don't like something they are fast
to jump on it.

What I was trying to get at is this, if you care about your upvotes, hacker
news promotes a sort of hive mind. Which is somewhat like "say only nice
things unless you are clearly swatting down something that is obviously
wrong".

Which is mostly fine, fantastic in fact. I'm fine with it, hacker news is
really pleasant because of the (more or less _) quality of the posts and
especially the quality of the comments. I 'd much rather have it be this way
than a free for all, those go bad pretty fast.

So I'm for the hive mind, I was just pointing out that you can't make jokes
and be upvoted. The joke wasn't banal at all IMO. GNU has done a lot of good,
I've been there since the beginning and paid attention along the way. They
have also been pretty self serving with their choices, every project has to
sign away their rights and then GNU takes full credit for the project even
though they had nothing to do with it other than it being GNU troff for
example. Given their tendency to take credit for stuff that they didn't do,
and their claim that they can do an OS but clearly can't, that joke is funny
as heck. If you don't get that, sorry, you haven't been paying attention.

(_) The quality of the posts in the area of programming, especially systems
programming, is spotty. Some stuff is great, stuff I didn't know (there is a
lot of that here and I'm very grateful for it, it's why I stick around), some
stuff is meh, and then there is stuff like "wow, look at $OBVIOUS, isn't that
cool?" that gets upvoted. That last one I just don't get, but whatever, the
good stuff is good. The signal/noise ratio here is better than any other
programmer oriented site I've found.

------
akerro
Years ago I read a similar experiment about max. CPU data flow. Guy was
testing how much data can his CPU pass in a second. He was writing it in C,
using some Linux optimization, optimizing code for CPU caches, using some
magical C vectors that are optimized for such purpose. He got some help from
someone working at Google. I tried to find that post but never succeeded. Does
anyone here know it?

------
jvolkman
`yes` (with the backticks) is my favorite "bring the system to its knees right
now" shell command.

~~~
ZenoArrow
What does `yes` try to do?

~~~
aexaey
This will attempt to open a child shell process with whatever output of "yes"
is, interpreted as shell script.

But before that, parent shell has to buffer until EOF. With "yes" output being
unbound, this means unbound buffering / memory growth. That is, until OOM
killer take notice and shut it down.

Whole thing will probably take few seconds to a minute (depending on how much
free RAM there is vs. how fast it is), peg a single CPU core in the process,
and will recover cleanly (except for shell in question being terminated).

...unless system in question has single CPU and large+slow swap. Then yes,
bring-it-to-its-knees.

~~~
marcosdumay
It may also push everything in memory to swap in the process, what is the real
speed killer.

~~~
AstralStorm
Make sure to have a sane memory limit set in PAM and switch vm.swappiness to
lower value than 60.

------
raverbashing
And the question is, do we need yes to be so optimized?

Not complaining, I like this kind of analysis

But it seems you won't be limited, in a shell script, by the speed you can
push y's

~~~
jlarocco
That kind of question doesn't make sense for open source code.

Somebody wanted to optimize 'yes', so they did. There doesn't need to be a
good reason, just like there doesn't need to be a good reason for a person to
read a certain book or watch a certain movie, other than they want to do it.

~~~
raverbashing
The question was "do we need it? (for a specific use case)" rather than
"should we do it?".

And it does make sense for Open Source code because the resources are limited
hence other features and/or bug fixes might be more important than pushing
data at full speed

~~~
jlarocco
> And it does make sense for Open Source code because the resources are
> limited hence other features and/or bug fixes might be more important than
> pushing data at full speed

That's not how open source works, though. There's not a group of people
obligated to work on the GNU utilities. There's not a central project manager
ordering people around telling them what changes to make.

Declaring that 'yes' is generally fast enough already doesn't imply that it
was fast enough for the person who spent their time optimizing it. Somebody
needed (or just wanted) 'yes' to be really fast, so they did the work and
submitted the changes back.

~~~
raverbashing
> There's not a central project manager ordering people around telling them
> what changes to make.

No, but there is review and approval of patches (also the most frequent
contributors know where the project is going and there is bug tracking)

If one just makes it faster without major benefits that patch is likely to be
rejected

~~~
jlarocco
> If one just makes it faster without major benefits that patch is likely to
> be rejected

 _IF_ the project were overwhelmed with incoming patches, then I would agree
that there's probably higher priority changes than optimizing 'yes'.

But I'm almost certain the GNU project is not being overwhelmed with changes
to the core utilities. Everything else being equal (code quality, readability,
test coverage, etc.) there's really no reason to reject a patch that
demonstrably improves the project, even in some silly way like making 'yes'
really fast.

------
ww520
I would just pre-allocate a static array of "y\n" of size BUFSIZ, write it out
in a loop, and call it for the day, skipping the whole malloc and filling loop
business.

Make the static array BUFSIZ * 1024 to trim the syscalls by a factor of 1000.

~~~
boulos
Real yes accepts a string to print (so you can have it spit out a full "yes"
or "Y" rather than a hardcoded "y").

~~~
ww520
Have a few pre-written arrays for the common cases: "y", "Y", "n", "N", etc.
Those are the fast cases (or the benchmark optimized cases, like, what
Volkswagen did). Have another pre-allocated static array to fill in with other
input.

~~~
skrebbel
> _(or the benchmark optimized cases, like, what Volkswagen did)_

This is amazing. Maybe we can turn this into a verb? "I Volkswagened the
common cases with precalced buffers".

~~~
kuschku
That's how you get sued. Especially because now Ford and GM are also in court,
for having done the same as VW.

~~~
gjm11
Let me check that I have correctly understood the scenario you're
anticipating.

1\. Someone uses "volkswagen" as a verb meaning "cheat in benchmarks".

2\. Volkswagen takes them to court, on the basis that it is slanderous or
libellous to associate Volkswagen with cheating in benchmarks.

3\. Counsel for the defence reminds the court that Volkswagen were in the news
for a protracted period for a benchmark-rigging that saw them hit with a
multi-billion-dollar fine, slashed a third off their stock price, saw their
CEO resign, led to there being a "Volkswagen emissions scandal" page on
Wikipedia, etc., etc., etc.

4\. [THIS IS THE BIT I'D LIKE YOU TO FILL IN FOR ME.]

5\. Volkswagen wins the case.

How exactly does step 4 go?

~~~
kuschku
By volkswagen arguing that this is industry standard behaviour, and the entire
media campaign is already libel and slander.

And they’d have a pretty good case with that, considering the original report
all this media campaign was based on called out 6 carmakers, but the media
(and the poster) only call out Volkswagen.

------
likelynew
Why is it so slow(compared to the post) in the macbook air. Native yes runs at
26 MiB/s, and GNU yes at 620 MiB/s.

~~~
aselzer
It isn't! yes runs at 7.2 GiB/s on my macbook air. Though I have Linux
installed on it instead of Mac OS :)

~~~
umanwizard
Are you trolling? The commenter obviously meant the macOS version of "yes".

------
Someone
With that malloc overhead, I expect GNU yes to be slower when only a few bytes
are read from it.

So, what's the distribution of #bytes read for runs of 'yes'? If we know that,
is GNU 'yes' really faster than the simpler BSD versions?

Also, assuming this exercise still is somewhat worhtwhile, could startup time
be decreased by creating a static buffer with a few thousand copies of "y\n"?
What effect does that have on the size of the binary? I suspect it wouldn't
get up much given that you can lose dynamic linking information (that may mean
having to make a direct syscall, too).

~~~
bonzini
Unless you are statically linking, one malloc doesn't significantly affect
your startup time. When only a few y's are read, time is going to be dominated
by ld.so, by a large margin.

------
ojn
Measurements are really noisy, but I seem to get significantly better numbers
than that when I use fsplice() on a pre-generated few pages of file data
instead.

~~~
AstralStorm
Yes, splice can bypass the pipe buffer in some cases.

------
metaphorm
I thought this was a fascinating read but it left a serious question lingering
in my mind, which is a little out-of-scope for the article, but I hope someone
here can address.

Why did the GNU developers go to such lengths to optimize the yes program?
It's a tiny, simple shell utility that is mostly used for allowing developers
to lazily "y" there way through confirm prompts thrown out by other shell
scripts.

is this a case of optimization "horniness" (for lack of a better word) taken
to its most absurd extreme, or is there some use case where making the yes
program very fast is actually important?

~~~
kevingranade
The stated use case for the perf improvement was "yes(1) may be used to
generate repeating patterns of text for test inputs etc., so adjust to be more
efficient."

Source:
[https://github.com/coreutils/coreutils/commit/35217221c211f3...](https://github.com/coreutils/coreutils/commit/35217221c211f3116f374f305654462195aa634a)

I've personally used it for generating repeating text and filling disks in
system testing, so I appreciate it being faster at those tasks. I also
sometimes use it as a signal generator for a hacky load generator, like so:

    
    
      yes | xargs -L 1 -P NUM_PROCESSES -I {} curl SOME_TARGET_URL > /dev/null
    

This doesn't benefit from being _faster_ per se, but I appreciate it using
less CPU since I want to give curl as much system resources as possible.

------
ars
But doesn't this make the typical use case (just a few "yes"s needed) slower,
since first it has to fill a buffer?

I would write() the buffer each time it gets enlarged, in order to improve
startup speed.

Also: The reddit program has a bug if the size of the buffer is not a multiple
of the input text size.

And it's increasing the buffer by incrementing one at a time, instead of
copying the buffer to itself, reducing the number of loops needed (at cost of
slightly more complicated math).

~~~
nostrademons
If your only overhead is filling an 8K buffer, I don't think your user is
going to care. Taking one microsecond instead of one nanosecond doesn't matter
all that much when you're going to lose way more than that in pipes, the
kernel, the program you're piping it to, etc.

~~~
statictype
But what's the use case for a large volume of continuous output? It feels like
we're optimizing for the wrong use case

~~~
pmontra
Maybe filling a disk or flooding a network connection as in

    
    
        yes | ssh server "cat > /dev/null" 
    

But yes take arguments so there might be more use cases:

    
    
        $ man yes
        NAME
               yes - output a string repeatedly until killed
        
        SYNOPSIS
               yes [STRING]...
               yes OPTION
        
        DESCRIPTION
               Repeatedly output a line with all specified STRING(s), or 'y'.

------
kazinator
GNU yes is fast because it is coded with the assumption that it's not
answering any real question, such as _" can I combine this free code with a
proprietary program?"_ or _" Would you accept the following monstrous patch to
GNU Coreutils /bin/true without a copyright assignment?"_

------
souprock
I think we can do better.

How about a /proc/bin/yes for this? Like most /proc files, it would appear to
be empty. Executing it would involve a fs/binfmt_proc.c file in the kernel
source, which would be a handler for this sort of executable. That would get
the job done entirely in the kernel.

------
sytringy05
man, I just spent like 8 minutes today writing a python script to use up all
the disk space on some servers (part of ops readiness testing) when I could
have just used this trick.

`yes` will help me on the "see what happens when something uses all the CPU
and memory" test case. Thanks Reddit/HN!

~~~
acdha
dd can also be useful for that kind of thing since you can use a source like
/dev/urandom to generate random bytes if you're trying to avoid compression
and the adjustable block sizes can be optimized for the underlying storage
system.

~~~
sytringy05
I did actually use dd to begin with but it didn't work as I wanted it too
right away (can't remember why, probably something SUSE related) and by then
I'd used up 6 mins of the 15 mins I gave myself for the job.

I also had to do the same test on windows, so python won

------
melicerte
Did you notice PHP outperforms any other scripting languages? Some report that
it event beats the GNU yes implementation.

After reading here so many unfair critics and pedantic dislike over
PHP[1][2][3][4][5][6], I just want to say: STFU.

[1]
[https://news.ycombinator.com/item?id=12706136](https://news.ycombinator.com/item?id=12706136)

[2]
[https://news.ycombinator.com/item?id=3825227](https://news.ycombinator.com/item?id=3825227)

[3]
[https://news.ycombinator.com/item?id=3824881](https://news.ycombinator.com/item?id=3824881)

[4]
[https://news.ycombinator.com/item?id=1823022](https://news.ycombinator.com/item?id=1823022)

[5]
[https://news.ycombinator.com/item?id=1819517](https://news.ycombinator.com/item?id=1819517)

[6]
[https://news.ycombinator.com/item?id=1819413](https://news.ycombinator.com/item?id=1819413)

... Just to name a few.

~~~
dom0
It's almost funny that you try to refute, or rather, dismiss, criticism of PHP
with "but it's fast", when none of what you cite even mentions that. I just
want to say: STFU.

~~~
melicerte
I don't dismiss criticism. I dismiss unfair critics. What I cite is full of
that. And, btw, [6] implies PHP is slow, read on:

[quote]

It's hard to find a worse example than php, because when many "bad" languages
fail in one or the other category, php seems to fail in most categories.

* Java has a really repetitive syntax, but it's libraries might make up for that.

* C++ with all it's features has bazillion ways to shoot yourself, but it's arguably fast and the syntax is bearable. ...

[/quote]

~~~
gjm11
It doesn't in fact imply that PHP is slow. What it says about PHP (besides
"php seems to fail in most categories" which doesn't imply any single specific
failure because most != all) is this: "But php has both an ugly syntax,
horrendous stdlib, and fame of security issues." You will notice that none of
those specific complaints is about speed.

------
du_bing
I run the command `yes | pv > /dev/null` on my MacBook Pro, it's only 37m/s,
is this normal? I am not familiar with the command.

~~~
kjensenxz
From the OP:

>OS X just uses an old NetBSD version similar to OpenBSD's >NetBSD's is
139MiB/s, FreeBSD, OpenBSD, DragonFlyBSD have very similar code as NetBSD and
are probably identical,

It really depends on how fast your memory and processor are. Everything there
was benchmarked with an i7-4790 with DDR3-1600, and very very little running
in the background.

~~~
qb45
Two orders of magnitude difference can't easily be blamed on CPU, in this case
it depends on how optimized _yes_ is. I have some older version of _coreutils_
on one machine here and performance is similarly abysmal.

------
peter_retief
Well now I know what `yes` does (And pv)

------
Tepix
Why is he using backticks to quote "yes" in the title?

~~~
daveguy
It is common in markdown formatting to indicate a command line with
backquotes. It tells the markdown compiler to apply special css and possibly
syntax highlighting. So, a lot of people who write about shell commands and
setup tutorials, or use markdown on something like github will automatically
identify it as a command.

------
dekhn
clearly, we just need /dev/yes

~~~
e12e
Sounds like a reasonable feature request for systemd.

------
crb002
yes | write <USERNAME> "Don't you hate dialup connections?"

~~~
BenjiWiebe
I think you mean yes "Don't you hate dialup connections?" | write username

------
DonHopkins
The proprietary Oracle Solaris 11.2 yes really slowed down when they added DRM
and Verified Boot support...

------
arnaudsm
[https://m.xkcd.com/619/](https://m.xkcd.com/619/)

------
peterwwillis
tl;dr someone who doesn't understand how i/o works gets a small insight into
how memory and a cpu work and decides _" Buffering is the secret"_ and _" You
can't out-optimize your hardware"_

Can we have a new flag for posts by people who don't know what they're doing
so I can skip them? I am serious.

