Hi, I have recently made (assisted with AI; sorry, this was the only way I can do this) a GPU solver that works on solving Eternity II that I will allow to be adapted into your project. Now, I don't know how to make WUs in BOINC currently, but seeing how GPUs are usually faster at doing calculations than CPUs, I have decided to make a GPU solver so that your search can be done WAAAAAAAY faster (and it's probably for the best because that puzzle has a lot of combinations and having CPU workers are going to be really slow, especially with the current amount of people on the project).

(I was originally considering keeping it for myself, but since the $2,000,000 prize was never going to be given out anymore since that deadline expired and I'm an accelerationist where I want everything solved fast so that there is less weight on everybody's shoulders and some extremely important work starts being worked on by multiple people, so it's probably for the best that I give this out...)

I even ran a few CPU units myself and definitely feel like it could be done way faster with GPUs.

Yes, the GPU version works with CUDA and OpenCL, meaning that NVidia and AMD cards and even Mac and Linux computers work with this (though, I suppose Windows and Linux is fine as it is since nobody uses Mac for these types of things). And it has x86-64 and ARM builds for Mac OS as well in case you still want to make a Mac version of the app.

Not only did I make a standalone GPU solver application similar to the one that I made for Diamond Dilemma's Gold Challenge, I also made a batch version that could integrate directly into your BOINC project and that is why I am contacting you here, to link you the files and work with you to make sure that the batch version works perfectly so that a lot of people use the GPU version as well. Also, I have a question: the current GPU app that I have repairs complete boards, but your CPU app uses a depth-first-search algorithm. I also don't have the source code for the CPU solver, so I don't know exactly how it needs to be converted. Would you prefer to have the GPU solver repair complete boards like the normal app but then the WUs are different than the CPU ones and aren't cross-compatible, or do you want the GPU solver to use depth-first-search on the board and be cross-compatible with the existing WUs (and probably finish them in a few minutes each compared to the over-an-hour standard on a 4th-gen Intel i7)?

The repository is here: https://github.com/gearashi/EternityIISolver

It is ENTIRELY open-source. You can adapt it how you want and change things if you need to. I will be making an announcement on my X account about this once it is launched (even though it is technically public anyways and the current code is up now).

Now, you might be wondering: "has an angel come from the heavens to give us a GPU solver for a BOINC project that less than 100 people are working on right now?" Yes, yes I did.

Yes, my writing is all over the place, but I don't have time to improve all this writing, so I'll just end it here.

Sincerely,
gearashi

Look at this as well regarding BOINC integration plans: https://github.com/gearashi/EternityIISolver/blob/main/docs/BOINC.md

Very interesting and thanks for sharing your work. The gpu question was brought up by a few people here. There is an article describing using GPU to solve eternity II: https://eternity2.dev/research/build/hardware/gpu-solving/ and several people in the past had built gpu apps and experimented with it as described in that write-up.

It will be good if you can share what cpu and gpu that you are using to do the testing. How much faster? I did a quick back of the envelope calculation, even if the gpu is 10x, 100x or 1000x faster than the cpu that you are using, a three order of magnitude speed improvement will still take longer time than the age of the earth to confidently solve the puzzle.

BOINC platform allows your own custom app build to be used within the boinc client. It is called anonymous platform as described here if you wish to test it within the BOINC ecosystem: https://github.com/BOINC/boinc/wiki/Anonymous-platform.

Hi pututu,

I am currently using an Intel i7-4790 and an Nvidia RTX 2060 6GB. Regarding the testing with the existing version of the app, that's a good question. The current version of the app caches the existing board records first so that it doesn't redo that board or has starting points, and it already made over 24,000,000 accepted moves running it for a few minutes on 8192 parallel searches. What does "moves" mean? Zero clue, but I guess it checks all of positions on the board and keeps record of one that reaches a higher score. It hasn't reached a number above 466 yet (because that is really tough to get and that's the starting point), but I assume with the app's maximum it could. I'll run it for a few hours and send back results. The GPU solver repairs complete boards while your CPU solver uses depth-first-search for WUs, and normally, those WUs take about an hour to two hours to finish each (but there would be like eight running at the same time, so it's like four WUs done per hour and that's on my CPU which is considered "old").

