Fastest yes in the west

Question

There has been a question about yes in the past, but this one is slightly different. You see, despite yes having a rather long size, it is incredibly fast. Running the following command:

timeout 1s yes > out

yields a file that is 1.9 GB. Compared to this program:

int puts();main(){while(1){puts("y");}}

which yields a measly 150 Mb.

The goal is to write a program that outputs y\n (that's y with a newline) repeatedly forever, in as few lines as possible, outputting the biggest size file in as short time as possible.

The scoring works with the equation: b * y/y'. The value b is the size of your program in bytes. The value of y is the size in bytes of the out file after running the following command: timeout 1s yes > out. The value of y' is the size in bytes of the out file after running the following command: timeout 1s PROG > out where PROG is your program, eg. ./a.out. Your program should match the output of the gnu coreutils program yes ran with no arguments exactly, albeit outputting y at any speed you like. Outputting zero bytes would be a divide by zero in the original equation, resulting in a score of inf for these purposes.

Lowest score wins.

Edit:

I will run all code on my computer, please show compilation commands and any setup required.

Specs (in case you want to optimize or something):

• OS: Arch Linux 5.5.2-arch1-1
• CPU: AMD Ryzen 2600X
• SSD: Samsung 970 EVO NVMe
• RAM: 16GB 3200MHz

Here is a script to calculate the score, since it seems people are having trouble:

b=$(wc -c < $1)
timeout 1s yes > out
y=$(wc -c < out)
timeout 1s $2 > out
y2=$(wc -c < out)
rm out
echo "scale=3;$b*$y/$y2" | bc

Example, given that the script is called score.sh and your program is yes.py:

./score.sh yes.py "python yes.py"

Answer 1

C, 112 bytes, 28 TB/s, score ≈ 0.008

long b[9<<21];main(){for(b[2]=write(*b=1,wmemset(b+8,'\ny\ny',1<<25),1<<27)/2;b[3]=b[2]*=2;ioctl(1,'@ ”\r',b));}

(If you’re having trouble copying and pasting this, replace the multicharacter constant '@ ”\r' with '@ \x94\r' or 1075876877.)

This writes 128 MiB of y\ns to stdout, and then repeatedly invokes the FICLONERANGE ioctl to double the file’s length by adding new references to the same disk blocks. Requires Linux x86-64 and a filesystem supporting FICLONERANGE, such as Btrfs or XFS; stdout must be opened in read-write mode (e.g. ./prog 1<> out in bash).

Self-contained testing script

This script loop-mounts a freshly created filesystem from a memory-backed image file and runs the program there. (I get about 43 TB/s in-memory, but the ratio with yes(1) is similar.) It works with either Btrfs or XFS, but Btrfs seems to give better scores.

#!/usr/bin/env bash
set -eux
dir="$(mktemp -dp /dev/shm)"
cd "$dir"
trap 'umount fs || true; rm -r "$dir"' EXIT
printf "long b[9<<21];main(){for(b[2]=write(*b=1,wmemset(b+8,'\\\\ny\\\\ny',1<<25),1<<27)/2;b[3]=b[2]*=2;ioctl(1,'@ \\x94\\\\r',b));}" > prog.c
b="$(stat -c %s prog.c)"
gcc -O3 prog.c -o prog
dd of=fs.img bs=1 count=0 seek=8G

# Pick one:
mkfs.btrfs fs.img
#mkfs.xfs -m reflink=1 fs.img

mkdir fs
mount fs.img fs
sync
timeout 1 yes 1<> fs/out || true
y="$(stat -c %s fs/out)"
rm fs/out
sync
timeout 1 ./prog 1<> fs/out || true
y1="$(stat -c %s fs/out)"
echo "score = $b * $y / $y1 = $(bc -l <<< "$b * $y / $y1")"

Answer 2

Bash, 3 bytes, 1.9 GB/s

yes

Try it online!

Admittedly this is a troll solution, but the rules do not explicitly forbid it, and it should get you a value close to 3, which is not bad.

Answer 3

x86-64 machine code (Linux system calls), 29B * 4.7GB/6.6GB = ~20.6 on tmpfs on Skylake

(Or even 28 bytes, but I haven't benchmarked Noah's suggestion of using the low 16 bits of the address as the count for rep stosd. Asm source for it on Godbolt.)

At about 6.6 GiB/s, this runs faster than GNU yes on tmpfs, the widely-used Linux ramdisk-like filesystem backed by the pagecache. I made sure to align my buffer to at least a cache-line boundary (and in fact a 4k page boundary) so the kernel's copy_from_user memcpy-like function using rep movsb would be most efficient.

I don't expect this will outperform yes writing to an SSD on a fast Ryzen CPU which isn't the bottleneck; posted score is tentative. However, writing 2 or 4 bytes at a time is unusably slow so we need a buffer to avoid a huge score penalty (like a factor of 2000 on tmpfs!). But probably this will score about 29 running at the same speed as GNU yes if they both fill the page-cache to max capacity with dirty pages and max out I/O bandwidth during the 1s window.

It's break-even for code size to use a buffer in the BSS instead of reserving stack space, in a Linux position-dependent executable where a static address can be put in a register with 5-byte mov r32, imm32. Using more space in the BSS doesn't increase the size of an executable that already has a BSS section/segment. But in this case it does make the executable larger so I'm not totally sure it's justified to not count anything for executable metadata for the BSS. But as usual, I'm counting only the size of the .text section. (And there's no initialized static data; all the constants are immediate.)

