v: pin compiler to V 0.5.1 (from source); keep vanilla_io_uring but skip it in CI

[enghitalo]

Two changes to the v benchmark for reproducible, passing CI.

1. Pin the V compiler to V 0.5.1, built from source

The Dockerfile previously cloned moving master. Pin it so builds are reproducible:

• Pinned to the 0.5.1 tag (not a master commit) because post-0.5.1 master carries a large codegen regression — single-element array push (arr << x) is 4-7× slower (vlang/v#27468; it also explains the x.json2 regression #27467), which slows every V program including these benchmarks.
• Plain make can't build an old tag: its latest_vc step git pulls the newest vlang/vc bootstrap, which no longer matches 0.5.1's vlib (fails with unknown ident \native`). So the build pins vc to the commit cut for 0.5.1 (vlang/vc@f461dfeb = "[v:master] 0c3183c - V 0.5.1") and runs make's own bootstrap recipe (cc -> v1 -> v2 -> v`).

Bump the tag (and the matching vc commit) to update the compiler.

2. Keep vanilla_io_uring, but skip it in CI (don't delete it)

Per @waghanza's suggestion — keep the codebase and skip it during matrix creation rather than removing the framework.

io_uring can't be exercised in this CI: io_uring_setup/io_uring_enter are blocked by Docker's default seccomp profile on the GitHub Actions runners, so the server builds but never becomes HTTP-ready (it can't pass the smoke test). So the framework is kept in the tree and skipped with a single line in .tasks/ci.rake:

next if language == 'v' && framework == 'vanilla_io_uring'

Remove that line once io_uring is allowed under the CI sandbox (e.g. a uniform custom seccomp profile applied to all frameworks). vanilla_epoll is unaffected, and the io_uring engine continues to be benchmarked in HttpArena, whose harness permits io_uring. See #9467 for the root cause.

[waghanza]

So you'll maintain v @enghitalo ? I mean you'll create a PR on each update to make sure version expsed (in confi.yaml) in the same that the sha here ?

PS : Do not merge, I prefer to do it, since I have results update running on my machine

[enghitalo]

I'm going to leave this version here as a permanent fix (instead of main branch) because V is undergoing a major refactoring, although it's quite stable. Whenever there's a change in Vanilla or V that requires updates, I'll update it here.

[enghitalo]

The CI failure was vanilla_io_uring only — it builds fine but io_uring_setup/io_uring_enter are blocked by Docker's default seccomp on the GHA runners, so it never becomes HTTP-ready. vanilla_epoll, pico, veb and fasthttp all pass with this V pin.

Excluded vanilla_io_uring from the CI matrix via a new generic framework.skip_ci flag (it still runs in the real benchmark). Root cause + a fair way to re-enable io_uring in CI (one custom seccomp profile applied uniformly to all frameworks) are tracked in #9467.

[enghitalo]

Update: instead of the per-framework CI skip, I just removed the vanilla_io_uring framework (force-pushed). Carrying a framework that can't pass the CI smoke-test isn't worth it; vanilla_epoll stays and io_uring keeps being benchmarked in HttpArena. #9467 updated accordingly (root cause + the fair way to add io_uring here later if wanted).

[waghanza]

Maybe @enghitalo , you can keep the code base ;-) and skip it on matrix creation in here

web-frameworks/.tasks/ci.rake

Line 25 in dcbf2bf

next unless File.exist?(file)

so as you can remove this skipe when io_uring will be enabled on docker

[enghitalo]

Maybe @enghitalo , you can keep the code base ;-) and skip it on matrix creation in here

web-frameworks/.tasks/ci.rake

Line 25 in dcbf2bf

next unless File.exist?(file)

so as you can remove this skipe when io_uring will be enabled on docker

done

[waghanza]

I mean you can re-add vanilla_io_uring source code 😛

Maybe it could be shown in results (since the results are made on an other type of workstation that github actions)

[enghitalo]

I mean you can re-add vanilla_io_uring source code 😛

Maybe it could be shown in results (since the results are made on an other type of workstation that github actions)

But does it run in the same Docker container?

[waghanza]

Nnot at all. It runs on latest stable docker version on latest fedora (44 as for now) @enghitalo

I'm not aware of all specs of githib actions docker info nor system below, but I'm quite sure that it is not a fedora with latest linux kernel

[waghanza]

btw, if it fails, it will not be included on results, so no inconvenients of having it here

[enghitalo]

Ok. Let's try