Author: Robert Hyatt
Date: 08:19:25 04/08/03
Go up one level in this thread
On April 08, 2003 at 04:24:11, Jay Urbanski wrote: >>The fastest thing I know of is generallry the executables on my ftp machine. >>However, it is generally possible to make them faster, if you know the _exact_ >>procssor that will be used. Unfortunately, all I deal with is unix so that I >>can't compile windows versions here... > >Do you think you might ask whoever compiles the Windows executables to increase >the number of CPUs to a more reasonable number? (I would suggest 16 at least :) > What windows box has that many? That is the problem. The .exe files are windows-only and beyond 8 is in rarified company. >This begs the question - is there any benefit to keeping the number low? I >would think that once you get above one you have incurred whatever overhead you >are going to have for an SMP version and you should just be able to pick the >number of threads during runtime. Why limit the maximum? The problem is memory. The "tree" data structure is used in the parallel search and the general formula seems to be that I need NCPUS*NCPUS of them. For NCPUS of 16, that turns into 256 of the things, which will crank up the base memory requirement. There's no penalty other than that, but some would complain with the stuff that big. What I probably should do is malloc() the things after I know how many processors I am supposed to use, and I'll add that to my list so that the NCPUS thing won't always be needed when compiling.
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.