Without aligning the stack by 64 or 4k, sub esp, edx; mov edi, esp would be only 4 bytes, and safe in a Linux x32 executable: 32-bit pointers in 64-bit mode. (For efficient syscall instead of slow int 0x80 or cumbersome sysenter in 32-bit mode). Otherwise break-even for sub rsp, rdx. So if not counting the BSS bothers you, save a byte and use the stack for buffers up to almost 8MiB (with default ulimit -s).

We fill a buffer that's 4x larger than we actually pass to write; rep stosd needs a repeat count of dword chunks and it's convenient to use the same number as a byte count for the system call.

Try it online! (NASM source which assembles to this answer's machine code.) It works on TIO; it doesn't depend on the output being a regular file or anything. Below is a NASM listing of machine code hexdump & source.

 6                                  global _start
 7                                  _start:
 8                                  ;; All regs zeroed at the top of a Linux static executable (except RSP)
 9                                  
10                                  SIZEPOW equ 17
13 00000000 0FBAE911                   bts  ecx, SIZEPOW  ; 1<<SIZEPOW x 4 bytes to fill.
14 00000004 89CA                       mov  edx, ecx      ; size arg for sys_write in bytes; 1/4 of the actual buffer size
15                                  
16 00000006 B8790A790A                 mov  eax, `y\ny\n`
25 0000000B BF[00000000]               mov  edi, buf        ; mov r32, imm32 static address; 00... is before linking
26 00000010 89FE                       mov  esi, edi        ; syscall arg
27                                  
28                                     ;shr  ecx, 2         ; just fill 4x as much memory as needed
29 00000012 F3AB                       rep  stosd           ; wmemset(rdi, eax, rcx)  4*rcx bytes
30                                     
31 00000014 8D7901                     lea   edi, [rcx + 1]  ;   mov  edi, 1
32                                  .loop:
33 00000017 89F8                       mov  eax, edi         ; __NR_write = stdout fileno
34 00000019 0F05                       syscall
36 0000001B EBFA                       jmp  .loop

47                                  section .bss
48                                   align 4096
49 00000000 <res 00080000>           buf: resd 1<<SIZEPOW

0x1b + 2 bytes for last instruction is 29 bytes total.

mov cx, imm16 would also be 4 bytes, same as BTS, but is limited to 0..65535. vs. BTS r32, imm8 creating any power of 2. (Both depend on a zeroed RCX to start with, to produce a result zero-extended into RCX for rep stos)

mov ax, `y\n` would be 4 bytes, 1 fewer than mov eax, imm32, but then we'd need rep stosw which costs an extra operand-size prefix. This would have kept the ratio of filled buffer to used buffer at 2:1 instead of 4:1, so I should have done that to save a few pagefaults at startup, but not redoing the benchmarking now. (rep stosw is still fast on Skylake I think; not sure if Zen+ might suffer; but more than a factor of 2 in fill bandwidth + page fault cost is unlikely.)

A static buffer makes alignment to a cache line (or even the page size) not cost instructions; having the stack only 16-byte aligned was a slowdown. I recorded times in comments on my original code that aligned the stack pointer by 64kiB or not after reserving space for a buffer. Alignment to 64k instead of 16B made a ~3% difference in overall speed for writing a 1GiB file (to tmpfs, exiting on ENOSPC) with SIZEPOW=16, and led to a reduction in instructions retired as well. (Measured with perf stat ./yes > testd/yesout)

     ;;;; instead of  mov  edi, buf
    sub  rsp, rdx
    ;   and  rsp, -65536   ; With: 631.4M cycles 357.6M insns.   Without:  651.3M cycles 359.4M instructions.  (times are somewhat noisy but there's a real difference)
 ;;  mov  rdi, rsp   ; 3 bytes
    push  rsp
    pop   rdi        ; copy a 64-bit reg in 2 bytes
    push  rsp
    pop   rsi

For other benchmarking purposes (with a smaller 1GiB tmpfs), it was convenient to use a loop that exited when write() failed (with -ENOSPC) instead of looping until killed. I used this as the bottom of the loop

35                                  %if 0
36 0000001B EBFA                       jmp  .loop
37                                  %else
38                                     test eax,eax      ;;;;;;;;;;; For benchmarking purposes: abort on write fail
39                                     jge  .loop
40                                  
41                                     mov eax, 231    ; not golfed
42                                     xor edi, edi
43                                     syscall         ; sys_exit_group(0)
44                                  %endif
45                                  

---

Testing

I tested using tmpfs because I don't want to wear out my SSD repeatedly testing this. And because keeping up with a consumer-grade SSD is trivial with any reasonable buffer size. More interesting (to me) is to find the CPU/memory-bound sweet spot between system call overhead from making too many small write system calls vs. L2 cache misses from re-reading too large a buffer every time. And also minimize time spent on filling a buffer before even starting to make system calls. (Although note that with write-behind I/O buffering for filesystems backed by real disk, there's no advantage to using a smaller buffer to get disk-write started sooner. I/O write-back to actual physical media wouldn't start until dirty pages hit the Linux kernel's high water mark. The default dirty timeout is 500 centisecs, and powertop suggests raising that to 1500 (15 seconds), so that's not going to come into play, just the high water mark. So what really matters is getting to the high water mark ASAP for a physical disk, and potentially pushing as many dirty pages into the pagecache as possible within the 1 second window, to finish writeback after yes dies. So this 1-second test probably depends on how much RAM your machine has (and even how much free RAM), if you're using a physical disk instead of tmpfs.)

write inside the kernel is basically a memcpy from the provided buffer into the pagecache; specifically Linux's copy_from_user function which uses rep movsb on systems with ERMSB (Intel since IvB) or rep movsq when it's fast (PPro and later, including non-Intel vendors.)

According to perf record / perf report output, with a 128k buffer size, 45% of the counts for hardware "cycles" were in clear_page_erms (on rep stosb) and then 18.4% in copy_user_enhanced_fast_string on rep movsb. (Makes some sense: clearing is touching a cold page, copy is copying over a just-cleared buffer, presumably hitting in L2 cache for src and destination. Or L1d for dst if it clears 4k at a time. Or only L3 cache if it's clearing whole hugepages :/) Next highest was iov_iter_fault_in_readable at 3.8%. But anyway, only ~63% of total CPU time was spent on the "real work" of actually copying into the pagecache. And that happens inefficiently, zeroing before copying.

I tried with tmpfs with huge=never (which is the default) and only got 4.8GiB for 1s with the 128kiB buffer version that gets 6.6GiB on hugepages. So clearly hugepages are worth it overall. perf record counts for cycles were: 14%: clear_page_erms and 10% copy_user_enhanced_fast_string, with many other kernel functions taking low single digits percentages, like try_charge at 4%, __pagevec_lru_add_fn, get_mem_cgroup_from_mm, __this_cpu_preempt_check, and _raw_spin_lock_irq at 3 to 2%. Managing memory in 4kiB chunks obviously costs a lot more than in 2MiB chunks.

Test setup

• i7-6700k @ 3.9GHz with 0xd6 microcode update (Nov 2019). (quad core Skylake-client microarchitecture, per-core caches: L1d 32k, L2 256k. Shared L3 = 8MiB) vs. Ryzen having 512kiB L2 caches.
  During this test: /sys/devices/system/cpu/cpufreq/policy0/energy_performance_preference = balance_performance, not full performance EPP setting. So this is closer to the normal bootup machine state of balance_power). I ran a warm-up run right before the main test to make sure the CPU speed was at full before the timed 1-second started: timeout 1s ./yes > testd/yesout; perf stat -d timeout 1s yes > testd/yesout.

  With EPP at performance (max turbo = 4.2GHz, near-instant ramp-up), in practice it runs at 4.1GHz average for the test. I get up to 6.9GiB written instead of 6.6, for the 128k buffer version. (And up to 7.3GiB with the writev version.)

• 16 GiB of DDR4-2666 (2x8GB DIMMs, dual channel)

• OS = Arch GNU/Linux, kernel = Linux 5.4.13-arch1-1

• Filesystem = tmpfs using transparent hugepages:
  sudo mount -t tmpfs -o size=10G,huge=always tmpfs /tmp/test. Much of the file is using transparent hugepages: from /proc/meminfo after writing a 6.4G file: ShmemHugePages: 6723584 kB (6566MB), and goes down to 83968 kB (82MB) after deleting it. It's using x86-64 2MiB hugepages instead of 4k normal pages to reduce TLB misses.

• System idle except for Chromium using about 3% of one core at idle clock speed.

• free memory was sufficient for tmpfs not to actually page anything out to swapspace during the test:

  $ free -m   # show numbers in megabytes.  Test output deleted; tmpfs nearly empty
                total        used        free      shared  buff/cache   available
  Mem:    15820        2790       12164         236         864       12497
  Swap:    2047         930        1117
  
  $ cat /proc/sys/vm/swappiness 
  6
  

• Spectre / Meltdown mitigations (big overhead per system call, above the ~100 cycles each for syscall / sysret to get in/out of the kernel):

  $ grep . /sys/devices/system/cpu/vulnerabilities/*
  /sys/devices/system/cpu/vulnerabilities/itlb_multihit:KVM: Vulnerable
  /sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion
  /sys/devices/system/cpu/vulnerabilities/mds:Mitigation: Clear CPU buffers; SMT vulnerable
  /sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
  /sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp
  /sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
  /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB filling
  /sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Mitigation: Clear CPU buffers; SMT vulnerable
  

Results writing to tmpfs for 1 second: best case 6.6GiB

Timed with this as a shell one-liner

 asm-link -nd yes.asm &&    # assemble with NASM + link
 taskset -c 3 timeout 1s ./yes > testd/yesout;     # warm-up run
 time taskset -c 3  timeout 1s ./yes > testd/yesout;
 ls -lh testd/yesout && rm testd/yesout

Up-arrow recall that string of commands a few times, take the best case. (Assume that lower values didn't ramp up the CPU speed right away; spent some time allocating hugepages, or had other spurious interference.)

I intentionally limited myself to only looking at 2 significant figures of file size (letting ls round to x.y GiB) because I know there's going to be noise, so perhaps keeping the data simpler might be good.

Results for various buffer sizes writing to tmpfs: 6.6GiB

(I did see 6.7G in some early testing with SIZEPOW=16 or 17, and I think even 6.8 or 9, but couldn't reproduce it once things settled down. Maybe some lucky early arrangement of hugepages that didn't last into a stable state?)

• SIZEPOW=1, buffer size: 2 (just 'y\n'), best-case size: 2.9MiB
  real 0m1.002s, user 0m0.431s, sys 0m0.570s

• SIZEPOW=2, buffer size: 4, best-case size: 5.8MiB
  real 0m1.002s, user 0m0.381s, sys 0m0.620s

• ...

• SIZEPOW=11, buffer size: 1024, best-case size: 1.3GiB
  real 0m1.005s, user 0m0.343s, sys 0m0.661s

• SIZEPOW=11, buffer size: 2048, best-case size: 2.3GiB
  real 0m1.008s, user 0m0.270s, sys 0m0.737s. (Smaller than 1x 4k page = bad)

• SIZEPOW=12, buffer size: 4096, best-case size: 3.6GiB
  real 0m1.012s, user 0m0.237s, sys 0m0.772s

• SIZEPOW=13, buffer size: 8192 (same as GNU yes), best-case size: 4.8GiB
  real 0m1.016s, user 0m0.180s, sys 0m0.834s

• SIZEPOW=14, buffer size: 16384, best-case size: 5.6GiB
  real 0m1.018s, user 0m0.090s, sys 0m0.926s

• SIZEPOW=15, buffer size: 32768, best-case size: 6.2GiB
  real 0m1.019s, user 0m0.057s, sys 0m0.959s

• SIZEPOW=16, buffer size: 64kiB, best-case size: 6.5GiB
  real 0m1.021s, user 0m0.023s, sys 0m0.993s

• SIZEPOW=17, buffer size: 128kiB (1/2 L2 cache size), best-case size: 6.6GiB
  real 0m1.021s, user 0m0.017s, sys 0m1.002s

• SIZEPOW=18, buffer size: 256kiB (= L2 cache size), best-case size: 6.6GiB
  real 0m1.020s, user 0m0.013s, sys 0m1.005s

• SIZEPOW=19, buffer size: 512kiB (2x L2 cache size), best-case size: 6.4GiB
  real 0m1.021s, user 0m0.000s, sys 0m1.019s (User time getting meaningless / too small for Linux to measure accurately.)

• SIZEPOW=20, buffer size: 1024kiB, best-case size: 6.2GiB

• SIZEPOW=21, buffer size: 2MiB, best-case size: 5.7GiB

• SIZEPOW=22, buffer size: 4MiB (1/2 L3 size), best-case size: 5.0GiB

• SIZEPOW=23, buffer size: 8MiB (L3 cache size), best-case size: 4.9GiB

• SIZEPOW=24, buffer size: 16MiB (2x L3 cache size), best-case size: 4.9GiB

• SIZEPOW=25, buffer size: 32MiB, best-case size: 4.8GiB

• ...

• SIZEPOW=28, buffer size: 256MiB, best-case size: 4.4GiB

GNU coreutils 8.31 yes: buffer size 8192, best case size: 4.7GiB

(vs. 4.8GiB for my 8k buffer version. Perhaps because of lower startup overhead. My statically linked executable makes literally no system calls before write, just a BSS pagefault or two, vs. GNU yes being dynamically has more overhead before it gets going. And not quite as tight a loop around syscall, probably involving indirect-call/ret into libc's write wrapper, so at least two different pages of code in user-space are touched between system calls. Two chances for iTLB or i-cache misses. (Making a system call tends to invalidate a lot, especially with Spectre / Meltdown / MDS mitigations enabled, but even without that if a lot of kernel code runs)

GNU yes's buffer is 64-byte aligned (cache line) but not 4k-page aligned. IDK if that makes any difference or leads to more dTLB misses (from spanning 3 pages instead of 2). Being an odd multiple of 64 bytes (address ending in 0x440) is not ideal for the L2 spatial prefetcher (which tries to complete 128B-aligned pairs of lines) but that's probably insignificant; 8kiB is small enough that we get lots of L1d hits and very few L2 misses overall, including both user and kernel space. (perf stat -d)

The fall-off at the high end of size is I think due to cache and TLB misses. You can run perf stat -d instead of time to see LLC-misses. (And LLC-loads is an indication of L2 load misses. Indeed, small buffers get mostly L2 hits, larger buffers get some misses.)

Note that the time real/user/system times are for the timeout process itself, not for just the yes workload. And that Linux's time accounting is somewhat granular, I think. perf stat gives more details, but I didn't want even the tiny overhead of the occasional HW performance-counter event interrupt.

---

Further speedup ideas:

Spawning multiple threads (all writing with O_APPEND) might be a minor win, depending on how much they serialize each other when appending. (I'm hoping they just reserve space and then copy, so a 2nd call can reserve more space while an earlier one is still copying. Otherwise we might need vmsplice + splice(2) or something to do the page-dirtying in user-space and give pages to the kernel without further copying (SPLICE_F_GIFT + SPLICE_F_MOVE)). But making a clone system call would probably take significantly more code.

Intel desktop CPUs can nearly saturate their memory bandwidth with a single core, unlike many-core Xeons with higher memory / uncore latency; ironically/paradoxically worse single-core memory bandwidth despite more memory controller channels for higher aggregate bandwidth than dual/quad-core client chips. With significant time spent in the kernel not bottlenecked on DRAM bandwidth, multiple threads could still help.

Using writev(2) to pass the same buffer multiple times with one system call could give the best of both worlds: small buffer for L1 / L2 hits while copying to the pagecache, but lots of work done per syscall. Maybe a few % speedup; (Tried it; got a 7.0G output with 20 io vecs for an 8kiB buffer, up from 6.6G. Kernel CPU time is now 49.5% clear_page_erms, 13.2% copy_user_enhanced_fast_string. So yes, less time spent copying, more time spent just clearing. 37 bytes, up from 29, score 26.3. Source on Try it online!).

As expected it doesn't come close to paying for itself in user-space code size to create the array of ptr,length pairs, although it was possible with a loop around 2 push instructions (4 bytes), but extra instructions outside the loop to get the args into place were necessary. Also, the call number __NR_writev is 20 so I used an array of 20 iovs, allowing the same trick as with fd = __NR_write to save a byte vs. lea.

There's still overhead per iovec (200x 2k buffer is slower than 20x 8k buffer). The sweet spot is around 4k or 8k buffers, with very minor gains for using a big vector (20x 8k seems enough). IOV_MAX is "only" 1024, and isn't slower but is barely faster. (Try it online! - flexible iov size version for perf experiments also needs only a couple changes to flip back to plain write instead of writev.

Answer 4

C (clang), 88 63 bytes, 2.5GB/s

b[2048];main(){for(wmemset(b,'\ny\ny',2048);write(1,b,8192););}

Try it online! Edit: Saved 25 bytes thanks to @ceilingcat by assuming 4-byte wide characters.

Answer 5

Bash, 16 bytes, 16TB output, score ~0 .0018554687

Thoroughly abuses the rules

trap '' TERM
yes

It ignores timeout's SIGTERM (running an empty command) and so continues beyond the 1 second that the benchmark script intended to set. This will fill your disk unless you kill it with a different signal or set a quota or other size limit.

Answer 6

Perl 5 (cperl), 26 bytes

while(1){print"y\n"x 9**4}

Try it online!

R, 18 bytes

repeat{cat('y\n')}

Try it online!

Improved thanks to @JDL

Squirrel, 24 bytes

while(1){::print("y\n")}

Try it online!

JavaScript (Node.js), 26 bytes

while(1){console.log('y')}

Try it online!

Python 3, 28 bytes

while1:print(end='y\n'*9**4)

Try it online!

Julia 1.0, 27 bytes

while(1==1) println('y')end

Try it online!

WHILE Programming Language

Performant but not participating because of many bytes...

You can't try it online! Sorry:) But here are Docs,doc and a java-based IDE

Answer 7

C (gcc), 67 bytes

b[1<<16];main(){for(wmemset(b,'\ny\ny',1<<16);~write(1,b,1<<18););}

Your times may vary. I'm running this inside a VM on a weak computer.

• b[1<<16]; is an integer array of \$2^{18}\$ bytes.
• wmemset(b,'\ny\ny',1<<16); sets that array to a pattern of y\ny\n. The characters are reversed due to the endianness of the x86 platform.
• ~write(1,b,1<<18) writes that array over and over until the write fails. (The ~ makes a -1 error return -> false; without it we iterate until the process is killed, saving 1 byte.)

May be faster on other systems if I increase the buffer size to 1 megabyte but there's no noticeable difference on mine. This really should be an average.

Try it online!

Answer 8

x86 machine code - 21 15 bytes, score : 175119.036

Using write() syscall to print y\n

This is a NASM listing (y.asm) :

6  00000000 6668790A                    push word 0x0a79
7  00000004 43                          inc ebx
8  00000005 89E1                        mov ecx, esp
9  00000007 B202                        mov dl, 2
10                                  .loop:
11 00000009 B004                        mov al, 4
12 0000000B CD80                        int 0x80
13 0000000D EBFA                        jmp .loop

Using score.sh to get a score (./score.sh y "./y"), score are : 175119.036

Answer 9

brainfuck, 30*971956224/621731~46899.2

>+[>+[<]>->+]++++++++++<[.>.<]

Try it online!

The BF JIT that I'm using prints each character in a separate syscall. An implementation that coalesces multiple . commands into one syscall would likely perform better.

Thanks to the list of BF constants.

Answer 10

Rust, 49 48 bytes \$\times\,\frac{32186368}{744521728}\approx2.075\$

Plain Rust, compiled with -C target-cpu=native -C opt-level=3. Clearly not the winner, only for reference; not bad, btw :)

fn main(){loop{print!("{}","y\n".repeat(8192))}}

-1 byte thanks to Anders Kaseorg

Try it online!

Answer 11

Python 3, 34 bytes, 1.9GB/s, score \$\le\$ 31.507

a='y\n'*2**17
while 1:print(end=a)

Try it online!

Answer 12

Jyxal 0ea7043bf37cd78106cde8f664e452f87286673b, ~31.551 on my machine

{9999`y\n`*₴}

Timed using an aging laptop with an Intel Core i5 4th gen, 8 GB ram, using WSL. It uses Vyxal's codepage, so I modified score.sh to use the -m flag instead of -c. Jyxal is a flavor of Vyxal designed for maximum speed. Unfortunately, I could not apply my push-pop optimizations in this case that really make Jyxal fast. Also for some weird reason multiplying the string inside the loop seems to be faster than outside...

{9999`y\n`*₴} # Ze program
{           } # An infinite loop
     `y\n`    # The string "y\n"
 9999     *   # Repeated 9999 times...
           ₴  # Printed without a newline

How to run

Jyxal isn't exactly released yet, you'd have to built it yourself. Clone the repo at commit 0ea7043bf37cd78106cde8f664e452f87286673b and then run ./gradlew shadowJar. You will find the compiled compiler in /build/libs/. Then create a file with the Jyxal program, and compile it with java -jar Jyxal-1.0-SNAPSHOT-all.jar yourProgram.txt. The run the compiled program using java -jar yourProgram.jar. All Java-related steps require Java 17 or higher.

Answer 13

Japt, 6 bytes

No clue how the scoring in this challenge works.

@Opy}a

Try it online!

@          :Function
 Opy       :  Print "y"
    }      :End function
     a     :Call repeatedly until it returns a truthy value
           :(Japt's O.p() method returns undefined)

Answer 14

x86-32 Linux, 26 bytes (ungolfed), 1.5M

write syscall test. Produces a very underwhelming result.

main:
    push    $0x0A79     # "y\n"
    mov     $1, %ebx    # write to stdout (fd=1)
    mov     %esp, %ecx  # use chars on stack
    mov     $2, %edx    # write 2 chars

loop:
    mov     $4, %eax    # sys_write call number 
    int     $0x80
    jmp     loop

Answer 15

Python 3, 18 bytes \$\times\frac{16834568}{622668}\approx486.65\$

while 1:print('y')

Try it online!

Answer 16

05AB1E (legacy) / 05AB1E, 4 bytes, score: waiting for OP

['y,

Or alternatively:

'y[=

Try it online.

Not sure which combination is the shortest, so for now this answer has four possible variations:

• 05AB1E (legacy) with program ['y,
• 05AB1E (legacy) with program 'y[=
• 05AB1E with program ['y,
• 05AB1E with program 'y[=

The 05AB1E (legacy) version is compiled and run in Python 3, and the 05AB1E version is compiled and run in Elixir. Based on performance on TIO for most challenges I did, I assume the legacy version will score much better.

I will leave just one of these four combinations with the largest output after OP's local test. The links provided contain instructions on how to install and run both 05AB1E and 05AB1E (legacy) locally.

Explanation:

[     # Loop indefinitely:
 'y  '#  Push string "y"
   ,  #  Pop and output it with trailing newline

'y   '# Push string "y"
  [   # Loop indefinitely:
   =  #  Output with trailing newline (without popping)

Answer 17

Pyth, 10 bytes \$\times\frac{1894125568}{1599025152}\approx11.846\$

#p*^9 5"y

Explanation:

#           :  Loop till error
   ^9 5     :  Evaluates to 9 ^ 5 (59049)
  *    "y\n :  Concatenates "y\n" to itself 59049 times
 p          :  Print without trailing newline

Try it online!

Answer 18

GFortran, 24 bytes, score: 49.179

yes1.f90   Try it online

do;print*,'y';enddo
end

Might be faster to use FPUT??, for 52 bytes:
yes2.f90   Try it online

do;call fput('y');call fput(new_line(''));enddo
end

Run the code

//Compile
$ gfortran -std=gnu -Wextra -Wall -pedantic -ffree-form -fcheck=all -fbacktrace yes1.f90 -o yes1.a
$ gfortran -std=gnu -Wextra -Wall -pedantic -ffree-form -fcheck=all -fbacktrace yes2.f90 -o yes2.a

//Run the test
$ timeout 1s yes > out0
$ timeout 1s yes1.a > out1
$ timeout 1s yes2.a > out2

//File sizes
-rw-r--r--  1  staff  29306880  6 Mar 18:43 yes.out
-rw-r--r--  1  staff        24  6 Mar 18:57 yes1.f90
-rw-r--r--  1  staff  14302020  6 Mar 18:51 yes1.out
-rw-r--r--  1  staff        52  6 Mar 18:57 yes2.f90
-rw-r--r--  1  staff  18071552  6 Mar 18:39 yes2.out

//Scores
$ bc<<<"scale=3;24*29306880/14302020"
49.179
$ bc<<<"scale=3;52*29306880/18071552"
84.329

My system (inferior to the OP):

$ neofetch --off
OS: macOS 11.2 20D64 x86_64 
Host: MacBookPro13,2 
Kernel: 20.3.0 
CPU: Intel i5-6267U (4) @ 2.90GHz 
GPU: Intel Iris Graphics 550 
Memory: 5500MiB / 8192MiB 

Answer 19

C (clang), ⁵⁷ 54 bytes \$\times\frac{44152832}{45940736}\approx51.8984\$

Saved 3 bytes thanks to @S.S.Anne!!!

#define p putchar_unlocked
main(){for(;;p(10))p('y');}

Try it online!

This is on my ancient tablet, probability better on my laptop that's far away right now - on holiday! :))))