TalkChess.com

M ANSARI wrote:I this entire debate about scaling of Komodo vs. Houdini is pointless, rather than handicap all engines to play on one core so that they can compete with Komodo, it makes a lot of sense to make Komodo MP to compete with other engines. Time is a constant in computers, and this constant gets exponentially improved with each new generation of hardware. But I will be first to admit that some engines perform dramatically better at very short time controls than others, and yes the Ippolit derivatives are extremely strong at very fast blitz times. I don't know why that is so, but I always had the belief that in the case of Rybka, it has a lot of overhead in initializing start of processes (as it is a process based engine). These overheads are in mili seconds, but they can quickly become prominent when time runs down and games are very fast 1 0 or 2 0.

Start-up times may be a factor for Rybka at super-fast speeds, but for Komodo and all of the other top programs these are not a significant factor unless you are talking about something like game in one second. They do not play a role in explaining why Komodo and Stockfish are weaker than say Ivanhoe at bullet (1 min) chess but stronger at blitz (5 min) and much stronger at longer time limits. We will have our MP soon, but because so many people insist on judging engines by very fast games, we really need to figure out precisely why we cannot compete at these bullet speeds, in order to fix the problem if possible. It is almost surely some detail about the search that Ippo uses and that SF and Komodo do not use, but which detail is responsible I cannot guess, as we have tried almost every Ippo idea, mostly without success.

Hi Larry,

don't spend too much time on ultra-fast time controls. I'd say that isn't too interesting for real chess players and computerchess enthusiasts. An engine that is strong at medium and long TCs is most important. What I like most about Komodo is its totally different evaluation of some positions. Ippo-family engines don't find some moves in hours of calculating, but Komodo prefers the right move shortly after you begin to analyse. That's why I like Komodo.

Best regards
Timo

P.S.: You can watch Komodo compete with the other Top-Engines in my live broadcast (tournament TCs, 60 games against each other, Ponder=On): http://www.team-oh.de/Computerschach/Clash.htm

TimoK wrote:Hi Larry,

don't spend too much time on ultra-fast time controls. I'd say that isn't too interesting for real chess players and computerchess enthusiasts. An engine that is strong at medium and long TCs is most important.

I disagree with part of what you say
I agree that engine that is strong at medium and long TC is most important
but it is possible that it is possible to make komodo stronger at all time controls if you understand why Komodo is weaker at ultra fast time control.

TimoK wrote:Hi Larry,

don't spend too much time on ultra-fast time controls. I'd say that isn't too interesting for real chess players and computerchess enthusiasts. An engine that is strong at medium and long TCs is most important. What I like most about Komodo is its totally different evaluation of some positions. Ippo-family engines don't find some moves in hours of calculating, but Komodo prefers the right move shortly after you begin to analyse. That's why I like Komodo.

Best regards
Timo

P.S.: You can watch Komodo compete with the other Top-Engines in my live broadcast (tournament TCs, 60 games against each other, Ponder=On): http://www.team-oh.de/Computerschach/Clash.htm

I have different point of view (not like yours)

Really i dont understand why some people are against Ippo-family engines ?!

I hope its not due to Ippo engines are clones and all rest engines are 100 % original work ?!

One thing more,Ippo-family engines are completely free,plus i am quite satisfied by their playing strenght in blitz and slow time controls

Just i'd like mentioned again that any professional program should not be buggy and should be ok in all time controls

Btw,from my experience i can say that the chess engines don't play at full strength using via Netchess adapter

And this is one of the main reasons about why i switched to Auto232 mode

Greetings,
Sedat

Hi Sedat,

Really i dont understand why some people are against Ippo-family engines ?!

I hope its not due to Ippo engines are clones and all rest engines are 100 % original work ?!

Where did I say that I'm against Ippo-family engines? Please read my post again. I only said that Komodo evalutates completely different.

Just i'd like mentioned again that any professional program should not be buggy and should be ok in all time controls

You think Komodo is buggy because it's not tuned to ultra-fast time-controls? Well, that's a strange point of view, but ok, it's your opinion.

Btw,from my experience i can say that the chess engines don't play at full strength using via Netchess adapter

Please share that experience with me and tell me more. From my experience engines connected via Netchess behave (=play) exactly like they are running locally. Do you have games or positions to substantiate this allegation? Btw. I'm using a newer beta-version of NetChess, but even with the downloadable standard version I had no such problems at all.

Best regards
Timo

Dear Timo,

Where did I say that I'm against Ippo-family engines? Please read my post again. I only said that Komodo evalutates completely different.

Sure...you did not use exactly the same words,but its quite qlear what do you mean with your 1st posting
In my opinion,all testers should be neutral and what a pity that some testers are against testing some top engines

You think Komodo is buggy because it's not tuned to ultra-fast time-controls? Well, that's a strange point of view, but ok, it's your opinion.

No...as far as i remember i never used a word:Komodo is a buggy engine,my meaning is for overall professional programs
But anyway,i am very happy too that we have Komodo-another very strong participant,but however Ippo engines perform much better in my tourneys
I guess,Komodo MP will be a serious opponent,but for right no we have no other choice,exception to wait...

