aboutsummaryrefslogtreecommitdiff
path: root/src/cubetypes.h (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Added -c option for solveSebastiano Tronto2021-12-241-0/+1
|
* Added the possibility to compress tables to 2 bits per entry.Sebastiano Tronto2021-12-231-0/+5
| | | | | | | | | | | | This is done similarly to nxopt: one base value is selected and entries are memorized based on that base value. Values higher than base+3 are returned as base+3 (still a valid estimate) and values lower or equal to base require a lookup on a "fallback" table, which must give a valid estimate for the larger one (e.g. nxopt31 or khuge can fallback to drud_sym16). I have also added some info to the pruning table files: base value and distribution. Unfortunately this means that everyone who has used nissy 2.0beta has to re-generate the tables.
* Added a new pruning table (equivalent to nxopt31). I have not tested it yet, ↵Sebastiano Tronto2021-12-161-9/+14
| | | | | | | it takes a while to generate. Plus I have done a whole lot of refactoring in random places because I cannot focus on one thing at the time.
* Faster optimal solver.Sebastiano Tronto2021-12-131-18/+14
| | | | | | | | | | | This is a pretty big one, but unfortunately performance only improved by about 5%. I implemented one of the main ideas of nxopt, that is switching to the inverse scramble on the fly if it gives a lower branching factor. On the one hand it makes sense that it does not have such a huge impact, since it only rarely happens that we do have a lower branching factor on inverse, but on the other hand I am quite sad that the improvement is barely noticeable :-( Maybe the problem is that I have introduced a lot of new overhead and I can improve that in the future. Or maybe I am just overlooking something stupid.
* Multi-threaded pruning table generation - now it's actually fast :)Sebastiano Tronto2021-12-091-2/+3
|
* Just refortmatting and added one typeSebastiano Tronto2021-12-081-149/+162
|
* tiny cleanupSebastiano Tronto2021-12-081-1/+1
|
* Faster and nice pruning table generation. Can still be improved with ↵Sebastiano Tronto2021-12-081-2/+2
| | | | multithreading.
* Little performance improvement in optimal solver - more to come!Sebastiano Tronto2021-12-071-9/+27
|
* Fixed typo in commentSebastiano Tronto2021-12-061-1/+1
|
* Multithreading seems to be working now, it was easier than expected!Sebastiano Tronto2021-11-201-105/+126
|
* Use inttypes.h macros to print uint64_t variables (this requires -std=c99). ↵Sebastiano Tronto2021-11-171-1/+1
| | | | Added a couple of TODOs
* Load all necessary pruning tables for a step before the actual solving processSebastiano Tronto2021-11-151-0/+2
| | | | | starts. This is in preparation for multi-threaded solving (but don't get hyped, it will take time).
* I tried to remove the dependence on antindex in order to get rid of themSebastiano Tronto2021-11-121-0/+1
| | | | | | | once and for all. I successfully removed from the pruning table generation part by using an alternative (slower) method, but then I realized that I also use antindexes when generating symmetry data. So I reverted to the original pruning table computation method, but I left the alternative way there, commented.
* Rewritten from scratch. Welocme nissy 2.0!Sebastiano Tronto2021-11-111-0/+286

Generated with cgit - Back to sebastiano.tronto.net