The 2 puzzles I posted here are classical Sudoku that dictates one and only one possible solution.

Certainly my solver is a general one, cracking any classical Sudoku problems. It can do exhaustive search to see if a problem has multiple solutions. It checks validity before search. I agree most what you said here. I said to a friend when discussing Sudoku: We all know that knowledge is power. But do you still need knowledge if you have power? :) Modern physics is trying to tell us that power and knowledge are the same thing. So, I picked power :)

It is still a simple brutal search program though I added some cutoffs to improve efficiency and also optimized it quite a bit. I don't see a need to go parallel for classical Sudoku at all. So, the numbers I mentioned here is coming from one core off an old laptop with i5-4200M. It is not a secret at all. It is a result of a hobby project. I will publish the code along a short descriptions of design considerations when I get the time. In fact, I did promise a friend of mine a short article about it months ago :)

Your worst case could be worse than the previous example which was my most time consuming problem. So, here is another one that took my program 0.00002s:

.........
.....1..2
..3.2..4.
....5..6.
.1.....2.
7..8.....
...7..3..
..2..6...
5.......7

I knew that was number I expected from your 80 lines :-\ My C/C++ program took about 0.0027s to crack it :)

try this one and report back:

.........
.......12
..3.45...
.........
..6...4..
.7.1.....
..82...7.
3.9.5....
4...6....

Here is the Code Project answer:-D: http://www.codeproject.com/cpp/Einstein.asp[^]

simple: suppose c is what you get from the stored proc and b is the boolean you want. just do this: b = c & 1; cast (c & 1) to bool if needed

I've no problem with VS2003 at all. The problem is I like the VS2005 C++ complier much better than the one on VS2003. It generates really fast code on one of my 32 bit tests.

Just tried to install MS Visual Studio 2005 beta2 on Windows XP x64 and failed badly. It seems to me VS2005 is not aware of XP x64 at all.:( Does anybody here have a trick to get around this?:) Thanks! -- modified at 9:51 Thursday 22nd September, 2005

This is an effect of L1 cache. You did not mention the CPU you were using. I assume it was a P4. The L1 access line size is 64 bytes if my memory serves me right. If there are no alignment issues(your compiler often does a good job at this), the smaller size the structure is the more effective for a single L1 line access. Nowadays, people often talk about structure of arrary (SoA), that address such issues....