Author: Reinhard Scharnagl
Date: 17:51:51 10/17/04
Go up one level in this thread
On October 17, 2004 at 19:02:24, Sune Fischer wrote: >On October 17, 2004 at 10:18:52, Stuart Cracraft wrote: > >>>Hi, >>> >>>I think bitboards generate move faster especially capture moves. But it's slower >>>in makemove() and unmakemove() because it has to update a lot of data. >>>However, you can do a lot of tricks with bitboards in eval(). So,if you want to >>>compare the two methods, you 've to compare the performance not only speed of >>>movegen(). >>> >>>Regards, >>>Teerapong >> >>Movegen is not the issue with bitboards. >>In fact, it is a drawback. >I doubt it. > >I can't remember ever seeing a non-bitboard engine be faster than a bitboarder >in incremental generation. > >Most of those with old-style generators dare not even try it because they know >it's so expensive for them. > >OTOH, I agree with TEERAPONG TOVIRAT that the makemove might be slower due to >extra work on the rotated boards. > >> Much harder to implement >>movegen with bitboards than with 0x88 or mailbox. > >Initially yes but I think it pays off later. Hi Stuart, when you know so much generators, how do you judge on the following results (from an Intel P4 2.8 GHz) also including check and mating information, all done without bitboards: FEN: rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1 +-*--b--c--d--*--f--g--*-+ MS Vis. Studio C++ Vers. 13.10 8 |[r][n][b][q][k][b][n][r]| 7 |[p][p][p][p][p][p][p][p]| Perft Testseries 6 | ::: ::: ::: :::| 5 |::: ::: ::: ::: | (without caching) 4 | ::: ::: ::: :::| 3 |::: ::: ::: ::: | Test #: 00 2 |<P><P><P><P><P><P><P><P>| 1 |<R><N><B><Q><K><B><N><R>| Break Time 5.0 Sec. =>+-*--b--c--d--*--f--g--*-+ Ply Nodes all (x) (e.p.) all (+) (#) Promot. Castl. Sec. ------------------------------------------------------------------------------- 01 20 0 0 0 0 0 0 0 02 400 0 0 0 0 0 0 0 03 8902 34 0 12 0 0 0 0 04 197281 1576 0 469 8 0 0 0 05 4865609 82719 258 27351 347 0 0 0.2 06 119060324 2812008 5248 809099 10828 0 0 5.2 ------------------------------------------------------------------------------- FEN: r3k2r/p1ppqpb1/bn2pnp1/3PN3/1p2P3/2N2Q1p/PPPBBPPP/R3K2R w KQkq - 0 25 +-*--b--c--d--*--f--g--*-+ MS Vis. Studio C++ Vers. 13.10 8 |[r]::: :::[k]::: [r]| 7 |[p] [p][p][q][p][b] | Perft Testseries 6 |[b][n] :::[p][n][p]:::| 5 |::: :::<P><N> ::: | (without caching) 4 | [p] :::<P>::: :::| 3 |::: <N> :::<Q>:::[p]| Test #: 01 2 |<P><P><P><B><B><P><P><P>| 1 |<R> ::: <K> :::<R>| Break Time 5.0 Sec. =>+-*--b--c--d--*--f--g--*-+ Ply Nodes all (x) (e.p.) all (+) (#) Promot. Castl. Sec. ------------------------------------------------------------------------------- 01 48 8 0 0 0 0 2 0 02 2039 351 1 3 0 0 91 0 03 97862 17102 45 993 1 0 3162 0 04 4085603 757163 1929 25523 43 15172 128013 0.2 05 193690690 35043416 73365 3309887 30171 8392 4993637 8.9 ------------------------------------------------------------------------------- I had used an sequential (incremental) generator but switched to this en block generator because of its better over all performance. Regards, Reinhard
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.