in reply to Threading vs perl

The Unix-world got by for years with out a serious threads implementation because the underlying hardware was a uni-processor, and 'threaded' was merely another synonym for 'time-sliced'. That world-view changed with the advent of the graphics-support processor, to offload the image rendering computations from the CPU. The world is changing again with the appearance of (relatively) cheap multi-processors. Once you have real hardware support for parallel execution streams, you _have_ to have some way of handling the synchronization/communications problem. If your problem is partitionable, with no inter-process interaction, you can throw multiple uni-processors at it. If it isn't partitionable, intra-process communications based on threads is manditory.

Consider your average large main-frame based organization, say My Bank, with over 5 Tbytes spinning and a 1% per month growth rate. Each second they have to support between five and fifteen thousand simultaneous transacations; each transaction can generate between 10 and 500 DB calls (mostly read disk accesses, but). Asynchrous I/O is the only way to go here, otherwise you get a end-to-end response time that is measured in fortnights.

Once upon a long time ago: ASP and JES3.... (Bring Back The Splat!)

----
I Go Back to Sleep, Now.

OGB

Replies are listed 'Best First'.
Re^2: Threading vs perl
by Eyck (Priest) on Jun 21, 2005 at 05:23 UTC

    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?

[reply]
      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.

[reply]

In Section Meditations