Author: Robert Hyatt
Date: 13:44:44 05/30/04
Go up one level in this thread
On May 30, 2004 at 16:19:09, Vincent Diepeveen wrote: >On May 30, 2004 at 16:15:54, Robert Hyatt wrote: > >You are denying tested data? When _you_ provide the data? :) My speedup = 1.0 on a dual. :) Null-move makes it impossible to get a decent parallel speedup on today's engines... My program runs slower on an opteron than on a 2.8 xeon. :) Yes, I suppose I distrust your test data. It doesn't match the data given to me by AMD engineers. By my own testing on the opteron I used in CCT6. Etc... But then again, your data _never_ matches mine. And mine generally turns out to be correct as others verify it... Of course you _could_ just do a google search and look at some of the info on the AMD opteron MMU operation, the 4-level map they use, etc... But perhaps that is too difficult? When nobody can reproduce your data, and everybody reproduces mine, go figure... > >>On May 30, 2004 at 15:41:30, Vincent Diepeveen wrote: >> >>>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? >> >>Never said it was. I _did_ say that if you blow out the TLB on the K7 and on >>the Opteron, the average access times are close. >> >>raw latency on opteron is about 70ns to do _one_ memory read. To read a random >>access word, where the TLB fails, requires 5 memory reads. No way to avoid it, >>and it is going to cost 350ns. _period_. On the K7, average latency is about >>125ns to do _one_ memory read. To read a random access word, where the TLB >>fails, requires 3 memory reads. Or about 375ns. >> >>Those are _real_ numbers, reported by _many_ people including AMD. >> >> >>I have no idea what your program above does, and really don't care. But the >>opteron has a much bigger TLB, if you don't blow it out by referring to at least >>2048 different pages, then you are not comparing apples to apples. Opteron has >>1024 TLB entries. Enough to efficiently address 4 megs of RAM (1024 * 4kb >>pages). Or if your O/S is smart enough, 2 gigs of ram with 1024 entries * 2M >>page size. >> >>But for true non-TLB assisted random accesses, it is 350ns period. There is >>absolutely no way to avoid the 4-level page translation lookup stuff. Opteron >>ends up doing almost twice as many memory accesses as the K7. Of course it can >>2^48 virtual addresses, and 2^40 real addresses in its present form so it has >>some advantages... >> >> >>> >>>>>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 :) >> >> >> >>Don't have to move blocks of a few megabytes. Just generating moves is enough >>to take advantage of sequential reads... >> >> >> >> >>> >>>> >>>> >>>> >>>> >>>>> >>>>>>>>> >>>>>>>>>>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.