AM (@.) on 9/3/09 wrote:
---------------------------
>Gian-Carlo Pascutto (gcp@sjeng.org) on 9/3/09 wrote:
>---------------------------
>>AM (@.) on 9/3/09 wrote:
>>---------------------------
>>
>>>What you say is obvious and hardly related to what I say (same refers to anon's
>>>post, but I'm not sure with whom he argues); did you notice that I specifically
>>>mentioned apps which parallelize efficiently enough over 50-100 threads?
>>
>>"efficiently enough" is a pretty vague statement.
>
>efficiently enough in a purely practical sense (and the issue here is not #cores alone but choice of P54).
>
>>Anon explained this problem already better than I did so I won't comment further.
>
>He went off into general well-known things.

I thought they were general and well known, but apparently you don't grasp them. So, I tell you again, look up Amdahl's law. Yes, if a code has 1% of work done in serial, then it is absolutely impossible to get more than 100x speedup by paralellizing it.

A code that is reasonably efficient on 50 CPUs is no way guaranteed to work well on 500 CPUs. No way in hell. I work on a large and in many areas highly scalable software, and we get reports all the time of people wanting to run things on larger CPU counts and something goes splat. Unlike the nice theoretical Amdahl's law, what you typically see is performance increasing reasonably well, then incredibly bad negative scalability as you start saturating interconnects and heavily contending on a few cachelines that must be passed around between every CPU.

On-chip communication would be faster, but with hundreds of cores, there is a limit to how quickly a cacheline can get passed around between them all. It's not going to be pretty.