in reply to Perl 5 Optimizing Compiler, Part 9: RPerl.org & The Low-Magic Perl Commandments

“Downvoted” though my comments were ... I at least did not lurk behind “Anonymous Monk” to say them.   (heh ...)

Will, the root problem of your “grand pronouncement,” just like every graduate-student (or senior undergrad) who has “created a New Programming Language, accompanied by A Paper Extolling Its Superiority to Everything That Has Come Before,™” is simply that this really isn’t a terribly useful thing to have done.   Let me explain.

“An implementation of the Perl-5 programming language,” on my present machine, “sub-optimal” though it may be, occupies all of about 86 kilobytes of object-code.   On the other hand, the CPAN library of the system is about 96 megabytes.   And the client project library, as previously mentioned, is more than a million lines of custom-written code which in fact cost well more than a million US Dollars to produce.   This situation is hardly atypical.

Therefore ... in light of this, how fare your “commandments?”   Frank answer:   “not so good.”   Because they not only “demand” that I change, but “require” me to change ... and to reap what “benefits,” exactly?   Just in order to “Soak In The Goodness™ Of” whatever you have done.   Is this a cost that I can justify?   No, it isn’t.  

Plan Accordingly.™

Sure, “new code” is being written all the time, and so all of us are always clamoring for improvements.   But none of us can afford to de-stabilize, let alone change, “what has been done before.”   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.

Replies are listed 'Best First'.
Re^2: Perl 5 Optimizing Compiler, Part 9: RPerl.org & The Low-Magic Perl Commandments
by Will_the_Chill (Pilgrim) on Nov 12, 2013 at 08:01 UTC
    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
[reply]
      Prove it. With real code.
[reply]
        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
[reply]

      (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
[reply]
        Can you please edit the line noise out of your post? It's super distracting :(
[reply]
Re^2: Perl 5 Optimizing Compiler, Part 9: RPerl.org & The Low-Magic Perl Commandments
by salva (Canon) on Nov 12, 2013 at 09:25 UTC
    An implementation of the Perl-5 programming language ... occupies all of about 86 kilobytes of object-code

    Ja ja ja...

    Hint: ldd is "your" friend.

[reply]
[d/l]
    A reply falls below the community's threshold of quality. You may see it by logging in.

In Section Meditations