Stream: show and tell

Topic: roc-regex

Karl (Sep 07 2026 at 22:10):

roc-regex does what you'd expect. It's very fast.

Karl (Sep 07 2026 at 22:13):

It pre-compiles the patterns at build time as a side product of Roc's constant folding, which I think is neat. I also tried to get it to beat the fastest HTTP parser+route matcher combo I know about, which was useful for finding startup overhead, but it's about 5 times slower. There just aren't enough bytes in a HTTP request for the higher speed matching to beat out the startup overhead for a highly tuned domain.

Karl (Sep 07 2026 at 22:17):

As a warning, these numbers are using my patched local Roc compiler so getting full performance for the scan heavy benchmarks will require this issue to be solved. These are also being run on a machine with 128bit SIMD vectors and Rust can take advantage of 256bit vectors while this cannot.

There's a comparatively hefty amount of overhead in these numbers from using checked array access so if those get elided it'll go faster. The two-word match at 1.33x and the multi-literal scan at 1.13x are the most direct apples to apples Roc vs Rust comparisons.

Richard Feldman (Sep 08 2026 at 01:35):

woooooow, super impressive!!!

Richard Feldman (Sep 08 2026 at 01:36):

I landed a fix for that issue btw - lmk if you can still get this perf on the new main!

Richard Feldman (Sep 08 2026 at 01:36):

this is really exciting stuff, @Karl! :smiley:

Karl (Sep 08 2026 at 04:15):

Things mostly hold up but I'm seeing a ~25% regression in the sparse literal row (Moriarty) which is the most directly affected by SIMD. If things were just not working then I'd see a regression across the other scanner rows but those numbers are stable. Looking into it.

Karl (Sep 08 2026 at 04:19):

Only shows up in the full benchmark binary, not in isolation so the fix you landed is working fine. I'll be reporting bugs related to the regex code over the next few days as I get them isolated with repros.

Claude says: "It is loop alignment. The code did not change at all. This is not a SIMD regression and not a codegen-quality regression. It is the alignment sibling of the register-pressure effect your notes already describe, where an unrelated edit moves a row that never runs the changed code."

"There is a genuine upstream item in this. LLVM can align loop headers, and Roc is evidently not asking it to."

I'll do another pass at slimming down the core of the matcher regardless but that's the current state of things.

TeaDrinkingProgrammer (Sep 08 2026 at 05:08):

I have a hobby project writing a regular expression language in Roc, so this will be usefull reference material :eyes:. Great work!

Krzysztof Skowronek (Sep 08 2026 at 14:36):

https://github.com/ieviev/resharp-dotnet

Have you heard about this? It was faster than rust in many cases (dotnet simd got really good in dotnet 10)

https://iev.ee/blog/resharp-how-we-built-the-fastest-regex-in-fsharp/ very nice article about the details and what it does well

The part about (a|ab)+ vs (ab|a)+ in a string like aababaabab is very interesting

Karl (Sep 08 2026 at 14:37):

This uses their algorithm.

Krzysztof Skowronek (Sep 08 2026 at 14:38):

Awesome!

Krzysztof Skowronek (Sep 08 2026 at 14:43):

I also have a noob question - why is roc not able to use the bigger simd vectors? Is it just for now or is it some fundamental issue?

Karl (Sep 08 2026 at 14:45):

Library support. Roc only implements the 128 bit SIMD set which has broad hardware support while 256 bit is more limited and Richard is worried about long term support/complexity.

Anton (Sep 08 2026 at 14:49):

I believe the 256 bit worry was mainly about different behavior on different devices.

Richard Feldman (Sep 08 2026 at 16:27):

that was a different thing

Richard Feldman (Sep 08 2026 at 16:27):

there are certain instructions we just have to be careful not to use (they're really niche though, fortunately) because they give different answers for the same inputs depending on whether you're using aarch64 vs x86-64 vs wasm

Richard Feldman (Sep 08 2026 at 16:33):

the 256-bit thing is basically:

• right now we have a pretty simple target system of like "build for 64-bit ARM Linux" - we don't get into the nitty-gritty of which CPU features you want to have, which I think is appropriate; nobody is like "I have installed Java for ARM64 machines that support 256-bit SIMD" :sweat_smile:
• if we enable 256-bit SIMD instructions, and someone makes a binary with them that works on their machine, and they publish it, other people who try to run it on machines that don't have that instruction are likely to just see that same Roc program abort with illegal instruction - so, likely no error message unless the host happens to be handling that. So, an extremely bad UX.
• in theory Roc's compiler could emit two code paths, one for machines that have 256-bit instructions and another for machines that don't (which falls back to 128-bit) and then at runtime we select between the two and cache the answer...but this is very difficult to do in the general case as an optimization you can rely on but which doesn't blow up your binary size and/or slow down your Roc program overall compared to if we just did 128-bit SIMD

so for now, 128-bit it is :smile:

Karl (Sep 12 2026 at 03:37):

Karl said:

I'll do another pass at slimming down the core of the matcher regardless but that's the current state of things.

I cleaned up the code today (the original quality was...not good, this is readable to me) and added another optimization for leading x+ patterns which is a bit golfing for my benchmark set but I think is reasonably general.

Last updated: Sep 24 2026 at 15:59 UTC