Author: Vincent Diepeveen
Date: 12:41:30 05/30/04
Go up one level in this thread
On May 29, 2004 at 11:30:27, Robert Hyatt wrote: [snip] >See above. _no_ improvement. Raw latency on opteron is 1/2 the raw latency on >the K7 and Intel boxes. But mapping adds 2 extra memory accesses on the opteron >which does away with any actual advantage... > > > >> >>Softwarebenches like linbench and such pumping sequential a few gigabytes >>through the machine and then divide that by the search time. Then you have >>bandwidth. 1/bandwidth = latency they claim. > > >But that is the latency _you_ are quoting when you say opteron is 1/2 the >latency of the K7. In your worst-case it is _not 1/2. It is the same. Let's show you the tested facts K7 versus A64: Opteron single cpu 2.5 cas versus k7 cas 2.5. Note the k7 has all memory banks filled the opteron does *not* it just has a single dimm and is single channel and not even dual channel. So actually the latency is better than shown here. Quad opteron tested at 120 ns latency for a single cpu in fact when i tried a while ago. E:\dblat>dblat 300000000 Setting up a random access pattern, may take a while Finished Random access: 13.156 s, 131.560 ns/access Testing same pattern again Random access: 13.374 s, 133.740 ns/access Setting up a different random access pattern, may take a while Finished Random access: 13.343 s, 133.430 ns/access Testing same pattern again Random access: 13.265 s, 132.650 ns/access Sequential access offset 1: 0.250 s, 2.500 ns/access Sequential access offset 2: 0.484 s, 4.840 ns/access Sequential access offset 4: 0.875 s, 8.750 ns/access Sequential access offset 8: 1.781 s, 17.810 ns/access Sequential access offset 16: 3.375 s, 33.750 ns/access Sequential access offset 32: 6.265 s, 62.650 ns/access Sequential access offset 64: 6.516 s, 65.160 ns/access Sequential access offset 128: 7.000 s, 70.000 ns/access Sequential access offset 256: 7.938 s, 79.380 ns/access Sequential access offset 512: 9.188 s, 91.880 ns/access Sequential access offset 1024: 9.875 s, 98.750 ns/access Now the dual k7. all banks filled. a-brand memory. C:\tries>dblat 300000000 Setting up a random access pattern, may take a while Finished Random access: 36.266 s, 362.660 ns/access Testing same pattern again Random access: 36.406 s, 364.060 ns/access Setting up a different random access pattern, may take a while Finished Random access: 36.250 s, 362.500 ns/access Testing same pattern again Random access: 36.484 s, 364.840 ns/access Sequential access offset 1: 0.906 s, 9.060 ns/access Sequential access offset 2: 1.766 s, 17.660 ns/access Sequential access offset 4: 3.437 s, 34.370 ns/access Sequential access offset 8: 6.891 s, 68.910 ns/access Sequential access offset 16: 13.875 s, 138.750 ns/access Sequential access offset 32: 19.093 s, 190.930 ns/access Sequential access offset 64: 19.156 s, 191.560 ns/access Sequential access offset 128: 19.328 s, 193.280 ns/access Sequential access offset 256: 19.719 s, 197.190 ns/access Sequential access offset 512: 20.437 s, 204.370 ns/access Sequential access offset 1024: 21.860 s, 218.600 ns/access So practical difference for computerchess : 363 / 132 = 2.75 times faster latency for the opteron On die memory controller isn't that stupid nah? >>I would prefer calling that 'streaming latency'. It's full name officially is >>though 'cross bandwidth latency'. >> >>For chesssoftware that cross bandwidth latency is completely irrelevant. >Not if you need to move blocks of data... That would make a funny chessprogram moving blocks of a few megabyte memory for each node :) > > > > >> >>>>>> >>>>>>>The IID principle can also apply to some additional situations: >>>>>> >>>>>>>1) You have a hash move, but it's at depth-2 rather than depth-1. You can do >>>>>>>another IID layer in this case. >>>>>> >>>>>>In that case hashmoves works better of course. >>>>>> >>>>>>>2) Your fail-high hash move (for some engines the only possible kind of hash >>>>>>>move) fails low. Here you can do IID to get an alternative move. >>>>>> >>>>>>This is highly unlikely as your IID is at depth-i where i > 0. >>>>>> >>>>>>So most likely that hashmove is already from a position j >= depth - i, which >>>>>>makes IID a complete waste of your time. >>>>> >>>>>I meant an IID where the move that already failed low is thrown out. You want >>>>>the second-best move at the reduced depth. >>>> >>>>Use double nullmove. works better than IID and the first move you already get >>>>the best move :) >>> >>>The depth reduction is too high. More experiments are needed - but it would be >>>quite a coincidence if the best IID depth reduction just happened to be exactly >>>twice the best null move depth reduction. >>>> >>>>>Usually, you will waste a few nodes this way of course. The idea is to avoid-the >>>>>worst case scenario - of doing a full search through a bunch of other moves, >>>>>before finding the fail-high move. >>>> >>>>You can add 1000 conditions, but if something doesn't work in general, it won't >>>>work with 1000 conditions either. It just is harder to test in a way that >>>>objective and statistical significant conclusions are possible to statistical >>>>significant conclude whether it works or doesn't. >>>> >>> >>>In Rybka, IID works. Further, I haven't found any conditions which make it work >>>better, although I didn't try anything really fancy - just some comparisons >>>between current eval and the bound. Anyway, I read your reply to Tord, and will >>>keep retesting as the engine evolves. >> >>I didn't find a single condition under which it works for DIEP. It's just a >>waste of system time IMHO. > >Too bad. It works for me too. Used very selectively. > > > >> >>>>>> >>>>>>>And - as Tord mentioned - an IID search can be turned into the final >>>>>>>reduced-depth search, based on its result. >>>>>>>Vas >>>>>> >>>>>>Depth reducing the current search? >>>>>> >>>>>>Sounds like a rather bad idea to me. >>>>> >>>>>Well that's the million dollar question, isn't it? >>>> >>>>Seems there is 2 camps. >>>> >>>>I'm currently in the camp that i tried both worlds and concluded that depth >>>>reducing with nullmove is already enough. >>>> >>>>I can imagine last few plies some types of forward pruning somehow work. So far >>>>i could not prove that last though. >>>> >>>>I have a hard time believing that forward pruning in the entire tree is going to >>>>beat the nullmove pruning. >>>> >>>>We both are titled chessplayers, and i see simply that the few mistakes todays >>>>engines make, usually it is a dubious move caused by bugs in the forward >>>>pruning. >>>> >>>>Shredder is clearest example. >>> >>>Yes Shredder has some blind spots, but it can also search really deep, >>>especially when it's attacking. It's always nice to search deeper in the >>>critical lines. Anyway - I'm still checking out both camps. >> >>Well it's not so hard to add 7 plies to your search depth because your >>'selective search' might see 7 more (which in fact it does in diep). >> >>I prefer a 14 ply search depth with just nullmove above 18 with the chance that >>all your search lines are depth reduced and last few plies you supernullmove and >>in qsearch you lazy evaluate :) >> >>With forward pruning at every ply like shredder seems to do you only see faster >>what it sees anyway. What your eval doesn't see, search won't find either >>because you nonstop shorten such lines more than my '14 ply search depth' is >>doing. >> >>>The key is to think of the future - because it will soon be here. I really don't >>>care which search misses more tactics on some 32 bit 1 GHz machine ... >>>Vas >> >>Last time Shredder ran on a 1 Ghz machine at a world champs was in world champs >>London 2000, so those days are long gone. >> >>>> >>>>>Vas
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.