http://www.perlmonks.org?node_id=1062138


in reply to Re: 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

Howdy sundialsvc4,

I do applaud you for the non-anonymous remarks, even if I strongly disagree. :-)

...to reap what "benefits", exactly?

I thought by now the answer was obvious to everyone. YOUR CODE WILL RUN WAY FASTER.

Is this a cost that I can justify?

Sure, if you want YOUR CODE TO RUN WAY FASTER. No brainer.

It was “a significant improvement” that you could take advantage of with relatively low business risk. You can mix the old with the new.

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.
AND
2. We can add back in all the high-magic components after we've got RPerl v1.0 working with the low-magic components.

Simply and politely put, your arguments ARE TOTALLY INVALID.

Perling,
~ Will

Replies are listed 'Best First'.
Re^3: Perl 5 Optimizing Compiler, Part 9: RPerl.org & The Low-Magic Perl Commandments
by Anonymous Monk on Nov 12, 2013 at 14:52 UTC
    Prove it. With real code.
      Pre-release hand-compiled alpha code here:

      https://github.com/wbraswell/rperl

      It should run in Linux, bulk88 and I are currently working to get it running in Windows. Please give it a try and let me know what happens. :-)

      Perling,
      ~ Will the Chill
Re^3: Perl 5 Optimizing Compiler, Part 9: RPerl.org & The Low-Magic Perl Commandments
by sundialsvc4 (Abbot) on Nov 12, 2013 at 21:40 UTC

    (Shrug...)   What can I say, Will?   It may astound you that I would say ... “I don’t particularly care that “my code will run ‘way faster!’ ”

    Really, the only thing that matters to me is that the software ... that is to say, the software that I have, and, that is to say, already ... produces the correct results, and that I can prove it.

    Furthermore, the actual extent of compiler-induced measurable improvements to the runtime of any code whatsoever is, at this point in time, a remarkably slight delta.   It is the stuff of “Whetstones” by now.   To make significant improvements to any compute algorithm, you have to change the algorithm.   Therefore, the usual actual business response is to “throw silicon at it (again),” thereby avoiding both the uncertainty and the expense of changing source, instead trusting Moore’s Law to once again save your business bacon.   After all, a capital investment in a $30,000 souped-up piece of silicon is nothing compared to the unfathomable expense of touching “paid-for source code that works.”

    The essence of your “commandments” is that “source-code change” is not only ‘free,’ it is ‘a Good Thing.™’ ”   Most unfortunately, this is not the case.   Aye, there’s the rub ...

    “Source-code change” ... is not an option.

    Think about it ... “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.”   Sure, it was “inefficient,” but then again, “Chips Are Cheap.™”   And so, so it goes.

      Hi sundialsvc4,

      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.

      AND

      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.

      Perling,
      ~ Will
      Can you please edit the line noise out of your post? It's super distracting :(