Suckless and cat-v fags eternally BTFO

GCC probably sees this as a no-op and optimizes it out.

two orders, my bad.

Based GNU

Post speed.
H/W: Ryzen 2500U + HDD.

Attached: post.png (1300x615, 192K)

>intentionally left out Plan9
Gee I wonder why.

pi@raspberrypi:~ $ yes | pv > /dev/null
5GiB 0:00:06 [ 857MiB/s] [ ]

Interesting.

while true ; do echo "yes" ; done is only 1MB/s while GNU's yes does the exact same output at 10GB/s

Ivybridge 3570k

>suckless
more like suckmore

Attached: Screenshot_2019-05-24_22-59-43.png (641x335, 34K)

Listen retard, the GNU system's goal is being a free system; nobody gives a shit about competition. Linux-libre works and there's no reason to further develop Hurd.
I hope this generates some understanding why the 'Hurd still isn't finished' meme is retarded.

This is Poe's law tier lmao

>/dev/null is hard-drive performance
retard
>doing cat 'file' | grep 'thing' instead of just grep 'thing' 'file'
double retard

~2.6GB/s on WSL
CPU is a 4690K

>Shitting in toilet instead of street
double retard

>don't ask how shit works
>release butthurt instead
oof

What about with mitigations=off? Context switches were like 7x faster before Spectre.

>wsl
Why would you openly admit this?
Don't you have any self respect?

Attached: 1549069880724-0.png (429x410, 5K)

What board do you think you're on?

>Don't you have any self respect?
Nah not really
I just thought it may have been an interesting data point

That's some shit tier cope you got going on kiddo

Are you fitting in sweetie?

openbsd run the command the fastest
$ yes | pv > /dev/null
/bin/ksh: pv: not found
$

So what's this supposed to be testing anyway? Yes just returns a string or 'y' and an exit code. It's not hitting the disk at all. pv shows the progress of data through a pipe (pipe view). So it's not touching the disk or even the vfs subsystem at all.

This command is testing the speed of certain syscalls as far as I can tell. Why are they so fast? Did OP or whoever he is quoting try them all on the bare metal?

It's MS shills or just one, like this user:

>34 posts
>1 windows user
>IT'S THE MS SHILLS
Why act this way?

yes | pv > /dev/null
^C86GiB 0:01:45 [4.92GiB/s] [ ]

daily reminder that st still doesn't have scrolling by default

apparently to suckless (actually more) fags this is bloat.

I don't think I've ever actually scrolled a terminal before even though the ones I use support it. That's like the whole point of `less`.

