RoboProg's / Software Development
Really? Better  in what situation?
Perl is the fastest! No, Java is the fastest! What I really meant to say is, C is the fastest! Would you believe that all of these answers are correct, under the right circumstances? Of course you would. (but which circumstances?)
A while back, I put together a test to compare forking and threading, using several implementations. I recently expanded my choice of languages a bit, as well as adding an option to run the entire task set sequentially, just to get an idea how each language would handle a batch. Keep in mind that the bulk of the "work" done by these demo programming examples is creating / updating / discarding strings, just like most real business applications, rather than calculating fibonacci sequences, prime number generation, supernova simulations, or tracking the path of a projectile from the BFG.
So, here are the scenarios I considered, as well as the language  that did the best in each category.
I have summarized the results below
(Perl + Sequential = 1,
0 = instant)
|Pentium D||C||Thread ||N/A|
|Pentium D||Perl||Thread ||106.05||816|
|Pentium D||Java||Fork ||N/A|
|Pentium D||Ruby||Thread ||4.13||31.8|
Each task was run 10,001 times , using the method (sequential; fork; thread) inticated. The median time of 5 trials is the time reported above.
Further details: The Atom is a "slow processor, fast memory bus" combination (1600 MHz CPU, 512 KB cache with 1024 MB of 533 MHz memory); while the Pentium-D is a "fast processor, slow memory bus" combination (3000 MHz CPU, 1024 KB cache with 1024 MB of 300 - 400 MHz memory -- I lost the papers on the RAM, so I am not completely sure of its unannounced speed). Also, I seem to have managed to burden each machine with additional crud since last spring, so they are now running a little slower. For the Atom, most of the slow down might be due to enabling the hyper-threading. For the Pentium-D, the change must be due to additional server bloat I've gratuitously installed. Nevertheless, these are the level, but bumpy, playing fields I have provided for each implementation.
Please feel free to download the source (and my logs) and see how these work on your system(s). I would like to know if there are any unexpected results on any much slower or faster systems.
Some parting thoughts: Generating a bunch of tasks, via fork or new threads, turns out to be a really bad way to handle incoming requests on a server. A better way  is to have a front end process which inserts commands/requests into a queue, which is itself dequeued by a small number of worker tasks, and another queue which communicates results back from the workers to the front end, or some variation on this theme. But that is not the subject matter for today's rant.
Note that there were no articles in October and November.