I bet if your team found a way to convert the existing CPU DFS units to GPU, they would take five minutes or less each WU and there would especially be more people using GPUs here to work on this project. Distributed.net did it with RC5-72 and Moo Wrapper (and that's still taking a while and will take years because there is a lot of old computers doing that instead of a full-on modern supercomputer or multiple of those).

32,768 parallel searches is the app’s current maximum and it saves the best possible board that it finds and tries to continue running until it hits the max 480/480 score, which if I found a higher board than 466 with the five hint pieces, I would tell you the exact board.

"even if the gpu is 10x, 100x or 1000x faster than the cpu that you are using, a three order of magnitude speed improvement will still take longer time than the age of the earth to confidently solve the puzzle"
Imagine multiple people using GPUs instead of CPUs working on this project then. It would be way faster (then again, still unrealistic).

This is basically a digital slot machine at this point hoping that I get a 480/480 out of luck. It runs at about 19M proposed moves per second on my end with the board repair system.

The last brute-force effort would be having a frontier AI that notices patterns and can solve things immediately just by seeing patterns solve the entire thing just by separating all of the pieces by colors, and types and just put the whole thing together. Same with the Diamond Dilemma with the Gold Challenge with all 180 triangular pieces with the gold path being one loop.

AI could only do math really good right now and some science and it can reverse-engineer code really really good right now. I would assume that a lot of these crazy difficult puzzles that have to be brute-forced normally will be defeated once AI gets really really good.

And one person has to know the solution and that's the puzzle maker themselves. The solution wasn't just made out of thin air. There had to be a lot of smart thinking involved on how every piece gets put together.

I wouldn't know how to really integrate this app into BOINC personally or how to test WUs, so that's why I made the code entirely open-source and freely available.

That is all. I'm letting it run for a bit right now.

Hi gearashi, thank you for sharing this, and for making it fully open source. That's generous. pututu already gave you good pointers, so a few points from the project side:

We tried hard to make it GPU-friendly. I spent months trying to make our solver work well on GPUs, and it simply doesn't fit this kind of computation. Our tasks run a depth-first backtracking search, the approach behind the best known Eternity II results, including our 466 with all 5 official clue pieces. Each step depends on the one before, the branches are unpredictable, and thousands of GPU threads end up waiting on each other. In our measurements, the GPU version was about 7,000 times slower than the CPU one. Board-repair searches (improving complete boards) do run very well on a GPU, but in our tests and in the published research they plateau well below what depth-first search reaches. Raw speed matters, but much less than cutting dead branches of the search tree as early as possible. A good early cut throws away billions of hopeless positions at once, and that's what saves years of computation. That is where most of our work goes, and why a high rate of moves per second doesn't by itself mean progress toward 467+.
BOINC integration. We can't ship an outside binary as a project app directly. Every result is checked against an exact, reproducible search, so a GPU app would need to reproduce the same work units exactly (same tickets, same node counts), or come with its own validation. Also note that the anonymous platform is disabled on this project: since every result counts toward the shared search, only our own validated builds can receive tasks, so the route pututu mentioned isn't available here.
A question. Yesterday a custom client that isn't ours connected to our live dashboard. For about half an hour it reported enormous node counts, around a thousand times what a real CPU thread does, but never returned a single result. It made a real mess of our public counters: the global node total, the throughput chart and the participant rankings were all inflated by numbers that matched no actual work. We had to block it and clean the counters by hand. Was that you testing your solver? No problem if it was, just let us know. Going forward, work has to come back as real, verifiable results; reported counters alone won't be credited.
Thanks again!

"A question. Yesterday a custom client that isn't ours connected to our live dashboard. For about half an hour it reported enormous node counts, around a thousand times what a real CPU thread does, but never returned a single result. It made a real mess of our public counters: the global node total, the throughput chart and the participant rankings were all inflated by numbers that matched no actual work. We had to block it and clean the counters by hand. Was that you testing your solver? No problem if it was, just let us know. Going forward, work has to come back as real, verifiable results; reported counters alone won't be credited."
I don't know if it is my GPU solver app doing that, but what it does first is cache boards from the existing library first so that when it searches for more boards, it doesn't repeat them and skips those results. I am about 10% of the way there with 12,176 boards out of 120,001 boards indexed as of this writing currently but it downloads one request per second. If that is me, I'm sorry. If there were a ZIP file where I could import all of the existing results to have it be cached, I think it won't strain your servers if it was doing that earlier yesterday.

I have made the GitHub repository private just in case to investigate why it was doing that yesterday and to have it not cause problems to your live dashboard.

I have research the code and from what I found, the GPU solver app didn't upload anything to the live dashboard. It was only downloading and caching the existing library boards. This is the exact chat log as stated:
"So far, our downloader only makes GET requests for the board index and individual boards. I haven’t found code that sends move counts or DFS node counts, so I can’t attribute their counter incident to this app yet. I’ve stopped our dashboard processes and am removing automatic downloads from the installed app as well as the source.

Did the team provide the offending request path, User-Agent, or an exact timestamp? Any of those would help distinguish our library downloads from a client reporting search counters.

The audit now covers both installed executables too. Their code matches the downloader we inspected, and I found no route that uploads node or move counts. The offline changes preserve your cached boards; I’m testing the rebuilt app before replacing the installed copies.

I found no code that uploads results, move counts, or node counts—including in both installed executables. The app contacted the project’s control-plane server only to GET /library/index and /library/board/<hash>. Its search counters were saved locally and displayed on 127.0.0.1.
That doesn’t explain the reported inflation, and I can’t rule out server-side behavior without their request logs. Your intended workflow is clear: obtain board files, then solve offline. The update removes all automatic project requests while keeping the downloaded cache usable.

I’ll add a manual export for the best validated board, with the score, piece IDs, rotations, and a readable layout. It will save locally and never upload. I’ll label it as a candidate for review; the project’s required submission format hasn’t been confirmed, so I won’t present it as a completed BOINC workunit."

And it's still working right now. So it might have not been me but somebody else. I'll test the new version of the app to make sure it doesn't pull the same thing, but it shouldn't be uploading anything to your live dashboard.

ACTUALLY, I just thought of something. I was originally just , but, I was running the BOINC CPU work units and was trying to reverse-engineer using GPT-6 Astra Ultra Codex how they ran and worked so they could be converted to GPU work and have the same exact format... but I guess that won't work really since you said CPU would be better for that anyways and GPU was slower.

So it could have been my reverse engineering work on the WUs because I was trying to figure out the format for it so I could convert it to GPU work, and I was running the actual GPU solver app for hours after that and it was just downloading the library files and wasn't uploading anything so it had to be that. Sorry for that.

*I was originally going to end the message there (I forgot to type the whole sentence)

So the problems involving the live dashboard yesterday were entirely related to pointless uploading and inflating work, right? Then it definitely wasn't my GPU solver app doing it, it was GPT-6 Astra when I tried to reverse-engineer how the WUs worked so I could make GPU versions of the exact work to work with the GPU solver. Either that, or it might have been somebody else screwing over the project for whatever reason.

Here are a few more parts of the GPT-6 Astra chatlog involving my tests:
"The recorded BOINC inspection commands show downloads, file copies, and static analysis; I haven’t found a command that launched the project’s solver. The official BOINC wrapper does contain progress-reporting code, but that alone doesn’t implicate our inspection. I’m also checking the historical requests for any direct counter submissions.

I found no evidence that the workunit inspection submitted counters: the 145 available pre-incident shell-command records contain no project-binary launch, POST/PUT, or progress-report invocation. The cause remains unconfirmed without the team’s server logs"

So it might have not been GPT-6 Astra checking the WU files and reverse engineering them. I ran the GPU online solver a bit earlier for a few minutes before it updated, so check your server logs to see if it still inflated the work when it's just supposed to download the library files currently.

I have made an offline version just in case that doesn't download from the board library or upload to anything and it allows you to export a best board locally in the same format as the library file.

So, yeah, idk.

"I checked that possibility. The available records don’t show the reverse engineering launching BOINC executables or submitting counters. They show downloads and static inspection. I also found no result-upload or counter-reporting code in our installed app. Identifying the actual cause still requires the project’s server logs."

It definitely wasn't me then.

I also didn't use the standalone launcher either. I was just checking the BOINC app and WU files with GPT-6 Astra, so I didn't use a modified version of your client.

In reply to benjamin's message of 9 Oct 2026:

Hi gearashi, thank you for sharing this, and for making it fully open source. That's generous. pututu already gave you good pointers, so a few points from the project side:

We tried hard to make it GPU-friendly. I spent months trying to make our solver work well on GPUs, and it simply doesn't fit this kind of computation. Our tasks run a depth-first backtracking search, the approach behind the best known Eternity II results, including our 466 with all 5 official clue pieces. Each step depends on the one before, the branches are unpredictable, and thousands of GPU threads end up waiting on each other. In our measurements, the GPU version was about 7,000 times slower than the CPU one. Board-repair searches (improving complete boards) do run very well on a GPU, but in our tests and in the published research they plateau well below what depth-first search reaches. Raw speed matters, but much less than cutting dead branches of the search tree as early as possible. A good early cut throws away billions of hopeless positions at once, and that's what saves years of computation. That is where most of our work goes, and why a high rate of moves per second doesn't by itself mean progress toward 467+.
BOINC integration. We can't ship an outside binary as a project app directly. Every result is checked against an exact, reproducible search, so a GPU app would need to reproduce the same work units exactly (same tickets, same node counts), or come with its own validation. Also note that the anonymous platform is disabled on this project: since every result counts toward the shared search, only our own validated builds can receive tasks, so the route pututu mentioned isn't available here.
A question. Yesterday a custom client that isn't ours connected to our live dashboard. For about half an hour it reported enormous node counts, around a thousand times what a real CPU thread does, but never returned a single result. It made a real mess of our public counters: the global node total, the throughput chart and the participant rankings were all inflated by numbers that matched no actual work. We had to block it and clean the counters by hand. Was that you testing your solver? No problem if it was, just let us know. Going forward, work has to come back as real, verifiable results; reported counters alone won't be credited.
Thanks again!

That explanation makes sense. Not every workload can benefit from the high parallelism a GPU can offer, esp if there are branches. If you browse other BOINC projects, the question of a GPU app is pretty much always brought up.

Thanks for checking so thoroughly, and no need to apologise: it wasn't you. The client in question identified itself under a different software name, came from a different machine, and only sent counters. Your downloader just reads the public board library, which is fine.

One request though: fetching all 120,000 boards one by one at one request per second is quite heavy for us, since every request has a hosting cost. Could you pause or slow down the bulk download for now? We'll look at offering the library as a single archive, which would be much better for both of us.

And no need to keep your repository private on our account.

The whole library is now available as a single file, rebuilt every day: https://stats.eternityathome.org/library/archive (gzip, one board per line).
Please use it instead of fetching boards one by one;
(Under construction; please wait an hour. Thank you.)

Just saw this. Downloaded it. Won't be downloading boards one-by-one anymore. Thanks. (._.)b