Number 1 engine on long time controls

[Dr.Wael Deeb]

Don't waste all your precious time on the forum...keep developing Komodo!!

By the way do you have a rough eta of Komodo MP?

I can't remember but did you say you were aiming for a 12 monthly release schedule or something more frequent than that?

The main bottleneck is always testing time, so answering questions on the forum while waiting for tests is not much of a slowdown. The newest Komodo SP is perhaps 15 or so elo ahead of Komodo 4. We should have MP data in a few days. We will certainly release more often than once a year, but how often depends on the rate of future progress, and the future is unknown.

Good luck with your upcoming release....
Dr.D

[Uri Blass]

6 seconds a game type time controls are giving zero information back as compared to alternative forms of testing.

Don't you believe in time control testing? By the way, this is not 6 seconds per game, it's Fischer 6 + 0.1 which is roughly equivalent to 12 seconds per side per game - a typical 60 move game should last about 24 seconds. We do not like sudden death time controls.

We have lots of people posting nonsense into this forum, but they all forget that most engine authors here basically produced something similar to rybka and basically got the first 3200 elopoints for free, and therefore are far from genius improving those engines by a few elopoints.

The fact no one claimed source code ownership of that code, nor started huge courtcases, also clearly proves it all was government sponsored; only governments are stupid enough to do so.

If you play engines that are very similar to each other against each other, then usually the one searching deeper wins.

All this 6 seconds a game time controls won't improve the beancounter engines much of course.

You can also prove of course that most algorithms invented in 90s, i invented a couple of dozens, if i retest most of them now, that back then Diep just didn't have the system time, so didn't get enough nodes per search, to even remotely break even with those algorithms.

At 6 seconds entire game you won't be getting enough nodes per search either to break even.

6 seconds single core entire game, what is it: 0.1 second a move or so.

0.1 * what do you get single core, like 2 million nps?

So we speak about 200k nodes for each search.

That's not gonna show of course whether a new 'search enhancement' is working.

It's just looking great on this forum and will prove nothing of course.

It's a stupid time control indeed....

Brilliant comment.

Don,don't take it personally or as a direct strike toward you....

Through all these years when I started testing computer chess programs,I've always avoided such ultra fast time controls....as you everyone can see from the above thread,they're useless to say the least....
Dr.D

But I cannot believe that you didn't notice that this was a study with many different levels, each one double the previous and that 6s + 0.1 was just the lowest level as a starting point. In the context of the discussion I did not take it as an insult, just as a really stupid comment.

No,Ive noticed the different levels of testing you've introduced....

The comment is not stupid,it's the time control you've used....

Read what the programmer of Diep wrote carefully....
Dr.D

6 seconds per game+0.1 seconds per move is only the fastest level.
The target is simply to find if Komodo improves with more time relative to houdini and how much.

6+0.1=level 0(0.2 second per move for game with 60 moves)
12+0.2=level 1(0.4 seconds per move for 60 moves)
24+0.4=level 2(0.8 seconds per move)
48+0.8=level 3(1.6 seconds per move)
96+1.6=level 4
192+3.2=level 5
384+6.4=level 6
768+12.8=level 7
1536+25.6=level 8(51.2 seconds per move)

The slowest level is not tournament time control but get closer to it and
we can learn from the result if there is a trend when komodo really scales better.

Note that we may need some months of computer time to get 2000 games of level 8 on one core and without using many computers for testing is it not practical to have level 9 and level 10.

[Dr.Wael Deeb]

6 seconds a game type time controls are giving zero information back as compared to alternative forms of testing.

Don't you believe in time control testing? By the way, this is not 6 seconds per game, it's Fischer 6 + 0.1 which is roughly equivalent to 12 seconds per side per game - a typical 60 move game should last about 24 seconds. We do not like sudden death time controls.

We have lots of people posting nonsense into this forum, but they all forget that most engine authors here basically produced something similar to rybka and basically got the first 3200 elopoints for free, and therefore are far from genius improving those engines by a few elopoints.

The fact no one claimed source code ownership of that code, nor started huge courtcases, also clearly proves it all was government sponsored; only governments are stupid enough to do so.

If you play engines that are very similar to each other against each other, then usually the one searching deeper wins.

All this 6 seconds a game time controls won't improve the beancounter engines much of course.

You can also prove of course that most algorithms invented in 90s, i invented a couple of dozens, if i retest most of them now, that back then Diep just didn't have the system time, so didn't get enough nodes per search, to even remotely break even with those algorithms.

At 6 seconds entire game you won't be getting enough nodes per search either to break even.

6 seconds single core entire game, what is it: 0.1 second a move or so.

0.1 * what do you get single core, like 2 million nps?

So we speak about 200k nodes for each search.

That's not gonna show of course whether a new 'search enhancement' is working.

It's just looking great on this forum and will prove nothing of course.

It's a stupid time control indeed....

Brilliant comment.

Don,don't take it personally or as a direct strike toward you....

Through all these years when I started testing computer chess programs,I've always avoided such ultra fast time controls....as you everyone can see from the above thread,they're useless to say the least....
Dr.D

But I cannot believe that you didn't notice that this was a study with many different levels, each one double the previous and that 6s + 0.1 was just the lowest level as a starting point. In the context of the discussion I did not take it as an insult, just as a really stupid comment.

No,Ive noticed the different levels of testing you've introduced....

The comment is not stupid,it's the time control you've used....

Read what the programmer of Diep wrote carefully....
Dr.D

6 seconds per game+0.1 seconds per move is only the fastest level.
The target is simply to find if Komodo improves with more time relative to houdini and how much.

