Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Re: Perl 5 Optimizing Compiler, Part 2

by flexvault (Parson)
on Aug 18, 2012 at 10:00 UTC ( #988186=note: print w/ replies, xml ) Need Help??


in reply to Perl 5 Optimizing Compiler, Part 2

Will_the_Chill,

Good Research!

I hope you noticed my interest in the topic Perl 5 Compiler, Again! which was a direct result of your original post. If you did you may have noticed the answer from rurban of:

    perl5 opcodes change from release to release, there's no discipline. p5 devs do not want to have bytecode discipline.

    parrot was designed to have bytecode discipline originally (and be platform independent), but both of these goals were thrown away without discussion at v1.0. That's why I left the project in protest.


clarified for me why the 'compiler' topic is near impossible to solve.

This guarantees that each release of Perl requires a re-compile of all scripts or just keep all scripts as source-code. Until that explanation I just couldn't understand the real problem.

Since both 'perl5' and 'perl6' have dropped the concept, maybe it's time for 'perl7' :-)

Good Luck...Ed

"Well done is better than well said." - Benjamin Franklin


Comment on Re: Perl 5 Optimizing Compiler, Part 2
Re^2: Perl 5 Optimizing Compiler, Part 2
by Corion (Pope) on Aug 18, 2012 at 12:10 UTC
    This guarantees that each release of Perl requires a re-compile of all scripts or just keep all scripts as source-code.

    ... only in as much as every C program needs to be recompiled whenever a new version of gcc is released.

    I would assume that a compiled Perl program includes all its constituents (modulo external, non-XS dynamic libraries), and thus is basically a stand-alone executable.

    But then again, I don't care much for either side of this argument, as for me the interpreter has been fast enough in the parts where I use it.

      Hello Corion,

      I think you're confusing my portability and scalability issues with others requirements for speed and/or obfuscation. I have stated on PM that 'Perl just gets better and better" and I meant it. I don't have issues with Perl's speed.

      Also I do have programs that were compiled in 1990 on pre-released IBM RS/6000 computers running AIX 3.0 beta ( AIX 3.1.5 was the official release in 1991 ) that can run today on 'power 7, p-series computers running AIX 7.1'. The computers are binary compatible even though the source code doesn't compile. K&R 'C' is considered traditional today, and most 'C' products no longer support traditional code.

      IMHO, if you ever have to authorize a '10 man-year' project to manually update source code on 2500+ computers, instead of remotely updated the compiled code over a weekend, then maybe you would see it as a little bigger and different problem.

      Thank you

      "Well done is better than well said." - Benjamin Franklin

Re^2: Perl 5 Optimizing Compiler, Part 2
by bulk88 (Priest) on Aug 19, 2012 at 02:26 UTC
    Python seems (I've never programmed in it) to cache compiled bytecode and keep it next to the original source code everwhere, http://docs.python.org/release/1.5.1p1/tut/node43.html. Maybe a similar concept should be added to Perl. If the version, or CRC or timestamps dont match it is recompiled and saved disk.

      bulk88,

      That would enhance Perl, but would not solve the lack of 'opcodes integrity' from release to release. Maybe the 'use 5.8.8;' could be enhanced to use/force the bytecode to be the same as used for release 5.8.8.

      As a programmer, Perl is a fantastic tool.

      From the perspective of upper management that authorized the salary for the programmer, it's a tool that end-users can change. We hear all the time on PM "I can't use CPAN" or "I don't have access to a compiler", or ...
      And then we get the tech answer of 'You too...' But that's not the answer?

      The question is coming from someone who is listening to his/her management, and management wants to control the use of the company's computer resources.

      A technical answer is not relevant.

      Upper management doesn't care how easy/hard it is for the programmer, they want to know that if the software gets deployed to the organization, then it will work the same everywhere.

      This isn't new, and it's not going to be solved on PM!

      Thanks...Ed

      "Well done is better than well said." - Benjamin Franklin

Re^2: Perl 5 Optimizing Compiler, Part 2
by Will_the_Chill (Pilgrim) on Aug 21, 2012 at 05:33 UTC
    flexvault, I've sent you an invitation to Trello using your e-mail address from the Chatterbox message (which I almost totally missed, please reply in these threads instead):
    BLANK

    Accept the invite and I will add you to the Trello board for this software development project.

      Will_the_Chill,

      That was a private message I sent you, so that the email address would not be on-line for spammers. Please remove the address.

      I've received your message.

      Thank you

      "Well done is better than well said." - Benjamin Franklin

Re^2: Perl 5 Optimizing Compiler, Part 2
by Will_the_Chill (Pilgrim) on Aug 22, 2012 at 06:54 UTC

    Ed, I'm no expert but I think you may be a bit confused. Your "Perl 5 Compiler, Again!" thread definitely did NOT prove that the "compiler topic is near impossible to solve". That thread was basically just one tit-for-tat between chromatic and Reini Urban, who are on opposite sides of the fence on this particular issue, and who are apparently also not the best of friends. Nothing solid can be deduced from that thread.

    The bytecode issue is only one aspect of the complicated optimizing problem. We may be able to produce a Perl 5 optimizing compiler without use of the Perl bytecode system at all. On the other hand, bytecode may turn out to be a critical component in optimizing, only time will tell.

    Perl 6 seems to be a pipe dream. Perl 5 seems to be stabilized and mostly in maintenance mode. I'm not interested in creating Perl 7, since Perl 6 needs to happen first, if ever. I'm interested in compiling & optimizing Perl 5, and this is what I will achieve. :-)

      Hello Will_the_Chill,

      Thanks for removing the email address.

      I don't think I'm confused about how to write a compiler, since I was very much involved in that in the past.

      What you are minimizing is the '...lack of bytecode integrity' on the impact of developing a compiler for Perl. This is a religious decision and not a technical issue. Your attempts will fail because the Perl developers don't want you to succeed. Each new version of Perl will need a unique compiler. So you come out with your Perl compiler 5.20.0 and the next week Perl 5.22.0 is released, and the Perl developers point out that you compiler 5.20.0 doesn't work with 5.22.0. True, because now you have to use the bytecode structure of 5.22.0 for your 'new/updated' compiler, and your always in catch up mode.

      Notice, how many are quick to point out that the early attempts at compilers were always 'out of date'.

      I wish you luck, but I was only half joking about Perl7. Perl's strength is The Programming Language, not that it's an interpretative language. Of course you need source code, and to develop the software product you need the power of running in an interpretor, but then you need a compiler to distribute the product. Perl5 has two of the three, and will alway have two of three.

      Thank you

      "Well done is better than well said." - Benjamin Franklin

        flexvault, my current plan doesn't necessarily involve utilizing the Perl bytecode representation as a significant part of the optimization process. I'm hoping this and utilization of Reini's B system will avoid the "always out of date" issue.
      Nothing solid can be deduced from that thread.

      Indeed, and yet:

      That thread was basically just one tit-for-tat between chromatic and Reini Urban, who are on opposite sides of the fence on this particular issue, and who are apparently also not the best of friends.

      You're making another big assumption. Please stop.

        Again, correct me. Telling me to stop will achieve nothing.
Re^2: Perl 5 Optimizing Compiler, Part 2
by raiph (Friar) on Aug 22, 2012 at 22:21 UTC
    Since 'perl5' and 'perl6' have dropped the concept of bytecode generation

    Aiui it is, or would be, a monumental (I think that's an understatement) social and technical task to bring bytecode, and bytecode discipline, to the current Perl 5 compiler.

    But the story is different for Parrot. And different again for Perl 6. And different again for Perl 5 in the light of Perl 6.

    Parrot is a tough call. As others have said, bytecode stability was part of the original plan. It doesn't have that now, but that doesn't mean it couldn't, and won't ever. Otoh, to say they have more pressing concerns, and lack of tuits, is an understatement. Unless you are confident you could live for a few years without oxygen if you had to, I recommend you don't hold your breath waiting.

    Perl 6 also has more pressing concerns, and also has less resources than it needs, but it's a much more reasonable proposition regarding generation of bytecode and discipline to keep it forward compatible as they add or change opcodes.

    There are several Perl 6 compilers that generate bytecode. In particular, Niecza is pretty advanced and currently generates CLR bytecode and Rakudo is also pretty advanced and currently compiles down to Parrot bytecode. Aiui both these compilers are likely to be portable across different bytecode backends soonish; perhaps one will even manage that this year.

    And a few days ago someone spotted Larry Wall working on a Perl 5 parser written in Perl 6, something that's gotta be way easier than working on the current Perl 5 compiler...

      And a few days ago someone spotted Larry Wall working on a Perl 5 parser written in Perl 6

      Isn't that a bit like translating Welsh into Esparanto?


      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.

      The start of some sanity?

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://988186]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (5)
As of 2014-07-26 20:23 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (179 votes), past polls