Subject: Re: multi-core software
From: rpw3@rpw3.org (Rob Warnock)
Date: Thu, 04 Jun 2009 20:38:24 -0500
Newsgroups: comp.lang.lisp
Message-ID: <up6dna1aq--N6rXXnZ2dnUVZ_hqdnZ2d@speakeasy.net>
André Thieme  <address.good.until.2009.july.27@justmail.de> wrote:
+---------------
| Kaz Kylheku schrieb:
| > You are dreaming if you think that there are any circumstances
| > (other than circumstances in which performance doesn't matter)
| > in which you don't have to concern yourself about the difference
| > between a uniprocessor and a 256 CPU machine.
| 
| What about 1 core vs. 2 cores?
+---------------

That's the biggest difference, but...

+---------------
| And 2 cores vs. 256 cores?
+---------------

As they say in the military, "Quantity has a quality all its own."  ;-}

Even Dekker's Algorithm might be a reasonable way to do mutual
exclusion with only 2 cores[1], but *no* single-lock solution is
going to work well for 256 cores. Even with hardware support [such
as LL/SC, say], if nothing else the "write invalidate" traffic from
the lock location is going to create a hot spot in the memory system.

Back at SGI, it was often the case that an app that worked very well
on a 64-CPU ccNUMA system fell over when the CPU count was raised to 256.
Ditto a working 256-CPU app when expanded to 1024-CPU.

Amdahl's Law <http://en.wikipedia.org/wiki/Amdahl%27s_Law> always
gets you, eventually...  ;-}  ;-}


-Rob

[1] O.k., so nobody is going to *seriously* consider using Dekker's
    Algorithm for user-mode programs these days, though I *have* used
    it successfully for simple interlocks between a single-CPU host
    computer and a "smart" DMA controller. [*Much* more efficient
    than interrupting the host, actually.]

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607