6+0.1=level 0(0.2 second per move for game with 60 moves)
12+0.2=level 1(0.4 seconds per move for 60 moves)
24+0.4=level 2(0.8 seconds per move)
48+0.8=level 3(1.6 seconds per move)
96+1.6=level 4
192+3.2=level 5
384+6.4=level 6
768+12.8=level 7
1536+25.6=level 8(51.2 seconds per move)

The slowest level is not tournament time control but get closer to it and
we can learn from the result if there is a trend when komodo really scales better.

Note that we may need some months of computer time to get 2000 games of level 8 on one core and without using many computers for testing is it not practical to have level 9 and level 10.

I get the picture pretty much clear Uri....but still I think that level 7 & 6 is a total waste ot time & CPU resources....

It's better to play more games at slower time controls where the chess engine will have a real chance to obtain reasoble depth showing it's real potential.....

Using such an ultra short time control will certainly show you how much the chess engine scales with more time as going from stupid selection of moves during these time controls to choosing an actually good moves with slower time controls is a simple fact that nedds no testing to prove it....
Dr.D

[Uri Blass]

Dr.Wael,
Of course the move selection is better at slower time control both for Komodo and for Houdini.

When I wrote:
"we can learn from the result if there is a trend when komodo really scales better. "
I meant scales better relative to houdini.

[lkaufman]

It's a tiny sample but after 28 games at 15 minutes plus 15 seconds per move (both single core) the latest Komodo version leads Houdini 2.0 by 15 to 13 in my test.

[Dr.Wael Deeb]

Dr.Wael,
Of course the move selection is better at slower time control both for Komodo and for Houdini.

When I wrote:
"we can learn from the result if there is a trend when komodo really scales better. "
I meant scales better relative to houdini.

Aha....that makes sense,thanks....
Dr.D

[Dr.Wael Deeb]

It's a tiny sample but after 28 games at 15 minutes plus 15 seconds per move (both single core) the latest Komodo version leads Houdini 2.0 by 15 to 13 in my test.

A good time control for testing and an impressive gain over Houdini....

Hope you keep the pace after playing at least 200 games regards,
Dr.D

[Robert Flesher]

6 seconds a game type time controls are giving zero information back as compared to alternative forms of testing.

Don't you believe in time control testing? By the way, this is not 6 seconds per game, it's Fischer 6 + 0.1 which is roughly equivalent to 12 seconds per side per game - a typical 60 move game should last about 24 seconds. We do not like sudden death time controls.

We have lots of people posting nonsense into this forum, but they all forget that most engine authors here basically produced something similar to rybka and basically got the first 3200 elopoints for free, and therefore are far from genius improving those engines by a few elopoints.

The fact no one claimed source code ownership of that code, nor started huge courtcases, also clearly proves it all was government sponsored; only governments are stupid enough to do so.

If you play engines that are very similar to each other against each other, then usually the one searching deeper wins.

All this 6 seconds a game time controls won't improve the beancounter engines much of course.

You can also prove of course that most algorithms invented in 90s, i invented a couple of dozens, if i retest most of them now, that back then Diep just didn't have the system time, so didn't get enough nodes per search, to even remotely break even with those algorithms.

At 6 seconds entire game you won't be getting enough nodes per search either to break even.

6 seconds single core entire game, what is it: 0.1 second a move or so.

0.1 * what do you get single core, like 2 million nps?

So we speak about 200k nodes for each search.

That's not gonna show of course whether a new 'search enhancement' is working.

It's just looking great on this forum and will prove nothing of course.

Heya Vincent, it's really to bad you decided to not release Diep for sale. Many of us would love a chance to analyze and play with you great engine. Maybe someday

[Dr.Wael Deeb]

6 seconds a game type time controls are giving zero information back as compared to alternative forms of testing.

Don't you believe in time control testing? By the way, this is not 6 seconds per game, it's Fischer 6 + 0.1 which is roughly equivalent to 12 seconds per side per game - a typical 60 move game should last about 24 seconds. We do not like sudden death time controls.

We have lots of people posting nonsense into this forum, but they all forget that most engine authors here basically produced something similar to rybka and basically got the first 3200 elopoints for free, and therefore are far from genius improving those engines by a few elopoints.

The fact no one claimed source code ownership of that code, nor started huge courtcases, also clearly proves it all was government sponsored; only governments are stupid enough to do so.

If you play engines that are very similar to each other against each other, then usually the one searching deeper wins.

All this 6 seconds a game time controls won't improve the beancounter engines much of course.

You can also prove of course that most algorithms invented in 90s, i invented a couple of dozens, if i retest most of them now, that back then Diep just didn't have the system time, so didn't get enough nodes per search, to even remotely break even with those algorithms.

At 6 seconds entire game you won't be getting enough nodes per search either to break even.

6 seconds single core entire game, what is it: 0.1 second a move or so.

0.1 * what do you get single core, like 2 million nps?

So we speak about 200k nodes for each search.

That's not gonna show of course whether a new 'search enhancement' is working.

It's just looking great on this forum and will prove nothing of course.

Heya Vincent, it's really to bad you decided to not release Diep for sale. Many of us would love a chance to analyze and play with you great engine. Maybe someday

+1

[Werewolf]

Don't waste all your precious time on the forum...keep developing Komodo!!

By the way do you have a rough eta of Komodo MP?

I can't remember but did you say you were aiming for a 12 monthly release schedule or something more frequent than that?

The main bottleneck is always testing time, so answering questions on the forum while waiting for tests is not much of a slowdown. The newest Komodo SP is perhaps 15 or so elo ahead of Komodo 4. We should have MP data in a few days. We will certainly release more often than once a year, but how often depends on the rate of future progress, and the future is unknown.

Good, don't get sucked into the once per year model - there are too many of those engines.