No problem

Post #123,300 by ben_tilly 10/29/03 2:27:10 PM Reply	No problem In other languages or environments, multi-threading would be the right solution. But Perl's historical philosophy is that the OS offers fork(), which gets the job done with no work for Perl. I would still call that the preferred way to work on Perl when the OS supports it. Besides which, forking architecturally scales better. I can just see you asking WTF I am talking about, so let me explain. Multi-threading is a much lighter-weight approach than forking. However multi-threading results in a far larger likelyhood of different threads needing simultaneous access to the same resources (eg memory). As you scale up, this quickly becomes a source of bottlenecks. That is why schedulers go out of their way to keep threads on the same CPU (or CPUs), which means that even with SMP, multi-threading won't distribute work as evenly as forking. It is an issue that becomes extremely relevant as soon as you try to distribute work with a clustering technology like [link\|http://www.mosix.org/\|MOSIX]. (They don't even try to handle multi-threaded applications.) And as [link\|http://lse.sourceforge.net/numa/\|NUMA] becomes more and more prevelant in high-end machines (which it will because NUMA scales far, far better than SMP), the benefits of a forking architecture quickly become obvious. A metaphor that I like is that a scalable solution is like an 18-wheeler, while the non-scalable one is often like a Porche. For getting around town, the non-scalable one is often easier and more fun. But if you need to get a few tons from one coast to the other... So yes, in an environment that supports both, multi-threading is faster. Forking can scale better. Choose whatever is appropriate. Cheers, Ben PS Disclaimer: This was posted by a weenie with a lot of theory and with current computation problems which scale just fine using ye basic load balancer... "good ideas and bad code build communities, the other three combinations do not" - [link\|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html\|Stefano Mazzocchi]
Post #123,305 by deSitter 10/29/03 2:42:45 PM Reply	Re: No problem This was an issue years ago - but with 1G of memory and 3GHz processors commonplace on workstations, heavy forking is a moot issue. I can see "last swap" competing with "uptime" for bragging rights :) You can also look at Windows NT and its bastard children - multi-threaded from day 1, butt-slow at real world problems. -drl
Post #123,334 by ben_tilly 10/29/03 5:13:13 PM Reply	The more you can do, the more they ask you to do The big toys that slugbug and Scott play with have a reason for existing. People buy them, take them to their limits, and wish that they had more. As for multi-threading being slow, talk to the good folks at Sun about that. Just because Linux 2.0-2.4 sucked at multi-threading, and just because NT has its problems, doesn't mean that multi-threading can't work well. You just have to do it well. (Linux 2.6 also should do it well. Along with scalability improvements, Sun is going to find itself outperformed farther up the scale...) Cheers, Ben "good ideas and bad code build communities, the other three combinations do not" - [link\|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html\|Stefano Mazzocchi]
Post #123,340 by admin 10/29/03 5:19:55 PM Reply	Absolutely. We're constantly maxing out that big machine. Incidentally, we don't exactly play with it... that's the production database machine. ;-) With respect to multi-threading, again absolutely. The threading in Linux is currently atrocious. The scheduling is bad (although there are patches) and the signal handling is completely broken. Tests I've done had Linux threading slower than Win2K by 20%, albeit without patching. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #123,306 by slugbug 10/29/03 2:43:11 PM Reply	this is an... ...eighteen wheeler scenario. Sounds like forking is the answer. Does this mean I will soon become a forking goddess? <smirk> Thanks for the help. Have folks jumping up and down on this one. -Slugbug
Post #123,335 by jb4 10/29/03 5:13:48 PM Reply	So, Perl assumes POSIX compliance in the OS, eh? Rather presumptious of it, doncha think? jb4 "There are two ways for you to have lower Prescription-drug costs. One is you could hire Rush Limbaugh's housekeeper ... or you can elect me President." John Kerry
Post #123,347 by ben_tilly 10/29/03 5:53:22 PM Reply	No See [link\|http://www.perldoc.com/perl5.8.0/pod/perlfork.html\|perlfork] for how Perl emulates forking on operating systems that don't support it. For a broader introduction to portability and Perl, read [link\|http://www.perldoc.com/perl5.8.0/pod/perlport.html\|perlport]. As usual, Perl's philosophy is to give you enough rope to hang yourself. Perl came from POSIX systems, it offers interfaces to POSIX-specific capabilities. But nobody is saying that you have to use them. And where they don't exist, Perl does its level best to do something reasonable instead. The result is that while it is trivial to write unportable Perl code, nearly all Perl code that you encounter is portable by default to all supported platforms. (Were it not so, then CPAN would never have succeeded.) Supported platforms may be found by scanning the PLATFORMS section of perlport above. Cheers, Ben "good ideas and bad code build communities, the other three combinations do not" - [link\|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html\|Stefano Mazzocchi]
Post #123,463 by jb4 10/30/03 2:06:32 PM Reply	Interesting, but looks like a bit of a kluge The fact that the emulator spawns threads instead of processes means that the desired protection between the fork-ed processes from each other does not exist. I am no Perl guru (hell, I barely know anything about it), but from a design standpoint, this means that any Perl script must be designed to the target platform...and I thought that was counter to what Perl was supposed to be about. (Yeah, Perl does not claim to be Java...but still....) jb4 "There are two ways for you to have lower Prescription-drug costs. One is you could hire Rush Limbaugh's housekeeper ... or you can elect me President." John Kerry
Post #123,472 by ben_tilly 10/30/03 2:48:22 PM Reply	It is a kludge It is meant as a workaround for features that the OS doesn't have. As for protection, the fact that each thread has its own interpreter, and interpreters do not by default share memory, means that most of the protection that you want is there. (The page that I pointed you had describes many of the things that don't get protected.) For the record, that multi-threading model was not intended to be used as a fork() emulation. Rather it was meant to make it possible for Perl to integrate well into IIS, which is multi-threaded. But given that they had the capability, the fork() emulation made sense. On Perl's design. Perl was not intended to be "about" anything. (OK, making easy things easy and difficult things possible...) It was designed as a general-purpose reporting tool for use on Unix, and kind of evolved. In the end Perl turned out to be highly portable, but that wasn't a design goal. Cheers, Ben "good ideas and bad code build communities, the other three combinations do not" - [link\|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html\|Stefano Mazzocchi]
Post #123,473 by deSitter 10/30/03 2:50:47 PM Reply	Re: It is a kludge There are (sigh, were) similar issue with getting things that were born under UNIX to live in the VMS world. -drl
Post #123,486 by ben_tilly 10/30/03 4:22:25 PM Reply	One of those things was Perl ;-) "good ideas and bad code build communities, the other three combinations do not" - [link\|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html\|Stefano Mazzocchi]
Post #123,489 by deSitter 10/30/03 4:36:04 PM Reply	Don't I know! I once downloaded and compiled it on a VAX which had Perl v.low on it :) -drl
Post #123,462 by Simon_Jester 10/30/03 2:06:03 PM Reply	Query: I've played a (small) amount with the multithreading That is why schedulers go out of their way to keep threads on the same CPU (or CPUs), which means that even with SMP, multi-threading won't distribute work as evenly as forking. on the bigger Sun boxes, and I don't remember having much difficulty utilizing the other processors on those boxes when I doing the multithreading. Memory issues were a problem. We utilized Sun's multi-threaded malloc, which helped. But, for our application, most of the memory accesses were tied to a particular thread - so our memory bottlenecks weren't too bad.
Post #123,469 by ben_tilly 10/30/03 2:39:39 PM Reply	That scheduler optimization is pretty recent IIRC "good ideas and bad code build communities, the other three combinations do not" - [link\|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html\|Stefano Mazzocchi]

Welcome to IWETHEY!