Re: PostgreSQL
[email protected] Thu, 2 Feb 2006 03:07:00 +0000
| Newsgroups | gmane.os.netbsd.devel.performance |
|---|---|
| Message-ID | <[email protected]> |
On Wed, 01 Feb 2006 20:16:57 -0500 Neil Conway <[email protected]> wrote: > On Thu, 2006-02-02 at 00:49 +0000, [email protected] 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.