There was a lady who insulted me recently. She was very pushy and demanding and I lost my temper and made an extremely sarcastic, damning response. Though those familiar with the situation claim that I owe her no apology, I still want to apologize the next time I see her. Regardless of whether or not she was offensive, I should at least be able to control my own behavior.

Yes, I sometimes lose my temper and when I do, I regret what I've said/done. Regardless of whether or not you regret what you have said, a simple, sincere apology can still do wonders for keeping the peace -- and a gracious individual does not demand an apology or acknowledgement. I've a lot of respect for you and your abilities, so I hope you don't take this as a personal attack, but I do think an apology would be a nice thing. By asking that your insult be taken in the context of Dominus' comment, you forego the opportunity to be gracious.

There are four issues raised by dominus' post and my response.

1. Are Perl's function calls slow?

   The archetypal test of function call performance is the Ackermann Function. Go here to see the list of other languages that out-perform Perl for function call performance. Many of those are fully pre-compiled languages. Many are not.

   For comparison purposes, look at straight forward implementations in Perl, with the same in Java.

   Perl:

           
       P:\test\MJD>ack1 9
       Ack(3,9): 4093
       78.843 83.671 0 0
   [download]

   Java:

   P:\test\MJD>timethis "c:javac ackermann.java && java ackermann 9"
   
   TimeThis :  Command Line :  c:javac ackermann.java && java ackermann 9
   TimeThis :    Start Time :  Fri Sep 02 22:01:28 2005
   
   Ack(3,9): 4093
   
   TimeThis :  Command Line :  c:javac ackermann.java && java ackermann 9
   TimeThis :    Start Time :  Fri Sep 02 22:01:28 2005
   TimeThis :      End Time :  Fri Sep 02 22:01:29 2005
   TimeThis :  Elapsed Time :  00:00:01.031
   [download]

   I've included the compilation and runtime for Java to even the score a little. JIT was not enabled.

   So 83.6 seconds for Perl, and 1.031 seconds for Java!

   Conclusion: Perl's function calls are slow.

2. Is "Avoiding function calls because they are slow ... an absurd response to performance problems"?.

   Anyone whom visited that Shootout page may have noticed that there are two supplementary versions of the Perl implementation of the Ackermann function, besides the one used in the main body of the tests.

   These both run vastly more quickly than the main one

   • Ack2.pl run 92x faster than the standard perl version
   • Ack3.pl runs 474x faster.

   How do they succeed in achieving this performance.

   Ack2.pl uses (dominus's own) Memoize module. But how does this work?

   Adding a couple of lines to the test case:

   use Memoize;
   memoize("Ack");
   my $count = 0;
   sub Ack {
       $count++;
       return $_[0] ? ($_[1] ? Ack($_[0]-1, Ack($_[0], $_[1]-1))
       : Ack($_[0]-1, 1)) : $_[1]+1;
   }
   
   my $NUM = $ARGV[0];
   $NUM = 1 if ($NUM < 1);
   my $ack = Ack(3, $NUM);
   print "Ack(3,$NUM): $ack";
   #print times;
   print "Ack() called $count times";
   [download]

   shows exactly how it achieves it's performance:

   P:\test\MJD>ack1 9
   Ack(3,9): 4093
   79.187 83.093 0 0
   Ack() called 11,164,370 times
   
   P:\test\MJD>ack2 9
   Ack(3,9): 4093
   0.046000
   Ack() called 12,294 times
   [download]

   The performance is achieved by avoiding making function calls! 12,294 -v- 11,164,370

   And how does Ack3.pl achieve it's further gain in performance?

   By in-lining the caching and thereby further reducing the number of function calls, by avoiding those that Memoize wraps around the memoized function!

   Indeed, a substantial portion of dominus' book, High Order Perl deals with the very subject of eliminating recursion (p.229–53, 348 (from the index)).

   Conclusion: Avoiding function calls as a means of improving performance *is not* "...an absurd response..." to poor performance.

3. Is "... the right response ... to try to fix the implementation" a feasible, practical suggestion?

   The number of people that have the required knowledge and expertise to dive into the perl sources to make this kind of change probably number in the low 10s.

   That's not to say that there isn't the possibility of scope for improvements. If you dump the assembler generated by an Inline C or XS function call and look at the number of times _Perl_get_context() is called in the prolog and epilog, there certainly seems to be the potential for some reduction. Of course, it may well be that a good optimising compiler succeeds in reducing some of the duplication, but that will vary from compiler to compiler and platform to platform.

   But a bunch of very clever guys have spent a good few years tuning the performance of Perl 5, and the idea that your average PerlMonk is going to do better than them any time soon, is .... (I'll leave the adjective to the individual reader to fill in).

   The idea that your average Perlmonk is likely to be able to go this route is overly optimistic at best. At worst, it is completely specious.

4. Does my characterisation (of dominus' characterisation of the very techniques that his own module and book exploit as "absurd"), as "academic hot air" constitute a grievous insult?

   Others will draw their own conclusions, but for my part, I think that the idea that your average PerlMonk could adopt the suggestion "to improve the implementation" *is* academic.

   In that regard, dominus' voicing that suggestion, given his knowledge, expertise and history of exploiting the very technique he decried, *is* "hot air".

   Can a factual statement, regardless of the wording, be "an insult"?

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.

Can a factual statement, regardless of the wording, be "an insult"?

Uh, yeah. "hot air" is an insult, no matter how you dress it up (except in ballooning). But to be fair, most of this last post would have made for a better response to the original reply.

Howdy!

There is a fair bit of misdirection there. Let's look a bit more closely at the sequence of statements.

Dominus offered his exposition in response to the "Streams.pm is slow" claim (more or less).

BrowserUK quoted a relevant line and asked a fair question.

Dominus quoted a piece of that and declined to have an opinion.

BrowserUK then quoted a different line from the first post and proffered the "hot air" remark. Note the change of context masquerading as a reply. That was sneaky.

Now you lay out a reply that you should have made much earlier in this thread that makes a substantive response to Dominus...at least through the first three points.

The last point then asks if the "hot air" remark constitutes a grevious insult. That question attempts to deflect by raising the bar. The initial insult came out of left field. You still don't do anything to make amends or even acknowledge that you gave insult. By being so obstinate (obdurate, even), you compound the insult.

You show your character clearly. It's not a pretty sight.

yours,
Michael

Does my characterisation (of dominus' characterisation of the very techniques that his own module and book exploit as "absurd"), as "academic hot air" constitute a grievous insult?

Grievous probably not. An insult?... hell yes.

Quite innocently. Its context is fairly meaty. Its use is not clearly pointed at a person, nor is it emphasized in any way. I take it's meaning to be "inconsistent with reason, logic, common sense". Its use comes as a conclusion to a logical sequence of statements that build on one another, leading to the conclusion that avoiding function calls because they are slow is an absurd response. I see reasoned exposition, not a one-liner poke-and-run.

You still avoid the issue...