GeneSearch

Yes, sort of. This site and the WASM bundle are vibe-slopped from a C# codebase that I've developed the algo with. C# WASM was way too slow to work well in the browser (~20x increase in runtime) so to get a prototype out quickly I vibe-slopped a Zig impl based on the C# impl where it copied most of the tests/structure. I do plan to write my own Zig impl + web version once I get the algo sorted out. Sorry the site has that vibe slop aesthetic. I hate it too ¯\_(ツ)_/¯

TLDR: It's faster/better for a specific target (at least in most cases I've tried). The gen3 fixture is something that took me 45+ minutes to find a 2G4Y solution in rustbreeder on my 16-core workstation. This finds a better solution in 10 seconds on my phone.

rustbreeder does a limited simulation of breeding from the ground up, this does a targeted search for a specific gene combination.

rustbreeder is more like a brute-force evaluator. Actual brute force is not computable so it uses scoring to pick a limited subset of combinations for each generation, but each generation has the compute work known up-front which doesn't share mutable state and can be easily split across threads. This is great for getting a broad set of results where you can evaluate a number of different outcomes after the calculations are done without re-running the search.

This algo is essentially the opposite: given a specific gene combination it does a targeted search through the breeding tree, using various hueristics to prune branches. This lets it spend more time calculating for a specific outcome, and once a solution is found it can even more aggressively prune while searching for a better result. In my limited testing it gets better results (less generations/breeding needed) in less time. The downside being you need to recalculate if your target changes. It's also more complicated and difficult to work with the code. The rustbreeder impl is much easier to update if the mechanics of breeding change in Rust.

This impl is currently single threaded, but the gains from threading are much smaller: there is mutable state, and is essentially a DFS with lots of branching/pruning. In my limited testing with C# impl speedup is maybe 1.5-3x depending on the gene pool. Probably less gains to be had in browser due to worker messaging overhead.

You can bump it up but you will probably get diminishing returns. This just tunes the various budgets in the algorithm before it gives up on a branch (it's basically multiplier). You won't necessarily get 2x the compute time at 2 because some branches might prune before exhausting the budget. This is very much something that's in-progress and being tuned.

Not now, but I will release it in the future (probably agpl). It's embarassingly messy right now.