GeneSearch

Yes. Just plant clones in order from top to bottom.

This is just to help if you have clones in a container: Assuming you input the clone list in row order (ie: the first 6 clones are the first row, the next 6 are the 2nd row, etc.) you can quickly locate the clone in the container using this.

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.

The frontend/web site is. I'm still working on the core algo (written in Zig -> WASM) and plan to make a real site in the future. 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. There is maybe 1.5x perf increase at most in my limited testing outside of the browser; with web worker message dispatch there is probably some overhead as well.

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