in reply to Re: Approaches to concurrency
in thread Approaches to concurrency

threads come with a performance penalty that is severe enough

Can you quantify that penalty?


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Replies are listed 'Best First'.
Re^3: Approaches to concurrency
by JavaFan (Canon) on Feb 09, 2009 at 13:26 UTC
    Let me give just one datapoint:
    #!/usr/bin/perl use strict; use warnings; undef $/; my $code = <DATA>; my $RUNS = 10; my $no_threads = "/opt/perl/bin/perl-64"; my $threads = "/opt/perl/bin/thr-perl-64"; foreach my $perl ($no_threads, $threads) { my ($sum_r, $sum_u) = (0, 0); foreach my $runs (0 .. $RUNS) { my $res = `/usr/bin/time -p $perl -e '$code' 2>&1 `; next unless $runs; $sum_r += ($res =~ /real\s*(\d+\.\d+)/)[0]; $sum_u += ($res =~ /user\s*(\d+\.\d+)/)[0]; } printf "real: %.2f; user: %.2f\n", $sum_r / $RUNS, $sum_u / $RUNS; } __DATA__ use strict; use warnings; foreach (1 .. 1000) { my @arr; foreach (1 .. 1000) { push @arr, 1; } } __END__ real: 0.43; user: 0.43 real: 0.54; user: 0.54
    The short program, pushing '1' a thousand time on an array, takes about 25% more when threads are compiled in. Of course, YMMV.

      Thanks. On the basis of that test it does look to be quite a hit.

      It'd be quite instructive to see the differences in the code paths (at the C or assembler level), when you do push @arr, 1; between the two builds.

      I've never built a non-threaded Perl here as with no concurrency at all, it's almost pointless, but maybe I should and try to trace the code through.


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
Re^3: Approaches to concurrency
by perrin (Chancellor) on Feb 09, 2009 at 14:26 UTC
    Last time I ran it through perlbench, the difference was about 15%. Nevertheless, most Linux distros come with a threaded perl these days.
      Nevertheless, most Linux distros come with a threaded perl these days.
      Of course. Otherwise, they'll have to field complaints that threaded applications won't work.

      Whenever distro makers have to make a choice of "going for performance" or "going for broadest usage", they'll pick most of the times the latter. That will be more useful for most of their users, and hence, themselves.

      Having said that, I often compile my own perls. On my home boxes, and on all work boxes where perl performance, version, and/or configuration is important.

      I think Slackware was the last to do the switch. I'm pretty sure that Slack's perl wasn't threaded at least up to Slack 10.x.