Author: Robert Hyatt
Date: 19:37:15 05/23/04
Go up one level in this thread
On May 23, 2004 at 21:32:56, Vincent Diepeveen wrote: >On May 22, 2004 at 14:18:54, Anthony Cozzie wrote: > >>>Who knows. I use threads on SMP. On NUMA. There is no significant reason not >>>to. And since Eugene's EGTB code is specifically designed for threads as well, >>>the gain by having a large shared LRU cache of table data is also worthwhile. >> >>Actually, I think there is a very good argument for using threads over >>processes, namely the new chip-multiprocessors due in year or two which will >>probably have a shared L2 cache. > >What is more important: fixing the weakest chain or improving a strong point? > >First of all CMP is not the same like SMT. So let's compare the right things. > >Sharing L2 cache serves a single purpose. In return you waste a lot of >instructions. So you already do not break even there. > >Secondly a major problem starts to get there when you have a big machine. > >Say a 32 node dual opteron. > >How to share code with a remote cpu? > >the only solution i know is MPI or cc-NUMA. MPI has exactly _nothing_ to do with "sharing code". MPI -> "Message Passing Interface". > >cc-NUMA is just a software emulation with the same effect like MPI with >exception that you do not rewrite your software when you are multiprocessor. cc-NUMA has _nothing_ to do with software. It has everything to do with the cache controller hardware and how shared data is kept coherent when more than one processor modifies the same memory address. That is what AMDs MOESI cache protocol is all about... Don't know how you jump off onto "cc-NUMA is just a software emulation with the same effect like MPI". That is simply meaningless gibberish. > >However if you are multithreaded then both cc-NUMA and MPI pose a problem. Vincent, you are simply rambling on about nonsense. MPI and "multi-threaded" do _not_ cause problems. I have students using threads to run 4 threads on each of the quad cluster nodes, they use MPI to communicate between the nodes. This has _zero_ to do with NUMA or anything else... > >So you need to write 2 parallel searches. 1 multiprocessor with MPI and 1 >multithreading. Jesus what nonsense... > >This where i take the cc-NUMA model and can run the current executable. > >Why do all that extra work when getting multithreaded? > a) overhead to extra pointers > b) you need to write 2 models > >Now let's take a look to a quad NUMA machine in 2014. > >Processors get faster and faster. Perhaps even 4 cores at 1 processor. > >So we speak about 16 processors. 12 of them are on the network so to say and 3 >of them are closeby. In short you have 12 problems with multithreading and 3 >advantages. > >What do you prefer? > Probably threads to share the gigabytes of executable code, rather than replicating it, for starters... >>I don't know how smart the OS is in terms of consistently scheduling threads on >>the same CPU. I know when I run things on my dual opteron at home it >>consistently bounces processes from CPU to CPU, which seems stupid even on an >>SMP system (still have to transfer all that data from cache to cache). >> >>anthony
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.