Skip to content

Conversation

@eightbitraptor
Copy link
Contributor

This PR rebuilds the knucleotide Ractor benchmark to use Ractors internally, rather than doing the internal work sequentially and running the whole workload in multiple Ractors using the Ractor harness.

This makes it directly comparable to the process-based implementation, so we can measure the forking approach directly against the Ractor approach, instead of measuring ractor overhead on a single threaded workload, which we have other benchmarks to do.

The old benchmarks-ractor/knucleotide has been removed.

To support this properly, we've rethought how benchmark categories work:

All benchmarks have been consolidated back into the single benchmarks directory and benchmarks-ractor has been removed.

Benchmarks that were previously in the benchmarks-ractor directory no have ractor_only: true in benchmarks.yml and the ractor_only category will run only these benchmarks.

Additionally, the new key default_harness has been introduced into benchmarks.yml. This lets individual benchmarks specify their own harness, independent of category. This has been done to facilitate running benchmarks like the new knucleotide-ractor introduced in this commit - which needs to run when --category=ractor is specified, but should use the default harness, unlike other ractor category benchmarks, which generally require the ractor harness.

The category filtering now works as follows:

  • No category: Runs all benchmarks except those with ractor_only: true. Uses each benchmark's default_harness, falling back to the default harness.
  • --category=ractor: Runs benchmarks with ractor: true or ractor_only: true. Uses each benchmark's default_harness, falling back to harness-ractor.
  • --category=ractor-only: Runs only benchmarks with ractor_only: true. Uses each benchmark's default_harness, falling back to harness-ractor.

The previous ractor knucleotide benchmark ran the whole benchmark in
parallel inside multiple ractors.

This is a good test that the benchmark can be parallelised but isn't
directly comparable to the original Knucleotide implementation which
uses processes to partition the work done by the benchmark itself.

This implementation uses ractors to parallelise the work in the same way
that the original uses Process.fork so it's more directly comparable.

This needs to be run with the regular benchmark harness instead of the
ractor harness, otherwise the ractor harness will attempt to wrap this
benchmark run in multiple ractors too.
I don't think there is value in keeping this around now that we have
a Ractor enabled version that has feature parity with the old Process
based one
For benchmarks like the knucleotide ractor benchmark, which use Ractors
internally so need to be included in the ractor benchmarks, but which
must not use the ractor harness

New category selection is as follows:

  - No category: Runs all benchmarks except those with `ractor_only: true`. Uses each benchmark's `default_harness`, falling back to the `default` harness.
  - `--category=ractor`: Runs benchmarks with ractor: true or `ractor_only: true`. Uses each benchmark's `default_harness`, falling back to `harness-ractor`.
  - `--category=ractor-only`: Runs only benchmarks with `ractor_only: true`. Uses each benchmark's `default_harness`, falling back to `harness-ractor`.
@eightbitraptor eightbitraptor force-pushed the mvh-knuecleotide-refactor branch from b4f216d to 06d34e7 Compare December 3, 2025 22:36
The API has changed between 3.4.7 and HEAD. Until 4.0 is realeased we
shouldn't test 3.4.7
@eightbitraptor eightbitraptor force-pushed the mvh-knuecleotide-refactor branch from 5fd05ad to dc13f62 Compare December 4, 2025 11:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants