In a way, it's useful to look at the various OS implementation of threads. Take, for example, Linux - not POSIX-compatible threads, but near enough. But, they're implemented pretty much as fork()s - that's where the non-POSIX-compatibility comes from (or, at least, the most part).

So, what you're actually doing is comparing the management of fork()s. fork(), especially when COW, is extremely lightweight, the main cost being the task switch and the increased complexity in scheduling.

Threading is, therefore, unlikely to gain much in terms of "raw speed". What it might gain, though, is increased readability of code - it's very obvious to see the thread of execution of a master thread, whereas following the various parents of fork()s is not always obvious. And, of course, on non-Unix derived OSes (Windows) threads may actually be quite a win, presuming that they are implemented fairly natively. My personal feeling, though, would be go with what makes the code work out best - if it's easier to understand with threads (esp. working with ex-Java/C++ programmers), that might be the best route.