Author: Bruce Moreland
Date: 15:57:03 09/21/99
Go up one level in this thread
On September 21, 1999 at 14:54:28, Scott Gasch wrote: >On September 21, 1999 at 13:54:44, Bruce Moreland wrote: > >>When I came back from Germany I was lazy about taking the machine out of the >>box, so it sat in the box for some huge long period of time. Then I got mail >>from Vincent asking me to run some test for him, and there the machine sits, in >>ply 20, having looked at 2.8 trillion nodes at approximately 890K nodes/second. > >I am curious as to how in the world one gets a node rate that high? I dont >doubt that it can be done but with my code on (fairly) fast hardware I only see >about 150k. Even if I strip out the eval routine and make it just consider >material balance I only see about 200k or so. > >I have implemented every speed enhancement i can think of except coding up the >eval in assembly language by hand (I do not know i386 assembly language well >enough for that). For instance, I use movepools to avoid calls to malloc >altogether, have piece->location tables to avoid searching for pieces, a pawn >hash, material strengths and piece counts for each side are part of the >position... > >Can anyone suggest other often used ways to boost search rate? It's a multiprocessor machine, a quad 450. I don't think it makes much sense to code in assembly, unless you are the type that likes to whack himself in the head with a board every few minutes. If you fiddle with a program constantly it will tend to go faster, if some of the changes you make are supposed to be speed changes only. You can also use forward pruning in your tree, which will increase apparent depth. Increased node rate is not a very good goal in my opinion. I'd rather work to improve strength and playing style. If you use "malloc" as a regular part of your search you'll go really slow. If you are talking about generating moves, I think the best way to go is a special-case mark and release heap. What this means is that you have an array of like 0..32767 generated moves. When you enter the search, you generate moves for the current position, which will fill elements 0..N in the array. When you execute the move at element zero and recurse into "search", you fill elements N+1..M in the array. When you are done with those, you come back and execute the move at element one, and then recurse and once again use array elements starting at position N+1. My explanation is complicated but it is simple to implement and involves no memory allocations other than the first one. bruce
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.