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. | [reply] [Watch: Dir/Any] |
|
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
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
|
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.
| [reply] [Watch: Dir/Any] |
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
| [reply] [Watch: Dir/Any] |
|
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.
| [reply] [Watch: Dir/Any] |
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?
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
|
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. | [reply] [Watch: Dir/Any] |