Author: Robert Hyatt
Date: 08:32:00 09/17/01
Go up one level in this thread
On September 17, 2001 at 06:44:33, Vincent Diepeveen wrote: >> >i forgot you have a cluster at university. > >Which network cards must i buy to get that latency and what's their >price, because i'm interested in buying 2 of those myself if they're >not $$$$. > They are selling for about 400 bucks each. Perhaps cheaper as that was the price two years ago. That will give you a two-node system with the 1.25 gigabit/sec full-duplex bandwidth, .5 microsecond latency. >most important thing to realize is that big majority of dudes here >are talking about running a program at their homenetwork, so their question >is always regarding 100mbit networks at most. to my amazement still >most companies still create 10mbit networks. Don't know about the rest of the world. Most companies over here are using 100mbit networks. That is more than fast enough to work with modest- sized clusters. And with some forethought into load distribution patterns, a good switch turns a 100mbit/second network into something much faster since any two nodes can communicate at 100mbits/sec without interfering with any other nodes trying to communicate.. at all... > > > >> >>> >>>That means, depending upon branching factor you will lose loads of system >>>time waiting for hashentries. >> >> >>Not if I do the algorithm right. I'm not going to be "waiting" for hash >>entries and doing nothing. > >Yes you told some years ago already this delayed transposition >suggestion and i have sincethen thought long about it, but the >main problem is that branching factor gets worse. Worse, but not a lot worse. Since 80% of the time a hash probe gets a "miss" anyway. This means that 80% of the time you search just as you would without a hash table anyway. The remaining 20% will lose a bit here and there. Not all hash hits will cut the search off instantly. And if your search algorithm is good, and you distribute the work efficiently (so that the same node searches the same position each time it is searched) then this becomes less of an issue. This is all common technique in distributed search, by the way... > >My move ordering already *only* for <= alfa nodes gets 1% worse and >several % for cutoff nodes. > >I do not know numbers for crafty here, but if your move ordering >statistics are the same, then imagine what 1% is at a depth >of 16 ply for crafty. You search plies less! Not in my search space. 1% worse move ordering will not kill the search at all. 10% will hurt. 20% will really hurt. and there are ways to keep it under control by doing intelligent workload distribution, as I mentioned before.
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.