I'm getting a compilation error with both gcc and clang-6.0: /usr/bin/ld: /tmp/ccidqhEW.o: in function 'f':\n ngn2.c:(.text+0x54): undefined reference to 'memset'\n collect2: error: ld returned 1 exit status. I'll look into this error, but as of now I can't score it.

I was also thinking about trying a RAMdisk for all I/O, just to see if that makes a difference. I doubt it'll make a huge difference, since reads and writes are sequential, and my SSD has a large enough cache to fit everything.

Of course, I'll try to get it done sometime today

@ngn i haven't revealed that only because I'm still working on it (and I got beat). I'm in the 3.5-4s range with Java, I have some quirks to work out, and then I'll attempt to migrate it to C++

Congratulations, you (and Arnauld) are in the lead by a lot right now.

Quite impressive for a general constraint solver. My first implementation was way slower than this. Running a benchmark right now, I'll update the post once it's done.

I guess my main goal with the challenge was to find the fastest way to solve a single sudoku. But since different sudokus have different solve times, this translated into getting the best average time for a set of hard sudokus, which correlates to the total solve time. I have my own solver, and I plan on making that parallel too, but there's hardly any need to use multiple threads to solve a single sudoku. I verified your solution, really nice implementation!

I might have to clear up the scoring. If you do anything in parallel, your score is still the sum of all individual solve times. You should calculate that sum and present it as your score. That way it's more about getting the code as fast as possible. The code can always parallelize across the 49151 puzzles, making that part trivial. I might change the scoring to be the total time of the program, and disallow multithreading. Or, perhaps multithreading should be a part of the challenge?