Re: Perl 5 Optimizing Compiler, Part 2

Replies are listed 'Best First'.
Re^2: Perl 5 Optimizing Compiler, Part 2 by Corion (Patriarch) 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.	[reply] [d/l]
Re^3: Perl 5 Optimizing Compiler, Part 2 by flexvault (Monsignor) on Aug 18, 2012 at 14:10 UTC
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	[reply]
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.	[reply]
Re^3: Perl 5 Optimizing Compiler, Part 2 by flexvault (Monsignor) on Aug 19, 2012 at 14:29 UTC
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	[reply]
Re^2: Perl 5 Optimizing Compiler, Part 2 by raiph (Deacon) 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...	[reply]
Re^3: Perl 5 Optimizing Compiler, Part 2 by BrowserUk (Patriarch) on Aug 22, 2012 at 23:22 UTC
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?	[reply]
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.	[reply]
Re^3: Perl 5 Optimizing Compiler, Part 2 by flexvault (Monsignor) on Aug 21, 2012 at 11:00 UTC
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	[reply]
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. :-)	[reply]
Re^3: Perl 5 Optimizing Compiler, Part 2 by chromatic (Archbishop) on Aug 22, 2012 at 16:41 UTC
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.	[reply]
Re^4: Perl 5 Optimizing Compiler, Part 2 by Will_the_Chill (Pilgrim) on Aug 23, 2012 at 07:28 UTC
Again, correct me. Telling me to stop will achieve nothing.	[reply]
Re^3: Perl 5 Optimizing Compiler, Part 2 by flexvault (Monsignor) on Aug 22, 2012 at 12:42 UTC
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	[reply]
Re^4: Perl 5 Optimizing Compiler, Part 2 by Will_the_Chill (Pilgrim) on Aug 23, 2012 at 07:36 UTC
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.	[reply]


laziness, impatience, and hubris
	PerlMonks