Please share that experience with me and tell me more. From my experience engines connected via Netchess behave (=play) exactly like they are running locally. Do you have games or positions to substantiate this allegation? Btw. I'm using a newer beta-version of NetChess, but even with the downloadable standard version I had no such problems at all.

I used the Netchess adapter, which is available to public and honestly i was disappointed by the performance of some mp engines (engines were using 4 cores)
Plus,even many times i noticed many engine crashes via Netchess adapter...

Note also that i already informed ( about those bugs,including with screenshots) and sent a few mails to the Netchess Author

Best,
Sedat

Hello Sedat,

Sedat Canbaz wrote:Sure...you did not use exactly the same words,but its quite qlear what do you mean with your 1st posting
In my opinion,all testers should be neutral and what a pity that some testers are against testing some top engines

Well, let me say it that way: For my taste there are too many Ippo-family engines around. No tester has the time to test all engines, so one has to choose. I'm testing Houdini that is clearly the strongest derivate. So I'm not very much interested in the rest of that family because I already have the strongest one. And there is another point: Because I'm Houdini customer, I'm able to get support. For any Ivanhoe or Robbolito I can't get any support from the author. Maybe I'll buy Vitruvius soon because it seems to have an interesting playing style and I'd get support because I bought a commercial product.

Sedat Canbaz wrote:I used the Netchess adapter, which is available to public and honestly i was disappointed by the performance of some mp engines (engines were using 4 cores)
Plus,even many times i noticed many engine crashes via Netchess adapter...

Ok, sometimes there is a problem after a game has ended (Fritz GUI reports "Could not load engine") - maybe that has something to do with NetChess. But the performance problems you speak of never appeared in my tests. Maybe because you were testing at fast TCs and I'm only testing with slower TCs. The overhead/delay that is caused by NetChess could affect games at blitz level, but are negligible at longer TCs.

Best regards
Timo

lkaufman wrote:

M ANSARI wrote:I this entire debate about scaling of Komodo vs. Houdini is pointless, rather than handicap all engines to play on one core so that they can compete with Komodo, it makes a lot of sense to make Komodo MP to compete with other engines. Time is a constant in computers, and this constant gets exponentially improved with each new generation of hardware. But I will be first to admit that some engines perform dramatically better at very short time controls than others, and yes the Ippolit derivatives are extremely strong at very fast blitz times. I don't know why that is so, but I always had the belief that in the case of Rybka, it has a lot of overhead in initializing start of processes (as it is a process based engine). These overheads are in mili seconds, but they can quickly become prominent when time runs down and games are very fast 1 0 or 2 0.

Start-up times may be a factor for Rybka at super-fast speeds, but for Komodo and all of the other top programs these are not a significant factor unless you are talking about something like game in one second. They do not play a role in explaining why Komodo and Stockfish are weaker than say Ivanhoe at bullet (1 min) chess but stronger at blitz (5 min) and much stronger at longer time limits. We will have our MP soon, but because so many people insist on judging engines by very fast games, we really need to figure out precisely why we cannot compete at these bullet speeds, in order to fix the problem if possible. It is almost surely some detail about the search that Ippo uses and that SF and Komodo do not use, but which detail is responsible I cannot guess, as we have tried almost every Ippo idea, mostly without success.

I am sure there are other reasons, the fact is that there are some evaluation values that simply don't work at fast time control. A good example in Houdini 1.5 would be the overly high evaluation of a queen vs pieces. Just like in human chess, strong tactical players like to have a queen against weaker players because there are many more dynamic reasons to go wrong. But when you have plenty of time to see the tactical pitfalls, a queen can quickly get over extended and the pieces can get coordinated to quickly snuff out the advantage of the queen and thus the "real" evaluation wins. I remember seeing this when beta testing R4 against H 1.5 and I saw many games that confirmed this.

M ANSARI wrote:

lkaufman wrote:

M ANSARI wrote:I this entire debate about scaling of Komodo vs. Houdini is pointless, rather than handicap all engines to play on one core so that they can compete with Komodo, it makes a lot of sense to make Komodo MP to compete with other engines. Time is a constant in computers, and this constant gets exponentially improved with each new generation of hardware. But I will be first to admit that some engines perform dramatically better at very short time controls than others, and yes the Ippolit derivatives are extremely strong at very fast blitz times. I don't know why that is so, but I always had the belief that in the case of Rybka, it has a lot of overhead in initializing start of processes (as it is a process based engine). These overheads are in mili seconds, but they can quickly become prominent when time runs down and games are very fast 1 0 or 2 0.

Start-up times may be a factor for Rybka at super-fast speeds, but for Komodo and all of the other top programs these are not a significant factor unless you are talking about something like game in one second. They do not play a role in explaining why Komodo and Stockfish are weaker than say Ivanhoe at bullet (1 min) chess but stronger at blitz (5 min) and much stronger at longer time limits. We will have our MP soon, but because so many people insist on judging engines by very fast games, we really need to figure out precisely why we cannot compete at these bullet speeds, in order to fix the problem if possible. It is almost surely some detail about the search that Ippo uses and that SF and Komodo do not use, but which detail is responsible I cannot guess, as we have tried almost every Ippo idea, mostly without success.

