in reply to Re: Behold! The power of recursion.
in thread Behold! The power of recursion.

It's further worth noting that DigitalKitty's algorithm uses only simple tail recursion, which can be easily compiled to be as fast or faster than an iterative solution.

Although I'm no expert, I believe the compiler would actually have to be smarter to optimize your iterative solution compared to the tail recursive one. Making the inference that $lower and $higher are candidates for register variables is slightly easier to make in the tail recursive version as there is a tendency to use registers for the subroutine calls variables for low-arity functions.

I could be wrong there, but a good compiler could do about as well with either, I would bet.

Now, implementing full tail call elimination is trickier, but recognizing tail recursion in this case and performing the optimization is a fairly trivial thing to do. Of course, we are talking about perl code here, and perl does not perform this optimization...

Replies are listed 'Best First'.
Re^3: Behold! The power of recursion.
by tachyon (Chancellor) on Oct 18, 2004 at 04:10 UTC

    I believe

    Benchmark knows. 

    Benchmark: timing 1000000 iterations of iterative_c, iterative_p, recu
+rsive_c, recursive_p...
iterative_c:  1 wallclock secs ( 1.10 usr +  0.00 sys =  1.10 CPU) @ 9
+07441.02/s (n=1000000)
iterative_p: 19 wallclock secs (19.52 usr +  0.00 sys = 19.52 CPU) @ 5
+1234.76/s (n=1000000)
recursive_c:  1 wallclock secs ( 1.16 usr +  0.00 sys =  1.16 CPU) @ 8
+60585.20/s (n=1000000)
recursive_p: 36 wallclock secs (36.26 usr +  0.00 sys = 36.26 CPU) @ 2
+7576.32/s (n=1000000)
                Rate recursive_p iterative_p recursive_c iterative_c
recursive_p  27576/s          --        -46%        -97%        -97%
iterative_p  51235/s         86%          --        -94%        -94%
recursive_c 860585/s       3021%       1580%          --         -5%
iterative_c 907441/s       3191%       1671%          5%          --

    [download]
    Read more... (2 kB)
[reply]
[d/l]
[select]
      Benchmark cannot "know" what my hypothetical "good" compiler would do. Perhaps I'm optimistic about the state of compiler technology, but I see no reason why a good compiler wouldn't create the same code for both.

      In the interest of disclosure, what compiler and optimization levels were used in the C case above?

[reply]

        Benchmark cannot "know" what my hypothetical "good" compiler would do.

        And? It shows what *any* non hypothetical, can compile code now, real world useful compiler can do. Out in the real world hypothetical compilers producing theoretical code are less that totally useful. The results presented were for CL.EXE /O2 on a Win2K AMD K7 system. FWIW GCC does a significantly worse job of optimising the recursive code.

        By all means compile it with anything you like on any platform and present any evidence that supports your hypothesis. 

        [root@devel3 root]# ./test.pl
Benchmark: timing 1000000 iterations of iterative_c, iterative_p, recu
+rsive_c, recursive_p...
iterative_c:  1 wallclock secs ( 0.42 usr +  0.00 sys =  0.42 CPU) @ 2
+380952.38/s (n=1000000)
iterative_p: 20 wallclock secs (18.34 usr +  0.00 sys = 18.34 CPU) @ 5
+4525.63/s (n=1000000)
recursive_c:  1 wallclock secs ( 0.60 usr +  0.00 sys =  0.60 CPU) @ 1
+666666.67/s (n=1000000)
recursive_p: 38 wallclock secs (37.75 usr +  0.00 sys = 37.75 CPU) @ 2
+6490.07/s (n=1000000)
                 Rate recursive_p iterative_p recursive_c iterative_c
recursive_p   26490/s          --        -51%        -98%        -99%
iterative_p   54526/s        106%          --        -97%        -98%
recursive_c 1666667/s       6192%       2957%          --        -30%
iterative_c 2380952/s       8888%       4267%         43%          --
[root@devel3 root]# gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)

        [download]

        cheers

        tachyon

[reply]
[d/l]

In Section Seekers of Perl Wisdom