in reply to Re^3: Are monks hibernating?
in thread Are monks hibernating?

For speed you do have to go to C or assembler

You certainly don't have to drop that far. I certainly wouldn't entertain doing much of anything in a language that doesn't support automatic memory management. And there are plenty of languages that do that can match the performance of C. Or even exceed it for some applications.

Nip over to The Great Computer Language Shootout to see what I mean. Take a look at Perl's lousy showing in the recursive Benchmark for what I mean about subroutine/method performance.

The lack of tail recursion optimisation accounts for some, but by no means all of the problem. There is a substantial overhead in simple calling a subroutine, which effectively penalises the use of subroutines for abstraction unless they do a fairly substantial amount of work to amortise the overheads. Once you move to using OO, you add another bunch of overheads in class lookup; dereferencing instance vars; inheritance resolution; et al. And OO encourages the use of small methods. If you implement a nicely architected solution, it runs like a dog.

Maybe that's a necessary penalty for the benefits of using a dynamic language, but even without jit, Java seems to do a whole lot better.

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^5: Are monks hibernating?
by shmem (Chancellor) on Feb 15, 2007 at 15:27 UTC
    Take a look at Perl's lousy showing in the recursive Benchmark for what I mean about subroutine/method performance.

    Well, lousy verbose coding is a big issue here, too. Removing unnecessary allocation of variables and explicit return calls where possible, and replacing the named subs with coderefs 

    # The Computer Language Shootout
# http://shootout.alioth.debian.org/
# recursive test, by Andreas Koenig, Sep 24 2006

### Uses temp variables to help perl free memory earlier

use strict;
my($Ack,$Fib,$Tak);
$Ack = sub
{
        my ($x, $y) = @_;

        return $y + 1         if $x == 0;
        return $Ack->($x - 1, 1) if $y == 0;

        $Ack->($x - 1, $Ack->($x, $y - 1));
};

$Fib = sub
{
        my ($n) = @_;

        return 1 if $n < 2;

        $Fib->($n - 2) + $Fib->($n - 1);
};

$Tak = sub
{
        my ($x, $y, $z) = @_;
 
        if ($y < $x) {
          my $z1 = $Tak->($x - 1.0, $y, $z);
          my $z2 = $Tak->($y - 1.0, $z, $x);
          my $z3 = $Tak->($z - 1.0, $x, $y);
          return $Tak->($z1, $z2, $z3);
        } else {
          return $z;
        } 
};

my $n = ($ARGV[0] || 0) - 1;
printf "Ack(%d,%d): %d\n",
        3, $n + 1, $Ack->(3, $n + 1);
printf "Fib(%.1f): %.1f\n",
        28.0 + $n, $Fib->(28.0 + $n);
printf "Tak(%d,%d,%d): %d\n",
        $n * 3, $n * 2, $n, $Tak->($n * 3, $n * 2, $n);
printf "Fib(%d): %d\n", 
        3, $Fib->(3);
printf "Tak(%.1f,%.1f,%.1f): %.1f\n",
        3.0,2.0,1.0, $Tak->(3.0,2.0,1.0);

    [download]

    gives a speed gain of roughly 25% - that's still slower than python, though...

    update: fixed wording

    --shmem 

    _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
[reply]
[d/l]
[reply]
Re^5: Are monks hibernating?
by talexb (Chancellor) on Feb 14, 2007 at 15:26 UTC

        For speed you do have to go to C or assembler

      You certainly don't have to drop that far. I certainly wouldn't entertain doing much of anything in a language that doesn't support automatic memory management.

    Well, that was a 'turning of the knob' thing -- how fast do you need to go? Can you write the thing in Perl and thing do some performance analysis to find the hot spots, then code those bits in C to get the speed up?

      Maybe that's a necessary penalty for the benefits of using a dynamic language, but even without jit, Java seems to do a whole lot better.

    Perhaps, but Java just seems to be so clumsy and backwards to me -- I love the simplicity of C. You know exactly where you are at all times. If necessary, I'd probably build some OO routines and 'pretend' to do C++; just pass Container objects around that hold onto the collection of objects that I'm working on.

    But this is a conversation that's tough to do over PM posts and morning coffee when it could be much more fun over a beer and face to face.

    Alex / talexb / Toronto

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

[reply]
      Java just seems to be so clumsy and backwards

      I don't like Java either, though I place most of the blame for that on the horribly incestuous standard libraries. But the separate compiler/interpreter; distributable bytecode; and runtime performance are nice.

      I'd probably build some OO routines and 'pretend' to do C++;

      You should definitely take a look at D. It does automatic memory management, OO, hashes, delegates, mixins, Perl-style fors and a whole lot more, Think C++ without the mess and verbosity. C without the pain. And it's fast.

      Now, if I could drop into Inline::D and transparently use Perl's hashes, objects and memory management...

      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.
[reply]
Re^5: Are monks hibernating?
by bart (Canon) on Feb 16, 2007 at 11:20 UTC
    I have no problem with the speed of Perl, in general. What I do care about, is its rather large memory footprint.

    For simple scripts of just a few lines of code, it matters that perl needs to load an executable of 1MB. Often, the load time is several times longer than the actual execution time. And that is something I just can't ignore.

[reply]

      That tends to suggest that you use a lot of short-lived, high-frequency (and possibly high-concurrency) and./or IO-bound apps? The archetypal example of which is dynamic http serving, though there are obviously many other server type applications that also fit the bill.

      It's for this type of application that mod_perl/fastcgi are designed to alleviate exactly the problems you describe. It's not hard to see how a similar approach could be used for non-http applications that fit this mode of operation. A daemon app that runs perpectually in the background with all the relevant code loaded and a small, fast front-end that simply fires the parameters to the daemon and retrieves the results.

      Most of my stuff runs in the exact opposite way. Long-lived and infrequently called apps performing cpu-intensive operations on large volumes of data and run for hours or days.

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

In Section Perl Monks Discussion