Houdini 1.03 is available

[jeandis]

Bonjour Mr. Houdart,
J'ai testé à plusieurs reprises votre moteur version 1.03 contre deep rybka 4 TC3100150 à 4 minutes la partie. Je possède un quad 6600 2.4 ghz 64 bits et le résultat est que deep rybka 4 gagne Houdini à cause de 2 choses principales :

1 - le moteur ne reconnait pas les tables de Nalimov (à moins que vous puissiez m'expliquer comment faire pour qu'il puisse les lire) ce qui est très important

2 - moteur plus lent pour effectuer les coups donc sujet de perdre au temps

J'ai effectué un petit changement au paramètre du moteur mais je ne pense pas que celà soit l'explication des points 1 et 2 à savoir :

split_depth 12 au lieu de 10 et activation des larges pages.

Félicitations pour votre excellente coopération sur les échecs.
cordialement,

Jean

[Odeus37]

Not that sure that Robert Houdart can read French... To sum it up, he is saying that :

he tested Houdini 1.03 against rybka 4 TC3100150 in 4 minutes blitz games, on a q6600 64 bits, and that Rybka 4 is winning because :

1) Houdini can't use Nalimov tables
2) Houdini is slower to play, and then can loose on time

Only changes he made from default were split_depth 12 and larges pages on.

[jeandis]

hello Odeus37.
I believe he speaks french because he is french jejejeje. I saw him in facebook and his writting was in french. May be he is an another Robert Houdart? a clone? jejeje

[Robert Houdart]

jeandis, I'm not French (to paraphrase Hercule Poirot ) and don't have a Facebook page, but I do speak and write French quite fluently. My mother tongue is Dutch.
Let me reply to your 2 observations in English, this will probably be easier for most of the forum members.

1) Based on what others have written (e.g. Bob Hyatt) I don't think that EGTB matter that much for 4 minute games. The only 5-piece bases that would really give Houdini a bonus in fast games are KQPKQ and KRPKR, as they occur quite frequently.
On the other hand, for deep analysis EGTB are quite interesting - especially the 6-piece TB - and at some point in time I will include them in Houdini (either Nalimov or the Gaviota variety).
Could you give an example game of Houdini losing (or missing a win) because of the lack of EGTB?

2) Rybka is indeed more conservative with its time usage, which can sometimes pay off when the other engine is running out of time.
But in my opinion fast blitz games without increment are not a very good idea: you're completely crippling the endgame of both engines, as neither will have the time to play correctly. If you really want to give both engines the opportunity to demonstrate their endgame skills you should play with a small increment. For example 4'+2" would be a much better choice than 4'+0 as the game would be decided on chess skills, not on which engine survives the longest.

Robert

[Vael Jean-Paul]

I can agree here..but still i can tell you my findings.

I'am testing for many years now..used so long time Arena..i follow every game..yes every game,because in Arena you get to many
correction to do at the end off a game when the game is not decided in clearly 1-0 or 0-1..loose on times are the most..even completly winning games the engine can loose the point..when it's sure draw ,loose on time then is it possible the other engine get the point (sound logic) or even the engine has loose on time and get the point himself!??
End databases are usefull..again not so good in Arena..but okay i have loved to use Arena many years!

Till i use Fritz..what a difference..i come from 40moves in 2hours games to 5min.blitz games because we get these days very fast computer systems..when i had a E6600 @3.6Ghz i play 15min games..with my next computer the Q6600 go @3.6Ghz i use 10min. time control and now with the core i7 920 @3.8Ghz i use 5min.blitz with everytime when i look back get better or deeper depth during these games!
In Fritz Gui with my new list i have played now 3660games..and have no single time loose seen! And when they come to the end game it fly's over your screen in 1sec. If they don't come into the end games..means they repeat 3 times position and make draw!
So,i have never to correct a game anymore,the bases helps you to not need using for example playing 5min+1sec.games.

Under Arena it's a good way to use time increments,but still you have to follow the games! or at least to check them!

Oh yes Robert..i have decided after a few more tests to use Houdini 1.03a x64 popcnt 4cpu..and doing very well here!!
Will see where he will ends.

Again thanks for this great compile!

JP.

[jeandis]

first thank you to reply to my message, very kind of you. Normally all games that I played in an internal tournament were at 4' per game. Houdini analysed very well but I saw that Houdini which is better after to get out of the book (+ 0.30/0.50 for example) little a little when it brought near the endgame it lost some goods positions. Sure, some games won Houdini but in a match against Deep Rybka 4 TC3100150 untill this moment rybka 4 won 2/3 games in 24 match games.
Congratulations for you hard work to make Houdini a terrible chess weapon!

[BB+]

For this kind of comparison I use a fixed-time search from the starting position with the default 128 MB hash.

I don't think this testing method is all that great I remember that Jury Osipov and I debated how much faster IvanHoe was than Rybka 3, and the opening position was slightly misleading compared to a broader spectrum of positions. There is also the question of how long the test should (to get rid of OS burps), and my guess is that 1 minute for a multi-cpu search is a bit short to try to resolve below a few percent.

That is the normal behaviour, the more memory you use the slower it gets.

There's also simply an accounting feature here -- when you get a hash hit, it doesn't count a node. This may seem trivial, but the time to loop through the hash stuff as compared to calling the make/unmake routine (where nodes are counted, at least in IvanHoe) means that if you have zero hash hits (think of a corrupted TT -- you are still doing hash lookups, but all fail) the NPS will increase. As an example, I get about 1400000 NPS in IvanHoe, but if I put "Z=0" in the hashing code before HASH_POINTER is called in Zobrist_use.c (I count 5 cases), this hits 2500000 NPS, a 78% "speedup"! [And it also then takes 2.3s to reach depth 12 with this "speedup"].

On the other hand, for deep analysis EGTB are quite interesting - especially the 6-piece TB - and at some point in time I will include them in Houdini (either Nalimov or the Gaviota variety).

Obtaining permission for Nalimov is a hassle, though it does have the advantage that many people have taken the large step of downloading 100s of GBs of data. Gaviota doesn't currently have 6-piece (at least I haven't seen it announced if so), but by the time you get around to it, it might. RobboBases currently have 6 piece, but I think the exact scheme would have to be modified (the "Total" Bases only work at the root position as-is, and the "Triple" Bases don't seem to support 6 piece yet), and I haven't seen the 6 piece bases actually distributed. They are also distance-to-conversion rather than distance-to-mate, which might be disconcerting to some who prefer an "analysis" engine.