Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

Re^2: Threading vs perl

by Eyck (Priest)
on Jun 21, 2005 at 05:23 UTC ( [id://468561]=note: print w/replies, xml ) Need Help??


in reply to Re: Threading vs perl
in thread Threading vs perl

I'm sorry, but the Un*x-world I've known has always been multi-processor, and the last decade it started turning into massively-multi-processor, so I don't quite follow you there

Desktop PCs, those used to be typically uni-processor, but you would be hard pressed to find un*x-based workstation without at least two CPUs (or at least additional socket for one).

When is intra-process communications based on threads manditory.? I was taught that with multi-CPU machines, threads are disadvantegous (because all of synchronisation necessary, when you move you process around, for example to another CPU, you need to keep it's memory ( cache ) synced, instead of keeping in sync only the data that the worker actually IS working on).

When did IPC::SysV, IPC or IPC::Msg drop out of favor?

Replies are listed 'Best First'.
Re^3: Threading vs perl
by tilly (Archbishop) on Jun 28, 2005 at 23:18 UTC
    You were taught correctly. For which reason good schedulers go out of their way to keep threads in a process on a single CPU.

    In fact SMP has a fundamental major flaw, which is that it does not scale. As you add more CPUs, each CPU spends a larger portion of its time waiting for all CPUs to come to attention so that one can do something which needs to avoid a race with any other. Eventually the useful work done by the next CPU is less than the amount of time it causes others to waste. This is the computer version of an organization where everyone spends all of their time in meetings. By breaking things into many smaller locks, and making sure that each CPU checks in more frequently, you can improve this. However this adds overhead, and you get diminishing returns. The best that I know of offhand is 128, and the last 64 CPUs don't add much.

    To really scale you need to move to NUMA (Non-Uniform Memory Architecture). In this architecture CPUs organize into groups, so when one needs others to synchronize it only needs some other CPUs to synchronize, reducing this locking considerably. This is the computer version of moving from a perfectly flat to a hierarchical organization.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://468561]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others romping around the Monastery: (6)
As of 2024-04-24 22:44 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found