Re^2: Behold! The power of recursion.

It is worth noting that while an iterative solution will almost inevitably run faster than a recursive solution, a good recursive solution is often quite terse.

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...

Comment on Re^2: Behold! The power of recursion.

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]
Re^4: Behold! The power of recursion. by jordanh (Chaplain) on Oct 18, 2004 at 11:38 UTC
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]
Re^5: Behold! The power of recursion. by tachyon (Chancellor) on Oct 18, 2004 at 22:19 UTC
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]
Re^6: Behold! The power of recursion. by jordanh (Chaplain) on Oct 19, 2004 at 01:03 UTC
Re^7: Behold! The power of recursion. by tachyon (Chancellor) on Oct 19, 2004 at 04:02 UTC


Perl: the Markov chain saw
	PerlMonks