[dmtrKovalenko]

I am not sure why this is built with -O3 I have tested it both on Neon and AVX endpoints and -O3 on gcc and clang actually gives a measurable impact

[ashvardanian]

Hi @dmtrKovalenko! Sorry for the delay on this one. Which exact functionality were you testing? Did you check the produced Assembly? Did you run internal throughput benchmarks or the StringWars ones?

[dmtrKovalenko]

Not really, I was testing it on my own benchmarks at https://github.com/dmtrKovalenko/fff.nvim

[ashvardanian]

Thanks for the nudge, @dmtrKovalenko — this isn't dormant, it's just turned out to be a bigger topic than the diff.

Status correction first: the Rust side no longer hardcodes -O2. Since 18a3acda, build.rs drops the flag and forwards Cargo's OPT_LEVEL, with [profile.release] opt-level = 2 in Cargo.toml as the pin — so this is already tunable from the outside, and this diff would reintroduce a hardcoded flag against current main. The open question is the default, not the mechanism.

Also worth recording: the original reason we pinned -O2 was that -O3 inflated the utf8_uncased TU to ~3 MB / ~44 s. That file has been split since — it now compiles to ~194 KB in ~4 s at -O3. The rationale no longer holds in that form.

I did a small ablation strudy. I measuring different kernels with -O2 and -O3, mostly with GCC and Clang, reproducing 40% variance depending on the input size. As expected -O3 tends to unroll my loops, resulting in larger binaries and sometimes worse performance on smaller inputs, but great results on typical microbenchmarks.

Let's keep this thread open until I understand better what to do about it 🤗