Komodo 3 release

[M ANSARI]

MP will be extremely important for the future of computer chess. As more and more cores increase, taking proper advantage of the additional CPU power will be the decider between the top engines. Scaling will be king and by scaling I don't mean simply ramping up the efficiency factor with regards to parallel processing. But rather how to best utilize all this available hardware. At the moment 4 cores seems the standard minimum number of CPU's available for the average home PC, this can soon jump to 24 or even 64+ processors. When this happens the scaling efficiency curve drops, and most probably ideas like MC or Idea "on the fly" become interesting. Maybe you can use the core engine as the Master and then attribute many of the other cores to look at other tasks. I guess you could even create modules that will identify certain problematic endgame positions and would come active when an identifier flag switches on. Or since 10% of all endgames are rook endgames, some effort could be made to translate some of the very good rook endgame book knowledge into a rook endgame module that again becomes active when a certain flag is switched on. What to do with all those CPU's will certainly be interesting to see. I have a feeling that this is where engines will soon be different ... by their ability to come up with the most revolutionary way to utilize these multiple cores. I think that straight forward MP scaling efficiency will not necessarily be the most important, but rather new methods of utilizing some of those cores in independent yet related methods will win out.

[pocopito]

Hi all

I've been reading this thread for a couple of days and finding it really interesting, so I just wanted to drop a line to thank to all contributors.

And of course, thanks for the new komodo release. Untill I knew this forum I had no new at all abut it, and I guess I'll take a look at it in the next days.

[jpqy]

I can't say it better then M Ansari..a game move is decided by 0.01 difference,while the second best move at that moment(time) can turn the game completely!
So,let the engine split this search and give this line to a other core(s)
Engine has offcourse to know how many cores you have ,more cores=more splits possible.
When i have real 12cores for example,i have a setting in the engine parameters to select how many splits i want..i can choose 6..each split/line can use 2cores now when neccesary.
Engine has to recognize best line at that moment/time and start over with next move..

To bring this over into a engine is a challenge task!
Next step us the cores from the video card (cuda)..

JP.

[Don]

We are working on the next Komodo release now.

Already available are Komodo 3 for Android and Komodo 3 for 64 bit Linux. Hopefully we will have Komodo 3 for windows in the next day or two.

You can get it here:

http://komodochess.com


We believe we have approximately 30 ELO of improvement and more at non-fischer time controls which we were deficient in. However it's difficult to say for sure how much we have gained as this depends on how it scales to time controls we don't test at.

The majority of the gain has come from evaluation improvements.

We have just added the Mac version.

Still remaining are the windows versions which I am waiting on - but so far we have:

1. Linux 64 bit
2. Mac universal
3. Android

Don

[Dr.Wael Deeb]

We are working on the next Komodo release now.

Already available are Komodo 3 for Android and Komodo 3 for 64 bit Linux. Hopefully we will have Komodo 3 for windows in the next day or two.

You can get it here:

http://komodochess.com


We believe we have approximately 30 ELO of improvement and more at non-fischer time controls which we were deficient in. However it's difficult to say for sure how much we have gained as this depends on how it scales to time controls we don't test at.

The majority of the gain has come from evaluation improvements.

We have just added the Mac version.

Still remaining are the windows versions which I am waiting on - but so far we have:

1. Linux 64 bit
2. Mac universal
3. Android

Don

Thanks Don for all your efforts and good luck
Dr.D

[ernest]

MP will be extremely important for the future of computer chess.

The sad thing about MP is that it makes almost useless all the position tests, because of the MP non-reproducibility.
You can have solution times going from 1 to 10 (or more) for the same test on some critical positions...

With my dual core, I once repeated a position test 200 times, and obtained a probability distribution curve of the solution times (the curve had a main peak corresponding to solution times at depth d, and several smaller peaks corresponding to solutions at depth d+1 d+2 ... d-1 d-2...). But that was as far as I could go.

It is to be noted that even with SP you have that phenomenon when you use different hashtable sizes (but it seems difficult to do a scientific study on that matter, I have never seen one).

[Jamal Bubker]

Thanks Don et Larry ! Please, don't change the positional style of Komodo ! It's very useful for analyse some positional games

[Laskos]

With my dual core, I once repeated a position test 200 times, and obtained a probability distribution curve of the solution times (the curve had a main peak corresponding to solution times at depth d, and several smaller peaks corresponding to solutions at depth d+1 d+2 ... d-1 d-2...). But that was as far as I could go.

My guess it was close to a normal distribution, wasn't it? Even if _time_ or _kN_ are taken as the variables (exponential of depth), the distribution in my guess would be close to normal.

Kai

[ernest]

My guess it was close to a normal distribution, wasn't it?

Hi Kai,

Actually, it was more a log-normal distribution (variable was time_to_solution, so the log seems natural).
But you can also have a curve with several "humps", or a sort of "camel curve" (if you get the solution mostly at depth 21 or 22, equally...)

All that remains from my post, which originally was in the German CSS Forum, is there (including the distribution curve):
http://rybkaforum.net/cgi-bin/rybkaforu ... 5#pid27295

[Laskos]

My guess it was close to a normal distribution, wasn't it?

Hi Kai,

Actually, it was more a log-normal distribution (variable was time_to_solution, so the log seems natural).
But you can also have a curve with several "humps", or a sort of "camel curve" (if you get the solution mostly at depth 21 or 22, equally...)

All that remains from my post, which originally was in the German CSS Forum, is there (including the distribution curve):
http://rybkaforum.net/cgi-bin/rybkaforu ... 5#pid27295

Yes, my mistake, normal distribution on _depth_, log-normal on _time_ or _kN_. Your "camel curve" can be approximated to a log-normal on _time_ or _kN_. Thanks for the distribution curve in the link given, it's quite revealing.

Kai