unsolved
Veteran
This is true for most searching programs, such as chess, as there is a diminishing return on each additional core thrown at the problem.
However, the cube has 6 faces, each of which may be rotated 0 degrees, 90 degrees, 180, or 270. This gives a total of 24 possible orientations to start from as the cube is attempted to be solved. I can replicate all of my data structures in RAM with simply a different cube orientation, and I am essentially attacking the problem with a potential 24 times increase in speed. I can spawn up to this many threads in my move generation code.
I did test my move generator out on a Dual E5-2697v2 at the office (24 physical cores) and I got in some trouble
I also shot up from 500 million nodes/second (old matrix code on a slower system) to 14,200,000,000 nodes/second (new bitboard move generator with optimized code, one line of code to generate slice moves!) That was a little more than a factor of 28.But this incredible speed is worthless unless I figure out how to use a corner-pruning table (and other tricks) to reduce the size of the game tree. When I do finally get it, though, this thing will be awesome!
I think you already know the answer. I created separate indexing functions for each "turn" of the cube.
One indexing function returns the numbers 1 to 36 when fed in any position that is 1 turn away from being solved.
So, all I have to write to disk (and read into memory) is the distance to the solution. One byte.
Next, I wrote an indexing function to convert every cube position that is 2 turns away from a solution into numbers from 1 to 1026.
Again, I write the distance to the solution that many bytes into the file, and read that far into the RAM buffer.
3 turns = 28,836 positions, 4 turns = 810,891 ... 7 turns = 18,032,462,352.
It is tricky and can return ambiguous data if not called in the proper hierarchy, otherwise I would not need a program to solve the cube, the indexing function would know the answer.
The current techniques also breakdown for > 7 turns. I just don't understand enough about the cube yet. This will come with time and experience.
Every position that is hit in the database has been solved optimally through brute force using my huge, bloated game tree. I posted all 16 solutions for the 1-unsolved-center vs. 1-unsolved-center for U and F in an earlier post, and the consensus was that these were all optimal 8-ply solutions. So, when I encounter a leaf node that has a known distance-from-solved, I know from that point forward there is a solution in "depth + database solve length" or better. The "or better" depends on whether a faster solution exists outside of the pre-solved database, or if a quicker solution can be encountered in the database with additional searching.
Once there is 2 consecutive iterative depths of saturation, meaning all pre-computed solutions have been encountered and there has not been a decrease in the solution length, the position has been solved and no additional nominal depth will change that.
Nobody really has seemed too interested to post examples of that which will help me, though I have offered just about everything I have. Remember my project is only a couple of weeks old, and clearly in the basement as far as solvers go. I have made progress though.
I finally had time to look around and I saw the search for the 3x3x3 positions of distance 20. Now that I find interesting
By the way, one of our 16-core servers is finishing up a calculation either on the 14th or the 15th. As far as I can tell, it's coming back into our office with "nothing to do."
If this is the case, I can set you up with a logon id if you want to run any calculations. I think it is 16 cores x 3.1 GHz with a turboboost @ 3.4 GHz. Let me know if you are interested.
Last edited by a moderator:
