Re: Thread discussion - Mailing list pgsql-hackers
From | Dann Corbit |
---|---|
Subject | Re: Thread discussion |
Date | |
Msg-id | D90A5A6C612A39408103E6ECDD77B82920D049@voyager.corporate.connx.com Whole thread Raw |
In response to | Thread discussion (Bruce Momjian <pgman@candle.pha.pa.us>) |
Responses |
Re: Thread discussion
|
List | pgsql-hackers |
> -----Original Message----- > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > Sent: Friday, July 05, 2002 7:59 PM > To: PostgreSQL-development > Subject: [HACKERS] Thread discussion > > > There was an interesting thread/process discussion in the gproff > Slashdot discussion: > > > http://slashdot.org/article.pl?sid=02/07/05/1457231&mode=neste d&tid=106 This guy had interesting comments: http://slashdot.org/~pthisis/ Especially this comment: http://slashdot.org/comments.pl?sid=35441&cid=3829377 ================================================================== Which is pretty much pointless MS bashing and incorrect. From the news:comp.programming.threads FAQ: Q147: Thread create timings Matthew Houseman writes: Thought I'd throw this into the pyre. :) I ran the thread/process create stuff on a 166MHz Pentium (no pro, no mmx) under NT4 and Solaris x86 2.6: NT spawn 240s 24.0 ms/spawn Solaris spawn (fork) 123s 12.3 ms/spawn (incl. exec) Solaris spawn (vfork) 95s 9.5 ms/spawn (incl. exec) Solaris fork 47s 4.7 ms/fork Solaris vfork 0.37 ms/vfork (37s/100000) NT thread create 12s 1.2 ms/create Solaris thread create 0.11 ms/create (11s/100000) As you can see, I tried both fork() and vfork(). When doing an immediate exec(), you'd normally use vfork(); when just forking, fork() is usually what you want to use (or have to use). Note that I had to turn the number of creates up to 100000 for vfork and thread create to get better precision in the timings. To remind you, here are greg's figures (on a Pentium MMX 200MHz): >NT Spawner (spawnl): 120 Seconds (12.0 millisecond/spawn) >Linux Spawner (fork+exec): 57 Seconds ( 6.0 millisecond/spawn) > >Linux Process Create (fork): 10 Seconds ( 1.0 millisecond/proc) > >NT Thread Create 9 Seconds ( 0.9 millisecond/thread) >Linux Thread Create 3 Seconds ( 0.3 millisecond/thread) Just for fun, I tried the same thing on a 2 CPU 170MHz Ultrasparc. I leave it to someone else to figure out how much of this is due to the two CPUs... :) Solaris spawn (fork) 84s 8.4 ms/spawn (incl. exec) Solaris spawn (vfork) 69s 6.9 ms/spawn (incl. exec) Solaris fork 21s 2.1 ms/fork Solaris vfork 0.17 ms/vfork (17s/100000) Solaris thread create 0.06 ms/create (6s/100000) =================================TOP=============Q148: Timing Multithreaded Programs (Solaris) From: sullivan@aisg20a.erim.org (Richard Sullivan) >I'm trying to time my multithreaded programs on Solaris with multiple >processors. I want the real world running time as opposed to the total >execution time of the programming because I want to measure speedup versus >sequential algorithms and home much faster the parallel program is for the user. Bradly, Here is what I wrote to solve this problem (for Solaris anyway). To use it just call iobench_start() after any setup that you don't want to measure. When you are done measuring call iobench_end(). When you want to see the statistics call iobench_report(). The output to stderr will look like this: Process info: elapsed time 249.995 CPU time 164.446 user time 152.095 system time 12.3507 trap time 0.661235wait time 68.6506 pfs major/minor 3379/ 0 blocks input/output 0/ 0 65.8% CPU usage The iobench code is included in the program sources on: index.html. =================================TOP============= My opinion is that PostgreSQL does not have to exclusively fork() or exclusively thread. As Spike Lee said: "Always do the right thing."
pgsql-hackers by date: