Recompia
Pokémon Pokopia를 Windows에서 직접 실행, 멀티플레이·모드·기능 향상 지원
저장소 정보는 아직 수집하지 않았습니다.
아직 감지된 업데이트가 없습니다. GitHub 릴리스가 나오면 여기에 보입니다.
메이커가 쓴 소개는 위의 한 줄이 전부입니다. 더 자세한 내용은 저장소 README에서 읽을 수 있습니다. 저장소 README ↗
README 전체를 불러오는 중입니다.
README 전문 보기 ↗Live demo: https://egg-solver.arhan.sh/
egg-solver is the fastest publically available optimal Rubik's Cube solver. This project was entirely generated by AI and was made possible under a few special conditions:
I created a 48 core AMD EPYC 9V45 virtual machine with 94 GiB and two 300GB data disks. I gave Claude Code's Opus 5.5 (xhigh) model full access over the virtual machine and asked it to autonomously create the solver. Over the course of five days, I used $2,400 in Claude Code credits and $400 in Microsoft Azure credits to build this solver.
egg-solver would not have been made possible without the following contributions to Rubik's Cube theory:
It is easy to believe that the AI was primarily responsible for making the solver this performant. This is untrue: the significant majority of Rubik's Cube solving techniques were developed and perfected by these individuals over many decades of research and experimentation. egg-solver is different from the other optimal solvers only in detail (in particular, a heavily optimized micro-threading implementation), not in broad strokes: we still use a meet-in-the-middle approach with a large in-memory pattern database.
The rest of this document, as well as the mentioned user guide, was entirely written using AI.
Requires Rust and Cargo. The release build targets the CPU it is built on.
cargo build --release --locked
mkdir -p tables
target/release/gen 0 auto tables/h0
# Optionally tune the lanes per thread for your machine
target/release/bench tables/h0 tune
printf '%s\n' "R U R' U' F2" | target/release/solve --table tables/h0
h0 is suitable for short examples. For arbitrary states, generate the largest
table that fits comfortably in RAM: h7 = 3.6 GiB, h8 = 7.3 GiB,
h10 = 29 GiB, h11 = 58 GiB. For example: gen 7 auto tables/h7.
# One cube, all selected threads:
target/release/solve --fast --table tables/h7 "R U R' U' F2"
# Batch: one scramble per line:
target/release/solve --table tables/h7 < scrambles.txt
# Check a table:
target/release/gen check tables/h7
-t N selects threads; -c 1 processes stdin one cube at a time;
--json emits JSON. --fast requires --table and one scramble from
arguments or stdin. Empty input is an error. --warmup SCRAMBLE is optional.
--load copy loads the table into private RAM before searching. With
--load map or shared memory, keep the backing storage unchanged while
running. See solve --help and the user guide.
How many times faster egg-solver is than each competitor (competitor time ÷ egg-solver time). Measured on a 48-core AMD EPYC 9V45 VM with tables resident in 1 GiB pages; table loading is excluded and each solver used its own table. Each competitor links to its study, with builds, commands and raw output.
| Competitor | Table GB: competitor / egg-solver | Workload | 1 thread | 48 threads |
|---|---|---|---|---|
| nissy-core H48 | equal, h6 to h10 | 500 states as one batch | — | 7.10–10.09× |
| nissy-core H48 | 60.67 / 62.26 (h11) | one cube at a time | 10.4× | 31.4× |
| cube48opt10 | 31.13 / 31.13 (h10) | one cube at a time | 5.4× | 20.3× |
| cubeopt30 | 2.60 / 3.89 (h7) | one cube at a time | 10.1× | 13.8× |
| nxopt22 | 7.81 / 7.78 (h8) | batch | 21.3× | 18.0× |
| nxopt EO3/EP2 | 62.47 / 62.26 (h11) | batch | 17.1× | 13.7×* |
| vcube208 | 7.81 / 7.78 (h8) | batch | 14.2× | 12.3× |
| cube48opt-rust Opt8 | 7.78 / 7.78 (h8) | batch | 3.9× | 3.2× |
*nxopt reports summed cube durations ÷ workers ÷ cubes; egg-solver's figure is batch wall time ÷ cubes.
Documentation · Browser setup · GitHub Pages deployment · Development scripts