The New Sudoku Players' Forum

[champagne]

I am nearly ready to run my test with a first revised code

I use as test file the games results for the games 1/313.
This is a file of 32601 records.
To limit the file loads effect, each puzzle is checked N (N=100 here) times.
My first test was on my desk with about 12/13 cores active.
AMD Ryzen 7 7500G 3.8 GHz

The average answer is 6 microseconds per puzzle, slightly lower with the revised code.
I am waiting for a free worker (same computer) to compare both codes in single and multiple threads context

[Serg]

Hi, champagne!
I think you underestimate "load" effect. Solver should solve loaded puzzles 10000 times each, not 100 times.

Serg

[champagne]

Hi Serg,

As I wrote, I intend to run the same batch in parallel and for the test, I think that one hour is a good target.
This fits with your remark with the file of 36000 puzzles.

There is another point that I would like to test.
I am running usually batches with a core locked through the affinity parameter.

As far as I could see in a test done with my son, Linux do this automatically if you start a batch with a free core. I think that windows don't, causing significant overheads.
This is something to check as well.

[Serg]

Hi, champagne!

I am nearly ready to run my test with a first revised code

I use as test file the games results for the games 1/313.
This is a file of 32601 records.
To limit the file loads effect, each puzzle is checked N (N=100 here) times.
My first test was on my desk with about 12/13 cores active.
AMD Ryzen 7 7500G 3.8 GHz

The average answer is 6 microseconds per puzzle, slightly lower with the revised code.
I am waiting for a free worker (same computer) to compare both codes in single and multiple threads context

Could you compare those solvers performance with JCZSolver performance?

Serg

[champagne]

Could you compare those solvers performance with JCZSolver performance?

Serg

Normally, my DLL is very close to JCZ solver. I don't have it, but if I remember well, JCZSolver is the 32 bits version written by Jasonlion starting from my code.

[champagne]

The test worker is now free to start the tests.

All tests will be done on the same computer, AMD Ryzen 7 7500G 3.8 GHz
Nothing else than the test active.

The test will always be the same file of 32601 records of the pattern game, (games 1-313)
Each puzzle is loaded and the brute force is called 25000 times.

I made a first test to check the process and got

5.11 microsecodens per puzzle with my last code
5.39 microseconds per puzzle with the DLL.

I had still one onther core active in this test, so I'll do it again.

EDIT This code uses native intel instructions and is closer to an optimized X64 code, so it should be slightly better than JCZsolve on this computer

I start with both codes without the core lock to see what happens. results later to day for one batch active. Likely to-morrow with several cores active.

[champagne]

now the results of three tests on both versions of my brute force.

Code: Select all

One single batch active,
5.02 microseconds per puzzle with the new code
5.20 microsecodns with the DLL 3% higher

Code: Select all

running 8 consecutive threads in parallel,
1h 49mn 4-9 s  with the new code
1h 56mn 15-19swith the DLL
small differences, but same nearly same run time.

8.03 microseconds per puzzle with the fresh code
8.56 microseconds with the DLL

A siginificant, but expected increase

Code: Select all

I made a third test with 4 threads active on 4 cores, I got
5.37 microseconds per puzzle with the fresh code,
5.58 microseconds with the DLL

Much better return on the parallel processing.

I'll do more tests for my own use to find a reasonable limit in the number of batches to do in parallel with such programs

[champagne]

as a conclusion :

this is 100% human design
this is 100% visual studio computer implementation
this is 100% computer runs

and a small 3-5% potential improvement at the end.

I am curious to see if experts in AI can do better.

But this exercise to finish later by a new DLL will surely change slightly my strategy in the parallel process of similar programs to get an optimal output.