in reply to Re^3: Perl 5 Optimizing Compiler, Part 9: RPerl.org & The Low-Magic Perl Commandments
in thread Perl 5 Optimizing Compiler, Part 9: RPerl.org & The Low-Magic Perl Commandments
Dave,
You win another brownie point! I did not strongly enough ban non-variable non-slice lvalues, the commandments have been updated yet again thanks to your sharp eye!
LMPC #20. Thou Shalt Use Scalars, Arrays, Hashes, Filehandles, & Mundane Lvalues (Variables & Slices)
LMPC #21. Thou Shalt Not Use Typeglobs, Code References, Weak References, Or Magic Lvalues (Builtins, Non-Variables, Non-Slices, etc)
I must disagree with your comment about not-using-other-people's-maybe-tied-vars, commandment #3 says not to use non-PBP code, which includes code-with-tied-vars written by either you _or_ somebody else.
LMPC #3. Thou Shalt Not Use ... Non-PBP Code ...
My previous post (Perl 5 Optimizing Compiler, Part 8: The Book Of RPerl) was made over 6 weeks ago, surely that's been enough time for your strength to return? ;-)
I think your questions about RPerl are generally answered in The RPerl FAQ, clearly linked at the very top of the Part 9 original post. Still, to answer your question specifically, the point of RPerl is to create an optimizing Perl 5 compiler. To achieve this, RPerl will initially remove all magic from Perl 5 and create a "restricted" (like RPython) subset of the Perl 5 language which can be compiled directly to C/C++ code, which is itself 100% compatible with, and equivalent to, the original Perl 5 code. This is implemented in RPerl by generating specially-crafted C/C++ code that can be fed through Inline::C(PP) and tie back into Perl 5 via XS. Once we have RPerl working with low-magic Perl 5 code, we can start selectively adding back in the magic components 1-by-1, retaining the ability to turn off all magic at any time to keep the pure speed boost of low-magic compiled code. As I've stated already, you can mix compiled low-magic code with normal non-compiled high-magic code.
To quote myself from my most immediately previous response to you, "Note, my use of the term 'magic' refers to both the specific so-named magic bits attached to Perl data structures, as well as Perl's wacky/weird/complex operations in general." You're right in pointing out that the magic bits attached to the Perl data structures are only 1 part of the "magic" that needs to be turned off to achieve massive performance benefits. This is why there are more commandments under the "Operations" section than the "Data" section.
Perling,
~ Will
You win another brownie point! I did not strongly enough ban non-variable non-slice lvalues, the commandments have been updated yet again thanks to your sharp eye!
LMPC #20. Thou Shalt Use Scalars, Arrays, Hashes, Filehandles, & Mundane Lvalues (Variables & Slices)
LMPC #21. Thou Shalt Not Use Typeglobs, Code References, Weak References, Or Magic Lvalues (Builtins, Non-Variables, Non-Slices, etc)
I must disagree with your comment about not-using-other-people's-maybe-tied-vars, commandment #3 says not to use non-PBP code, which includes code-with-tied-vars written by either you _or_ somebody else.
LMPC #3. Thou Shalt Not Use ... Non-PBP Code ...
My previous post (Perl 5 Optimizing Compiler, Part 8: The Book Of RPerl) was made over 6 weeks ago, surely that's been enough time for your strength to return? ;-)
I think your questions about RPerl are generally answered in The RPerl FAQ, clearly linked at the very top of the Part 9 original post. Still, to answer your question specifically, the point of RPerl is to create an optimizing Perl 5 compiler. To achieve this, RPerl will initially remove all magic from Perl 5 and create a "restricted" (like RPython) subset of the Perl 5 language which can be compiled directly to C/C++ code, which is itself 100% compatible with, and equivalent to, the original Perl 5 code. This is implemented in RPerl by generating specially-crafted C/C++ code that can be fed through Inline::C(PP) and tie back into Perl 5 via XS. Once we have RPerl working with low-magic Perl 5 code, we can start selectively adding back in the magic components 1-by-1, retaining the ability to turn off all magic at any time to keep the pure speed boost of low-magic compiled code. As I've stated already, you can mix compiled low-magic code with normal non-compiled high-magic code.
To quote myself from my most immediately previous response to you, "Note, my use of the term 'magic' refers to both the specific so-named magic bits attached to Perl data structures, as well as Perl's wacky/weird/complex operations in general." You're right in pointing out that the magic bits attached to the Perl data structures are only 1 part of the "magic" that needs to be turned off to achieve massive performance benefits. This is why there are more commandments under the "Operations" section than the "Data" section.
Perling,
~ Will
In Section
Meditations