Author: Uri Blass
Date: 07:26:02 07/15/03
Go up one level in this thread
On July 15, 2003 at 09:44:34, Robert Hyatt wrote: >On July 15, 2003 at 02:36:27, Uri Blass wrote: > >>On July 15, 2003 at 00:37:32, Robert Hyatt wrote: >> >>>On July 14, 2003 at 18:38:51, Uri Blass wrote: >>> >>>>On July 14, 2003 at 16:35:05, Robert Hyatt wrote: >>>> >>>>>On July 14, 2003 at 16:32:17, Robert Hyatt wrote: >>>>> >>>>> >>>>>One thing more I should add. Cray Blitz searched about 20K on a single YMP >>>>>CPU. On the genius PC (486/33) it could not hit 100 nodes per second. For >>>>>a speed reference. >>>> >>>>I think that comparing the same program is misleading. >>>>I guess that a programmer who needs to write the same algorithm for 486/33 is >>>>going to write it in a different way. >>> >>>I think some of the things are simply _not_ going to be done. Too slow. >> >>What did you do in cray blitz that you believe that you cannot do on 486/33 >>because of speed? > >1. Quality mobility. Take the set of squares a piece directly attacks. >Instead of counting mobility = sum of squares, compute a "usefulness score" >for each square on the board, and compute mobility = sum of usefulness scores >for the squares attacked by that piece. It is computationally intensive, >but very fast on a vector machine. How do you calculate the usefulness score? I think that if calculating the usefulness score is not expensive then calculating the sum of usefulness score is also not very expensive. > >2. King safety. What pieces attack the area around the king, and how close >to the king are the squares that are attacked? What about indirect attacks >such as two rooks or rook/queen or bishop/queen in "battery"? How hard is it >to get defenders over to help? Again, all pretty straightforward to calculate, >but way slow. Unless you have vectors. I think that Ed attack tables are about similiar information and Rebel is not extremely slow. > >3. Hash table. We did 8/16 probes. But not to consecutive table entries. >We used another 9 bits from the hash signature to generate a random offset >to probe to, to better distribute the entries and avoid clustering/chaining. >Horribly slow on a PC. Absolutely free on a vector machine. This is not an evaluation decision sand I thought about evaluation. > >I'm sure there are other things I have missed. One comparison. On the >486/33, Cray Blitz ran at under 100nps. Well under. It varied from a low >of about 10, to a peak of maybe 75-80. Crafty on that same machine would >hit around 3.5K to 5K. Figure a speed difference of about 100X at least. > > >> >>I mean to things that you think that the price in term of speed is more than >>being 10 times slower because I assume that Crafty can hit at least 1000 nodes >>per second on 486(I have not 486 to test so it is only a guess). >> >>Uri > >It's primarily a matter of a "different approach". Vectors allow things that >are simply too slow with a PC, no matter what you try to do to make it >efficient. On a PC, sequential memory addresses are _way_ more efficient >than random accesses. On a vector machine this is not true at all. The first >word of any vector is the slowest to access. The next N are free. And the >next N don't have to be consecutive. They can be uniformly spaced through >memory, or randomly spaced. I understand that the machines are different but I am not convinced so easily that things are too slow without trying to do them on PC. there are a lot of things that it is possible to do faster by defining better data structures. Uri
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.