Subject: Re: PostgreSQL
To: Neil Conway <neilc@samurai.com>
From: None <segv@netctl.net>
List: tech-perform
Date: 02/02/2006 03:07:00
On Wed, 01 Feb 2006 20:16:57 -0500
Neil Conway <neilc@samurai.com> wrote:

> On Thu, 2006-02-02 at 00:49 +0000, segv@netctl.net wrote:
> > 1. I was reading somewhere that PostgreSQL was not multithreaded. This can
> > have a significant impact if you have a busy database server. Multicore CPUs
> > designed for executing 10s and 100s of threads simultaneously are just
> > around the corner (Sun's T1 processors). So fine grained threaded
> > applications are the future.
> 
> Whether threads or processes are used to implement concurrency does not
> really affect how fine-grained the concurrency is. That is, I don't see
> how using multiple processes and fork() makes an application inherently
> less suitable to multicore servers than an application using threads.
> 
> -Neil
> 
> 

Both of you, Neil and Thor, have asked me why I think that fine grained
threaded applications will perform better. Here is why I think that:

http://www.sun.com/processors/UltraSPARC-T1/index.xml

Sun have released a new CPU, which is capable of running up to 32 concurrent
threads. I think soon everyone will follow the same path. Multicore CPUs are
becoming popular because increasing clock rate is becoming more difficult and
it generates too much heat. Also UltraSparc-T1 is designed for multithreaded
applications, i.e. it has hardware support built in for executing threads in
parallel and to keep the processor pipelines busy.

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. 

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. It's more the way they operate on data, i.e. sometimes data
can be processed in parallel, e.g. parsing HTTP headers, HTML files, etc. I
have a 4-CPU Sun machine, when using Firefox to browse webpages, only 1 CPU is
busy 100%, the rest are sitting pretty much idle. Here is a good example where
fine grained threading could improve performance by a large margin. Firefox
creates a seperate thread for each tab/window, but that's not good enough (I
can only browse one page at a time), it should use multiple threads when
parsing and rendering web pages, etc.