I am sure there are other reasons, the fact is that there are some evaluation values that simply don't work at fast time control. A good example in Houdini 1.5 would be the overly high evaluation of a queen vs pieces. Just like in human chess, strong tactical players like to have a queen against weaker players because there are many more dynamic reasons to go wrong. But when you have plenty of time to see the tactical pitfalls, a queen can quickly get over extended and the pieces can get coordinated to quickly snuff out the advantage of the queen and thus the "real" evaluation wins. I remember seeing this when beta testing R4 against H 1.5 and I saw many games that confirmed this.

I believe that what you say is indeed a contributing factor, but in my opinion the observed disparity in relative strength between bullet and blitz is way too large to be explained by such eval factors. It must be something in the search that is responsible. By this I mean something that Ippo (and Houdini) does which Komodo and Stockfish do not do. But as we've tried pretty much every search idea in Ippo and nothing helps the problem, it remains a mystery.

lkaufman wrote:

M ANSARI wrote:

lkaufman wrote:

M ANSARI wrote:I this entire debate about scaling of Komodo vs. Houdini is pointless, rather than handicap all engines to play on one core so that they can compete with Komodo, it makes a lot of sense to make Komodo MP to compete with other engines. Time is a constant in computers, and this constant gets exponentially improved with each new generation of hardware. But I will be first to admit that some engines perform dramatically better at very short time controls than others, and yes the Ippolit derivatives are extremely strong at very fast blitz times. I don't know why that is so, but I always had the belief that in the case of Rybka, it has a lot of overhead in initializing start of processes (as it is a process based engine). These overheads are in mili seconds, but they can quickly become prominent when time runs down and games are very fast 1 0 or 2 0.

Start-up times may be a factor for Rybka at super-fast speeds, but for Komodo and all of the other top programs these are not a significant factor unless you are talking about something like game in one second. They do not play a role in explaining why Komodo and Stockfish are weaker than say Ivanhoe at bullet (1 min) chess but stronger at blitz (5 min) and much stronger at longer time limits. We will have our MP soon, but because so many people insist on judging engines by very fast games, we really need to figure out precisely why we cannot compete at these bullet speeds, in order to fix the problem if possible. It is almost surely some detail about the search that Ippo uses and that SF and Komodo do not use, but which detail is responsible I cannot guess, as we have tried almost every Ippo idea, mostly without success.

I am sure there are other reasons, the fact is that there are some evaluation values that simply don't work at fast time control. A good example in Houdini 1.5 would be the overly high evaluation of a queen vs pieces. Just like in human chess, strong tactical players like to have a queen against weaker players because there are many more dynamic reasons to go wrong. But when you have plenty of time to see the tactical pitfalls, a queen can quickly get over extended and the pieces can get coordinated to quickly snuff out the advantage of the queen and thus the "real" evaluation wins. I remember seeing this when beta testing R4 against H 1.5 and I saw many games that confirmed this.

I believe that what you say is indeed a contributing factor, but in my opinion the observed disparity in relative strength between bullet and blitz is way too large to be explained by such eval factors. It must be something in the search that is responsible. By this I mean something that Ippo (and Houdini) does which Komodo and Stockfish do not do. But as we've tried pretty much every search idea in Ippo and nothing helps the problem, it remains a mystery.

Larry, maybe the reason for this discrepancy in strength is much simpler than you think. I cannot deduct that my idea is right but I have a feeling that it is just related to the shape of the search tree in relation to time or reflection time. I like to presume that a shallow/thin tree is best for elo provided this tree is 'correct' from a PV point of view. I also presume that no engine does what I would call 'permanent pruning', but that temporary pruned moves can resurface at a later iteration due to longer reflection time. I belief that engines with a shallow/thin search tree could spot such temporary pruned (better) moves and shift the tree (in time) without actually changing its 'form' because it stays thin. This could explain that the better move is eventually spotted given enough time. This better move normally is not the first (and only) move of the PV, but can also be pinpointed due to a second better move down the line that was pruned initially. Spotting this type of dependency (coherence) between moves can be a strength or weakness of an engine but is also influenced by the general tree shape. If it is a strength and the tree is thin and deep then you have a very strong engine. Now please compare Komodo with Houdini for example and you will notice that on average the single thread Komodo after prolonged time reaches the same depth as Houdini running three threads in that same time. This is a clear indication that Komodo's search tree is thin compared to Houdini's and that the latter suffers less from initially pruned moves. This should be more prominent when reflection time is fast.

Another more subjective way of formulating this principle would be to look at the 'quality' of the given PV line. If just the first few moves are 'correct' the PV line is 'flawed' even though the first move is the correct one. It's a matter of time though before you run into examples where the second best move is chosen due to inferior moves in the PV. Coherence in the chain is crucial, especially in long chains.

Best wishes,
Ron