Re^4: Perl 5 Optimizing Compiler, Part 5: A Vague Outline Emerges

... a fast subset of perl...

The same thing came up in Perl 6 development more times than I could remember. Someone would show up and say "I have a very basic Perl 6 implementation on $virtual_machine that's n times faster than $other_implementation!" and it turns out they had implemented a calculator which did integer math.

No disrespect to Flavio or Perlito, but "fast subset" only starts to get interesting when that "subset" is more set than sub.

Comment on Re^4: Perl 5 Optimizing Compiler, Part 5: A Vague Outline Emerges

Replies are listed 'Best First'.
Re^5: Perl 5 Optimizing Compiler, Part 5: A Vague Outline Emerges by BrowserUk (Patriarch) on Sep 20, 2012 at 23:15 UTC
It already is. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. RIP Neil Armstrong	[reply]
Re^6: Perl 5 Optimizing Compiler, Part 5: A Vague Outline Emerges by chromatic (Archbishop) on Sep 20, 2012 at 23:31 UTC
... except for the things that make Perl 5 slow, like tie and overload and AUTOLOAD, and other things that real programs tend to rely on like CPAN and XS and timely destruction and variable aliasing and Unicode and BEGIN and caller context. Like I said, "subset". Again, I like Perlito and I want to see it succeed, but its current performance numbers demonstrate that the subset of Perl that isn't exceedingly difficult to optimize can be implemented with pretty good efficiency. That's all.	[reply]
Re^7: Perl 5 Optimizing Compiler, Part 5: A Vague Outline Emerges by BrowserUk (Patriarch) on Sep 21, 2012 at 00:29 UTC
like tie and overload and AUTOLOAD, What percentage of Perl code uses those things? 5%? 10%? What if (can't believe I'm using that phrase), you have two sets of opcodes. The existing one that deals with those things; and another that doesn't. The latter (say) 2 times faster and the former same speed as now. Does 90%/2 + 10%/1 = 55% mean anything? Do the decisions about magic have to be made at runtime by every opcode on every scalar? Or is it possible to decide at (say) sub dispatch time, that none of the args are magical; and the sub does nothing magical to them, so this call to this sub with these parameters can be dispatched to the fast path. And if at any point down the call chain from there, a sub is called that applies magic to an aliased input; or returns a magical return value; then it returns back to the slow path? With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. RIP Neil Armstrong	[reply]