On Thu, Oct 21, 2010 at 6:04 PM, Darren Duncan <dar...@darrenduncan.net>wrote:

> Aaron Sherman wrote:

> Things that typically precipitate threading in an application:
>>   - Blocking IO
>>   - Event management (often as a crutch to avoid asynchronous code)
>>   - Legitimately parallelizable, intense computing
>> Interestingly, the first two tend to be where most of the need comes from
>> and the last one tends to be what drives most discussion of threading.

> The last one in particular would legitimately get attention when one
> considers that it is for this that the concern about using multi-core
> machines efficiently comes into play.

That sounds great, but what's the benefit to a common use case? Sorting
lists with higher processor overhead and waste heat in applications that
traditionally weren't processor-bound in the first place?

Over the past 20+ years, I've seen some very large, processor-bound
applications that could (and in some cases, did) benefit from threading over
multiple cores. However, they were so far in the minority as to be nearly
invisible, and in many cases such applications can simply be run multiple
times per host in order to VERY efficiently consume every available

The vast majority of my computing experience has been in places where I'm
actually willing to use Perl, a grossly inefficient language (I say this,
coming as I do from C, not in comparison to other HLLs), because my
performance concerns are either non-existent or related almost entirely to
non-trivial IO (i.e. anything sendfile can do).

>  The first 2 are more about lowering latency and appearing responsive to a
> user on a single core machine.

Write me a Web server, and we'll talk. Worse, write a BitTorrent client that
tries to store its results into a high performance, local datastore without
reducing theoretical, back-of-the-napkin throughput by a staggering amount.
Shockingly enough, neither of these frequently used examples are

The vast majority of today's applications are written with network
communications in mind to one degree or another. "The user," isn't so much
interesting as servicing network and disk IO responsively enough that
hardware and network protocol stacks wait on you to empty or fill a buffer
as infrequently as possible. This is essential in such rare circumstances

   - Database intensive applications
   - Moving large data files across wide area networks
   - Parsing and interpreting highly complex languages inline from
   data received over multiple, simultaneous network connections (sounds like
   this should be rare, but your browser does it every time you click on a

Just in working with Rakudo, I have to use git, make and Perl itself, all of
which can improve CPU performance all they like, but will ultimately run
slow if they don't handle reading dozens of files, possibly from multiple IO
devices (disks, network filesystems, remote repositories, etc) as
responsively as possible.

Now, to back up and think this through, there is one place where multi-core
processor usage is going to become critical over the next few years: phones.
Android-based phones are going multi-core within the next six months. My
money is on a multi-core iPhone within a year. These platforms are going to
need to take advantage of multiple cores for primarily single-application
performance in a low-power environment.

So, I don't want you to think that I'm blind to the need you describe. I
just don't want you to be unrealistic about the application balance out

 I think that Perl 6's implicit multi-threading approach such as for
> hyperops or junctions is a good best first choice to handle many common
> needs, the last list item above, without users having to think about it.
>  Likewise any pure functional code. -- Darren Duncan

It's very common for people working on the design or implementation of a
programming language to become myopic with respect to the importance of
executing code as quickly as possible, and I'm not faulting anyone for that.
It's probably a good thing in most circumstances, but in this case, assuming
that the largest need is going to be the execution of code turns out to be a
misleading instinct. Computers execute code far, far less than you would
expect, and the cost of failing to service events is often orders of
magnitude greater than the cost of spending twice the number of cycles doing

PS: Want an example of how important IO is? Google has their own multi-core
friendly network protocol modifications to Linux that have been pushed out
in the past 6 months:


They had to do this because single cores can no longer keep up with the

Reply via email to