Author: Dann Corbit
Date: 16:05:11 09/19/02
Go up one level in this thread
On September 19, 2002 at 17:56:12, David Hanley wrote: >On September 19, 2002 at 17:40:18, Dann Corbit wrote: > > >>How to get the speed is the key thing, though. You might add hash tables to >>TSCP and it will double the speed. You might add null move to TSCP, again, >>probably doubling the speed. You might fix the iteration in eval.c to use a >>move list instead of iteration over the whole board. If you go to individual >>piece lists, it will be about 4x faster in the early game, and 10x faster in the >>endgame. Combine them all together and it will be quite a speedup. > >There is a ton i could do to speed it up that i know of offhand. Like i said i >do allocation during the search, all of my arrays are bounds-checked, there's a >lot of dynamic typing going on, etc. I know i can rip a lot of that stuff out >and make it run faster, probably by a factor of ten, but it's nice to have while >i'm developing. > >I am surprised that piece lists will lead to such a dramatic speedup, that's a >good tip, thanks! I wonder if i can add that in with just a k or two of >source--hmmm... Depends on the program. Also, when you speed something up 40 times, something else will become the bottleneck. Mispredicted branches are very bad, and so all the if() checks and switches will be very expensive. If you update the piece lists with makemove/unmakemove you can do it incrementally and you know what the piece is when you do it. Now, with TSCP you will see that it always searches the whole board. That's 64 squares. And then it will do lots of branches depending on what is on the board. You never have more than 32 pieces even at the start, and imagine the savings when there are only 8 pieces left. But I have no idea if it will make a big difference for Lisp.
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.