Re^4: Perl 5 Optimizing Compiler

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

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?

Comment on Re^4: Perl 5 Optimizing Compiler

Replies are listed 'Best First'.
Re^5: Perl 5 Optimizing Compiler by chromatic (Archbishop) on Aug 14, 2012 at 17:52 UTC
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).	[reply]

Replies are listed 'Best First'.

Re^5: Perl 5 Optimizing Compiler
by chromatic (Archbishop) on Aug 14, 2012 at 17:52 UTC

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

[reply]

In Section Seekers of Perl Wisdom