6 Men TB Generator

Endgame analysis using tablebases, EGTB generation, exchange, sharing, discussions, etc..
User avatar
Martin Kreuzer
Posts: 53
Joined: Thu Jun 08, 2006 9:02 am
Sign-up code: 0
Contact:

Post by Martin Kreuzer »

Hi Guido,

I have computed two more endgames on my 3.4GHz Pentium 4 (2 GB RAM):
kbbkbb took 5 hours,
kbbknn took 17 hours.
The second one was computed with a different method implemented by Eugene Nalimov which he calls "bit vector algorithm".

Ciao,
Martin Kreuzer
guido
Posts: 42
Joined: Sun Jun 18, 2006 8:55 pm
Sign-up code: 0
Location: Milan, Italy

Post by guido »

Martin Kreuzer wrote:Hi Guido,

I have computed two more endgames on my 3.4GHz Pentium 4 (2 GB RAM):
kbbkbb took 5 hours,
kbbknn took 17 hours.
The second one was computed with a different method implemented by Eugene Nalimov which he calls "bit vector algorithm".

Ciao,
Martin Kreuzer
Hi Martin,

Thank you again for these info. It is clear that I have to work hard to make my generator faster.

In my table of the last message, there were both the cpu time and the elapsed time: this distinction is important for me to see what part of the time is related to computations and what to the I/O in order to try to reduce the total
time. It is more logical to compare the elapsed time with your data, so I spent 11 h and 60 h for kbbkbb and kbbknn respectively. Too much in particular for kbbknn!
I'm doing a correction that should reduce the time for this ending by about a ten per cent or more, but I'm still far from the result you obtained, even if my PC is "only" 2.4 GHz.

On the contrary I spent less than two hours for knnknn against 12 hours of Nalimov. Also reducing the time optimizing the compilation, I find the thing a little strange. It is true that in knnknn I used method 3 (retrograde algorithm) while in the other case method 2 (semi-retrograde algorithm).
I cannot use freely method 3 because I have still an error with this algorithm in some TBs when they cannot be kept completely in RAM. Moreover the problem of the retrograde algorithm is that the cpu time is very low but the I/O
time increases very much, so with big RAMs this method is surely the fastest one.

I don't know what is the "bit vector algorithm" of Nalimov but I imagine that it could be a method similar to that described by Wu and Beal in the paper "Memory Efficient Retrograde Algorithm and Its Application To Chinese Chess Endgames".

ciao
guido
Nulla dies sine linea
User avatar
Martin Kreuzer
Posts: 53
Joined: Thu Jun 08, 2006 9:02 am
Sign-up code: 0
Contact:

Timings

Post by Martin Kreuzer »

Dear Guido,

please do not take my first timings very seriously. They
were obtained with a compilation of the TB generator which
was quite inefficient. I had not used any "optimization" and
the executable included a lot of unneeded debug information.
The later compilations are faster by about a factor of 3.

Greetings,
Martin Kreuzer
Leto
Posts: 3
Joined: Thu May 04, 2006 2:15 am
Sign-up code: 0

Post by Leto »

If only Blue Gene could be used, we would have 20 piece tablebases by now...
User avatar
jshriver
Posts: 298
Joined: Tue Jan 31, 2006 5:59 am
Sign-up code: 0
Location: Toledo, OH, USA
Contact:

Re: Timings

Post by jshriver »

Martin Kreuzer wrote:Dear Guido,

please do not take my first timings very seriously. They
were obtained with a compilation of the TB generator which
was quite inefficient. I had not used any "optimization" and
the executable included a lot of unneeded debug information.
The later compilations are faster by about a factor of 3.

Greetings,
Martin Kreuzer
Can you email me a tar.gz or tar.bz2 of the 32bit linux compile?

-Josh
Post Reply