On Thu, Feb 02, 2006 at 03:07:00AM +0000, segv@netctl.net wrote:
> 
> To take advantage of such multicore CPUs, code needs to be decomposed into
> parallel regions, which can be executed in parallel. Threaded applications that
> have a fine grained design will benefit the most from such hardware. 

Multicore and multithreading have *nothing* in common with regard to
userland performance characteristics. For multicore CPUs it is pretty
much important whether or not multiprogramming or multithreading is
used, the only difference comes from a possible shared caches and that
would react the same way for both models.

SMT is intended for applications which are CPU bound, not memory bound.
Now please check the normal cache locality of database servers and you
will find out that it is the average worst case. In fact, CPUs like the
T1 can be very bad for database systems, because of the relative
bottleneck of the memory bus.

> The most important thing is: the application needs to be designed for fine
> grained concurrency from the start. Forking new processes is one way to achieve
> concurrency, but it doesn't scale and many applications don't actually fork
> that many children.

This is just rubbish. Just because a database forks doesn't have
anything to do with its internal concurrency. This is not about some
wishy-washy general purpose application class, but databases. They have
very different performance characteristics. The common serialisation
points in databases are IO operations, e.g. reading from disk to buffer,
preparing a (write) transaction and writing the buffer back to disk. For
this operations the SysV primitives in most cases are not much slower
nor are they the dominant factor. Compared to disk IO, it is
irrelevant. Heck, compared to the kernel buffering overhead, it is
irrelevant.

Joerg