Author: Robert Hyatt
Date: 13:10:51 09/25/02
Go up one level in this thread
On September 25, 2002 at 14:45:01, Vincent Diepeveen wrote: >On September 25, 2002 at 14:17:55, Robert Hyatt wrote: > >>On September 25, 2002 at 11:49:25, Russell Reagan wrote: >> >>>On September 25, 2002 at 08:10:06, Vincent Diepeveen wrote: >>> >>>>i cannot use select() at all as i limit myself to < 128 processor >>>>partitions then. >>> >>>Does WaitForSingleObject or WaitForMultipleObjects allow you to use more than >>>128 processors? >>> >>>>also i have no idea how to get it to work and whether it can do >>>>it 400 times a second instantly. >>> >>>See the problems Microsoft causes? They always have to be different (in a bad >>>evil kind of way). >> >> >>The very concept of synchronizing > 128 processes with such a system call >>defies any sort of logic I can think of. Doing it hundreds of times a second >>only guarantees horrible performance. Doing this every now and then would >>be ok. But not "400 times a second". There are other ways to eliminate that >>kind of stuff... > >the first 10 ply you get out of hashtable with just 1 processor obviously. > >Only after that the other 511 can join in. they manage themselves after >this. I don't want to let them poll while they are not searching. i have >no option there. You simply don't understand memory architecture yet. "polling" works perfectly. You wait on a pointer to become non-zero for example. While you are "polling" it takes _no_ bandwidth because the value lands in your local cache. All the cache controllers have to do is inform each other when something changes. IE this is how the Intel boxes work and they do that quite well. NUMA shouldn't change that basic idea... > >Just imagine how much bandwidth that takes away. > >The machine has 1 TB a second bandwidth. This 512p partition has >about half of that (machine has 1024p in total). If all these procs are >spinning around that will confuse the SN0 routers completely. Not with cache. > >From that 0.5 TB bandwidth about 0.25TB a second is reserved for harddisk >i/o. I can't use it. I use the other 600MB/s which the hub delivers for >2 processors for memory bandwidth. > >We all can imagine what happens if the hubs are only busy delivering reads >to the RAM. > >Right now each processor spins at its own shared memory variables, >that's simply *not* a good design idea for NUMA. It is not working for >any machine actually above 8 procs. It would work fine on a Cray with 32... > >Also shared memory buses you can't work with that design at all.
This page took 0.01 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.