>retard
It might affect "yes" performance in theory. But I think it is resident in RAM, and I don't know frequency of it...
>double retard
I'm used to this, and even killing me won't solve problem. Yes, I'm the man who does this:
if (something() == true){...
So...

There was a fun thread at Hackernews some years ago on this topic. The question was why GNU suff is usually faster while other implementations which have much less code and therefore should run faster are actually slower. Turns out that the "bloated" code actually is there for a reason. Examples are cat, that reads stuff in chunks, grep that has some intelligent algos, etc. Looking into the utilities is worth it too, btw, since there are lots and more lots of comments.

- /dev/null is a virual device
- using grep 'pattern' file instead of cat file | grep 'pattetn' is the right day and saves a process

Termux:
GNU coreutils yes; [ 260MiB/s]
busybox yes: [3.75MiB/s]

This. The "LOC = bad" meme is retarded. GNU coreutils are overall very good and their code serves a purpose.

wtf, I love GNU now.

Because it is an obscure operating system no use uses? Its biggest fan killed himself? If they even have a yes program, it's probably the slowest too. Thompson and the other guys couldn't code for shit.

>Turns out that the "bloated" code actually is there for a reason.
To make it redneck-compatible with 1972 boomer-tier hardware. GNU's Pthread doesn't even make use of atomics, meaning a 2-minute-home-made spinlock is faster than pthread_mutex.

Before some sophomore CS retard even thinks about it, yes, pthread_mutex uses spinlock.

Newfag outs himself.

Attached: 1540698488512.gif (480x270, 1000K)

plan9 doesn't have vp anyways

How exactly is suckless/cat-v BTFO?
Yes, the BSDtards are BTFO, but neither Plan9 from user space nor 9base have the `yes` command.
Yeah! You sure showed suckless/cat-v by showing the superiority of a program deemed pointless bloat and COMPLETELY excluded from Plan9.

Even if it was 1000x slower, noone would notice it desu

>/dev/null is hard drive performance
Neck yourself retard, /dev/null is a kernel-specific location such that it doesn't even write to memory. It is faster than even your RAM.

>t. brainlet who can’t patch st

user, I'm pretty sure he was pointing that out.

the neckbeard shilling board?

>It is faster than even your RAM
prove it

Attached: .png (220x157, 6K)

How are BSDtards BTFO? What real life case does this simulate? What's being checked for performance here even?

I would also like to add how it's webscale

The lesson to take here is that programs made up of more code isn't necessarily a bad thing, just like algorithms, the simplest ones are always going to be inferior in some ways

Is this true?
Sounds Amazing

pv /dev/zero > /dev/null
9.53GiB/s on my phone

Just imagine the possibilities...

>__great__
Gtfo Linus

hohohohaha get the fuck out newfaggot, wangblows performance is perfectly relevant. Its also a pussy move to call other posters'shills' after getting btfo

Instead of doing fputs("y") in a loop, they first generate a large (4096 bytes I think) array, fill it with "y" and then fputs that in a loop.
This significantly reduces the overhead from the system call.

The higher the LOC, the higher the chance of you overlooking the backdoors

Attached: Screen Shot 2019-05-25 at 15.20.48.png (386x36, 4K)

The GNU system was designed by the best hacker alive.

The point of bloatless software isn't about speed for me. Having more control and a better understanding of what a program is doing is much more valuable to me than speed.

>his pea-sized brain can't even begin to comprehend the work of art that is gnu
Might as well use an iPhone.

Nice marketing buzzwords, faggot

Interesting, I'm getting 6.5-6.6GB/s on headless Debian stable with an i5 4570S CPU (it only hits like 3.3GHz while running this). 2 cores are at 100% while running this, so 10GB/s should definitely be possible on a CPU clocked much higher than this.

not necessarily true. you could have 10 lines of code with 10 errors or 100 lines with 0 errors get my drift?

cool beans

concise is not necessarily as short as possible
bloat is superfluous code

bloat is unnecessary features. do one thing and do it well

like yes, should spit out yes until it dies. it shouldnt have a -n flag to spit out no

>sets up giant pipe size on file descriptor
>allocates and pre-fills buffer
>writes full buffer at once
this way you can be on-par with GNU yes with roughly 100 lines of clean C

GNU yes: 4.8 GiB/s
this Go snippet: 5.91GiB/s
package main

import "os"

func main() {
buf := []byte{}
for i := 0; i < 4096; i++ {
buf = append(buf, []byte("yes\n")...)
}

for {
os.Stdout.Write(buf)
}
}

gnutards on suicide watch

BASED. I knew daddy Rob Pike was RIGHT after all.

>do it well
so far GNU's version is the only one that does its thing well

I would rather
suck | less
than

suck | more

you mean "BSD never got to goal"

>139 MB/s
Sure, its not faster than GNU, but its faster than the shit pic related is pushing

Attached: yes.png (343x96, 9K)

try GNU on same machine

Why do you NEED yes to spit out y at 35GB/s?
What possible fucking use case would this come in handy where other yes implementations aren't fast enough?

Attached: 2019-05-25-184304.png (612x446, 12K)

>Why do you NEED yes to spit out y at 35GB/s?
We need common sense yes control.

>Why do you need a 35GB/s 'yes'?
>Why do you need a 10Mb/s internet connection?
>Why do you need websites to be Why do you need your text editor to start in under 5 seconds?
>Why do you need a >128G disk?
>Why do you need a quad core cpu?
>Why do you need a dedicated graphics card?
>Why do you need a physical keyboard?
>Why do you need a >17" monitor?
>Why do you need >1366x768?
>Why do you need a headphone jack?
>Why do you need >2 usb ports?
>Why do you need an ad blocker?
>Why do you need programs Why do you need gigabit ethernet?
>Why do you need your OS to boot in Why do you ne...

No shit. I've demonstrated this same concept before against muh bloat c turds who don't understand that syscalls are demons and retard simple c shit is slow.

is gnu hurd actually usable

>all the hurt shill replies
Based

GNU: 666MiB/s
Busybox: 10.4MiB/s

if you know the GNU base64 command, i made very fast "base2" command that can encode/decode incoming data into/from binary-ascii

It's pretty IO-bound so it depends on how fast your computer can read/write stuff but I get ~800 MiB/s from urandom and 1.5 GiB/s from zero on my i3-6100 with 8GB of dual-channel DDR4

./base2 --wrap=0 /dev/urandom | pv > /dev/null
11.3GiB 0:00:15 [ 790MiB/s] [

./base2 --wrap=0 /dev/zero | pv > /dev/null
23.9GiB 0:00:17 [1.50GiB/s] [

I made it using an accelerated method utilizing the "pext" command(haswell and newer), and if you dont have pext then it will use a fast SWAR method(which still has room for improvement with some more SIMD tricks as well).

feel free to try it yourself

git.io/fjBj6

No bully

Attached: 1555739556465.webm (601x750, 2.77M)

Y'all faggots with your fancy ass fast computers
This is a 2.7 GHz Sempron 140 running Slackware

Attached: 20190525_140210.jpg (427x77, 18K)

the basis of the two implementations

the pext + binary-or way is a quick way to convert 8 bytes at a time into binary ascii while the swar method uses more tricks but with some SSE/AVX/AVX2/AVX512 stuff I can make it do up to 16/32/64 bytes in parallel!

Attached: kitty_2019-05-25_11-03-11.png (509x376, 145K)

Linus is a fucking beast. He wrote so much good shit and is still managing to run a youtube channel. What the fuck man, this guy is insane.

Attached: yorkshire-tea-2000858_2.jpg (850x850, 194K)

Fucking amazing.

There's a lot of Pajeets replying to this message. They are working hard today.

>Linus wrote GNU
The state of Jow Forums

yes prints just y\n so you're feeding it more data every time

I have two Xeons with mitigations=off and I'm only getting [5.26GiB/s]

raspberry pi 3b gets ~1GB
just so you know