Author: Vasik Rajlich
Date: 07:55:53 04/04/04
Go up one level in this thread
On April 03, 2004 at 08:10:21, Bernd Nürnberger wrote: >On April 03, 2004 at 06:17:57, Vasik Rajlich wrote: > >>On April 02, 2004 at 07:19:40, Bernd Nürnberger wrote: >[...] >>> >>>Maybe I did the killers wrong. I did two for each ply, and for every >>>beta cutoff, I move killer2[ply] to killer1[ply] and overwrite killer2[ply] >>>by the move, causing the beta cutoff. >> >>Yes, that's correct. >> >>Actually, I put the new killer move such that it is the first one. (Ie chosen >>first during subsequent move generation.) Intuitively this seems slightly more >>correct, but I haven't tested this and it really shouldn't matter much. > >I put back killers now into my engine, and they indeed helps -- to less or >more account depending on the position (that's clear ...). >I will also try some experiments with the idea I read in another thread: >also take killer[ply-2n], killer[ply+2n]... > Interesting. Probably at most a very small win - but cheap anyway. >[...] >>I think this also depends on the speed of your engine. The faster your engine, >>the less time you should spend on move ordering. (More generally, the faster >>your engine, the less time you should spend on everything.) > >I am not sure about this. A small improvement in move ordering is often >a very large improvement in speed. But details are nethertheless dependent >on the engine. > >btw. With a small eval function (pc values, pc-sq values, castling), my >engine uses about 2000 clocks/move. Hopefully it will not drop to >much with a more sophisticated eval (the things now can all be done >incementally) ... but after all, I am using Java and therefore it runs >really fast IMO ... That is really fast. When Rybka was first running, it was also really fast. (Although not this fast.) At some point, you have to decide if you will keep it fast (ie like Fritz, Junior), or try some more expensive computation (ie. like Shredder, Hiarcs). > >>>Maybe I should try to do killers before even or bad captures, as you propose. >>>I will test it, as soon as I have some SEE function implemented. Right now >>>I am doing a MVV/LVA ordering, so I cannot clearly say: what is an even, >>>what is a bad capture and the ordering itself does not do clear cuts here >>>either. >> >>Bad captures and moves which allow the opponent good captures should definitely >>go at the bottom of the list. The question is whether it's worth the computation >>to put them there. > >I am pretty sure, in most cases it is worth the computation. I just added >some plain vanilla internal iterative deeping, which *really* consumes >much time because doing a complete depth-2 search - the results were positive >as far as I can say this after just implementing it ... If you browse through the CCC archives, you will see all sorts of threads about how "A" works great in engine X but horribly in engine Y. There are many reasons for this. One big one is the speed of the engines in question. The faster an engine, the less it will profit from additional computation, so the threshold for the effectiveness of this computation is set higher. So, the slower your engine, the better it is to order the moves better, compared to a faster engine. Anyway, this is just a theory. Re. internal iterative deepening, it's much more important to order the first move well than to order the bottom half of the moves well. If you order your first move well, you'll fail high quicker, saving lots of nodes. If you get to the point of searching the bottom half of your moves, you are probably failing low anyway, and the order won't matter. This is why IID is a big win, even though it's very expensive, while other much cheaper static move ordering tricks are not so clear. Cheers, Vas > >Greetings, Bernd
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.