On Wed, Nov 18, 2009 at 9:20 AM, Jonathan Yu <jonathan.i...@gmail.com> wrote:
> Certainly I've found for tight loops with lots of calculations, XS/C
> is going to be faster. Why? Because it's compiled into machine code
> and executed directly on the chip. On the other hand, Perl is compiled
> into bytecode which is then executed by the Perl Virtual Machine.
That's one piece of it, but the other part is that any tight loop that
is creating and destroying Perl primitives picks a lot of overhead.
As an example, Vincent Pit just did some recent work in blead to
optimize "in-place" array reversal in void context:
@array = reverse @array;
When this pattern is detected, the optimization just fiddles the
internal pointers within the AV structure instead of reversing the
array to a temporary list and then assigning it back. Vincent
benchmarked it as several *orders of magnitude* faster (particularly
as the array size grows).
So creating/destroying Perl objects -- even just for things like
argument passing on the stack -- is part of the cost of the
flexibility of Perl. When that becomes a bottleneck in a tight loop,
that's when XS becomes a potential option.
That's not a knock on Perl -- that's just part of the design.
-- David
