Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid

Re^3: Perl 5 Optimizing Compiler

by chromatic (Archbishop)
on Aug 14, 2012 at 16:59 UTC ( #987413=note: print w/replies, xml ) Need Help??

in reply to Re^2: Perl 5 Optimizing Compiler
in thread Perl 5 Optimizing Compiler

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.

Replies are listed 'Best First'.
Re^4: Perl 5 Optimizing Compiler
by bulk88 (Priest) on Aug 14, 2012 at 17:37 UTC
    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?
      What stops perl from using alloca, where possible, today?

      Some combination of the need to box everything into SVs, non-linear control flow, and lack of escape analysis.

      you want C stack allocated SVs?

      It'd be nice to have something slimmer and simpler than a SV.

      are you referring to RISC cpus with dozens of registers and keeping entire structs split across registers?

      The AMD64 architecture (or whatever it's called) has plenty more registers than the preceding 32-bit x86 architecture, but even keeping a couple of commonly used parameters in registers throughout a function is going to be cheaper than copying them in and out of memory.

      I believe that rewriting Parrot's op dispatcher in assembly to keep the program counter and interpreter in registers would offer a sizable improvement in op dispatch (not that that's anything close to Parrot's bottleneck).

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://987413]
[shmem]: you can break up the chain MP3::Tag->new($_)- >interpolate("\%S ") and test whether MP3::Tag->new($_) is true
[Lady_Aleena]: shmem, no to deletion.
[shmem]: can't help you there since that song is not on my bench
[Lady_Aleena]: shmem, I need to look at MP3::Tag to see how to get the date from one song.
shmem sticks himself into the envelope. gn.(1<<3) all

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (6)
As of 2017-04-23 22:19 GMT
Find Nodes?
    Voting Booth?
    I'm a fool:

    Results (432 votes). Check out past polls.