|Problems? Is your data what you think it is?|
Re^4: Perl 5 Optimizing Compiler, Part 9: RPerl.org & The Low-Magic Perl Commandmentsby Will_the_Chill (Pilgrim)
|on Nov 13, 2013 at 02:02 UTC||Need Help??|
You appear to be repeating yourself:
Re: Perl 5 Optimizing Compiler, Part 9: RPerl.org & The Low-Magic Perl Commandments
And this is very much what has made some of the truly-innovative “hacks,” like Moose, be so successful and widely-accepted. It was “a significant improvement” that you could take advantage of with relatively low business risk. It’s not simply that you can use Moose;. It’s every bit as much, if not much-more, that you can also say: no Moose;. You can mix the old with the new.
SEEMS EQUIVALENT TO
Re^3: Perl 5 Optimizing Compiler, Part 9: RPerl.org & The Low-Magic Perl Commandments
“why t’hell was Moose so successful, when it is a Wart on top of a Hack on top of a Bunion to try to make Perl-5 the object-oriented language that it never was, and never was intended to be?” The short answer was that you could use Moose; to put on your Super Suit, and-d-d-d... that you could utter no Moose; to take it off again. All of which enabled you to make Useful Improvements To™ “the garbage what you were stuck with” without “starting over.”
I've already answered this question to you and others in this thread, so I'm just going to start copy-and-pasting until y'all start actually reading my responses. Here you go!
Re^2: Perl 5 Optimizing Compiler, Part 9: RPerl.org & The Low-Magic Perl Commandments
Now you're just messing with me, right? I've explicitly and clearly stated this 3 times in this thread alone! Come on, man, get with it. To YET AGAIN quote myself:
Also, we can use the "no magic;" pragma to turn off magic for 1 subroutine at a time, which means we can mix low-magic RPerl code (fast) with high-magic Perl code (maybe less fast), giving us the best of both worlds!
As I've stated already, you can mix compiled low-magic code with normal non-compiled high-magic code.
1. We can mix low-magic code with high-magic code.
2. We can add back in all the high-magic components after we've got RPerl v1.0 working with the low-magic components.
Now, on to your point about the supreme importance of software returning the correct results. I totally agree. That's why we have test suites. So, we make sure RPerl passes all low-magic test cases and thus "prove" (to borrow your term) that RPerl will run your low-magic code correctly.
I never said that source code change is free. It is, in fact, due to the large cost of source code change that I am writing a new compiler to automate it for me as much as possible. I don't ever want to have to change my source code because it is not fast enough, I'll have RPerl take care of the speed for me.
You say that compiler-induced improvements are small, this is patently incorrect. Early benchmarks show RPerl's Perl data mode runs 7 times faster than pure Perl, and RPerl's C/C++ data mode runs 199 times faster than pure Perl. You say the only way to gain significant improvements is to change the algorithm, which is also patently incorrect. You need only STOP USING SO MUCH DANG MAGIC. Please do your homework!
RPerl Performance Benchmarks
Sorry friend, but you're WRONG AGAIN.