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

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.

Replies are listed 'Best First'.
Re^4: Approaches to concurrency
by BrowserUk (Patriarch) on Feb 09, 2009 at 14:44 UTC

    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.