Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

Re: {Perl6} Macros and native compilation

by chip (Curate)
on Apr 10, 2005 at 18:51 UTC ( #446441=note: print w/ replies, xml ) Need Help??


in reply to {Perl6} Macros and native compilation

Parrot is a virtual machine. There's no need to go further in compiling down to native code.

    -- Chip Salzenberg, Free-Floating Agent of Chaos


Comment on Re: {Perl6} Macros and native compilation
Re^2: {Perl6} Macros and native compilation
by samtregar (Abbot) on Apr 11, 2005 at 00:59 UTC
    So all those Java JITs are just a big waste of time? If the virtual machine imposes no overhead then I guess you'd be right but that seems rather unlikely.

    HTML::Template is a VM is you squint and tilt your head but that doesn't make HTML::Template::JIT useless.

    -sam

      Err, actually, Parrot has this massively sane, cross platform, JIT system. It's just that we as compiler writers need not be aware of it.
Re^2: {Perl6} Macros and native compilation
by spurperl (Priest) on Apr 11, 2005 at 11:30 UTC
    What you say is correct, but it's not enough for some cases.

    For example, at work we all have Windows machines and most people don't have Perl installed. From time to time, I create small Perl applications that could be useful for others, and it's a big problem to move them to other computers.

    Even if Perl is installed, all the modules the program need often are not, and some computers are not connected to the network so it's not easy to distribute.

    What I use is PAR, but it creates large executables (3 MB and north) and often induces a runtime penalty (even if it's only on startup - some apps are so small that a 20 second delay is unbearable)

    Compiling Perl to native code would be a bliss for me. I'd wish to work in a networked Unix environment (like at my other job), with Perl installed everywhere and CPAN distribution simple, but sometimes reality hurts.

    In fact this is the only downside of Perl for me, and the reason I still sometimes create pure-C++ (with Win32 API for GUI) apps - complete programs with GUIs that run autonomously on any Windows box disregarding of its application base and take only 100K of disk/memory are hard to beat.

      Your use case is an important one, and I intend for Parrot to be easily bundled with Parrot applications -- preferably with a smaller total size than that currently necessary with Perl 5.

          -- Chip Salzenberg, Free-Floating Agent of Chaos

        I don't mind Parrot being bundled with the "natively compiled app", I realize it can be very difficult without this bundling.

        Just hopefully the whole bundle won't be too big and/or too slow.

      What I use is PAR, but it creates large executables (3 MB and north) and often induces a runtime penalty (even if it's only on startup - some apps are so small that a 20 second delay is unbearable)

      Compiling Perl to native code would be a bliss for me. I'd wish to work in a networked Unix environment (like at my other job), with Perl installed everywhere and CPAN distribution simple, but sometimes reality hurts.

      Most of that delay will likely disappear with Parrot without the need for compilation to native code. Most of that startup delay will be loading and compiling the Perl 5 code. With Perl 6/Parrot you'll be able to just ship the Parrot bytecode with the VM and save the compilation steps.

      What I use is PAR, but it creates large executables (3 MB and north) and often induces a runtime penalty (even if it's only on startup - some apps are so small that a 20 second delay is unbearable)

      Such long PAR startup penalty only occurs the very first time you run a (PARred) program (unless you have used the -C or --clean switch when creating the package), because PAR must extract all the files it needs to run your program, including perl itself, the modules used by your program and anything else you've packaged (the files are extracted into your system temporary directory).
      The next time you run your program, it starts up much faster (provided that these cached files have not been deleted of course), since PAR first looks for these previously cached files, and if it finds them it cleverly avoids to extract them again.

      Ciao,
      Emanuele.

Re^2: {Perl6} Macros and native compilation
by Limbic~Region (Chancellor) on Apr 11, 2005 at 12:45 UTC
    chip,
    Given your recent acceptance of the Parrot design chief hat, this answer worries me a bit. The question being asked was along the lines of has any work been done towards native executables, to which the answer I believe is "yes" having followed the project for some time now. The answer you gave leads me to believe that it is no longer a goal to support native executables on popular platforms. On the other hand, you might have just meant that while it is an option, it is not a necessary one.

    Can you please clarify?

    Cheers - L~R

      Well, I don't want to discourage anyone from working on native code export if they have good reason to believe it's worthwhile. (This is not to be confused with the JIT, which is native code as an in-memory optimization.) But as far as I can tell, it isn't worthwhile. Some good use cases might change my mind, of course.

      BTW, for those of you who want to create packaged binaries: I suggest that the best route will be to package the parrot executable along with your pbc.

          -- Chip Salzenberg, Free-Floating Agent of Chaos

        chip,
        I will paraphrase and summarize our recent IRC conversation for the benefit of others.

        Limbic~Region: Parrot currently has a command line option for native executables which I believe already works on a couple of platforms. Are you saying that this functionality isn't integral or necessary for the project?
        chip: Not exactly. It is unlikely a native executable will work without linking against a substantial part of Parrot. It is not something I see as being necessary but I certainly don't want to discourage anyone else from working on something they feel is important.

        Please correct me if my paraphrasing is misrepresenting your position in any way. I see your point and concede that I have apparently been under the wrong impression for over a year now.

        Cheers - L~R

Re^2: {Perl6} Macros and native compilation
by Elian (Parson) on Apr 14, 2005 at 14:54 UTC
    Erm... we already can do that. The JIT code has been leveraged to emit native object files, and there's a bytecode->C translator that generates compilable C. (That's been in there and working, on and off, since the first few weeks of the project)

    There's definitely a performance win to doing it, though how much depends on how much of the code uses the low-level types instead of PMCs, since the C optimizer has more to work with there.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (4)
As of 2014-12-20 08:28 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (95 votes), past polls