Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses

Re: Perl 5 Optimizing Compiler

by rurban (Scribe)
on Aug 13, 2012 at 19:58 UTC ( #987198=note: print w/replies, xml ) Need Help??

in reply to Perl 5 Optimizing Compiler

Some of the mentioned performance and language changes were being outlined at the corehackers wiki.

Using XS for performance is silly, because the XS API is silly. One should not copy values to/from perl arrays for c stack arguments, perl should use the C stack as perl4 did for its argument passing. Larry just did not know the libffi or ffcall libraries then.

The pp_ API with the same perl stack API is also pretty unoptimizable, but this can be rewritten.

Replies are listed 'Best First'.
Re^2: Perl 5 Optimizing Compiler
by bulk88 (Priest) on Aug 14, 2012 at 16:12 UTC
    Why would the C stack be faster than the Perl stack? Both are an array of word sized numbers/pointers.

      In theory, a good optimizing compiler can avoid some of the stack manipulation necessary for naïve C function calls. (Obviously for those externally visible symbols where you must adhere to a platform ABI, you can't get away with this.) Even better, because the C stack isn't heap allocated, you can avoid malloc/free pairs for stack allocated values.

      You get at least two drawbacks from this. First, your calling conventions are going to end up looking a lot like C's calling conventions, so you have to go through wild contortions for things like exception handling, tail call optimizations, green threads, and continuations. Second, you're subject to the limitations of the C calling conventions, so maximum stack depth (see recursion and corecursion), thread stack limits, and the safety of extension code written with access to the C stack are concerns.

      You have to be a lot more clever to write optimizable code using the heap, but you get a lot of features from avoiding the C stack. To go really fast, you have to avoid copying a lot of memory around anyway, so my preference is to figure out how to optimize heap calls to avoid allocating and freeing unnecessary memory and to put everything into processor registers and keep it there.

        What stops perl from using alloca, where possible, today? you want C stack allocated SVs? are you referring to RISC cpus with dozens of registers and keeping entire structs split across registers?
      Because a stack access is 1. ~70 times faster then a heap access, 2. allocation is for free, 3. you do not need to clean up the stack, and 4. stack ptrs are thread safe. That's why normal programming languages use an ABI which puts parameters onto the stack and better align it properly to be able to use MMX. It's not only for recursion.

      Compare reading or writing at %ebp+8 against any absolute ptr. It's about 5 against 150 micro instructions.

      Stack accesses are also relative and hot and local, heap accesses usually not. Some heap ptrs are hot and cached, but you still have the cache overhead.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://987198]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (5)
As of 2018-05-25 11:48 GMT
Find Nodes?
    Voting Booth?