Re: Perl 6 and byte code
Stéphane Payrard
> Presently Python compiles it's py files to pyc files that can then be
> run without access to the source (the py).
>
> Would Perl 6 be able to do this? Compile the pl to plc and pm to pmc and
> load the ??c version if it was available and newer than the
> source?
I suppose that means implementing for perl6 the equivalent of
ccache. I doubt that, in general, the preferred form of a dynamic
programming language is the bytecode one.
>
> Other than code hiding would there be any performance benefits?
>
There is the age old debate about the dubious benefits of source
code hiding.
--
stef
Dan Sugalski
>Presently Python compiles it's py files to pyc files that can then
>be run without access to the source (the py).
>
>Would Perl 6 be able to do this? Compile the pl to plc and pm to pmc
>and load the ??c version if it was available and newer than the
>source?
Yeah, that's doable. Probably will be done.
>Other than code hiding would there be any performance benefits?
Given that the bytecode will probably have a segment with the
original source in it, this isn't likely to get you much of a win
there.
There should be a performance win, though. There won't be a need to
compile the source, which saves some time. Bytecode files on-disk are
shared across all the processes in the system, so you only get one
in-memory copy of a file, which saves both RAM and load time if
you're using a file that another process is using.
On single user or small machines this probably won't be a big win in
most cases. It should, however, make a pretty big difference in
server systems.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Peter Hickman
Thanks for that, I was pretty sure that it should have been doable.
Thanks
Gisle Aas
> Bytecode files on-disk are
> shared across all the processes in the system, so you only get one
> in-memory copy of a file, which saves both RAM and load time if you're
> using a file that another process is using.
I assume this means that the plan is to mmap these files. Are most
systems happy with hundreds (or thousands) of mapped sections of
memory or are there some negative performance implications of doing
that?
How about the code JITed from the bytecodes. Will it be shared?
Regards,
Gisle
Dan Sugalski
>Dan Sugalski <d...@sidhe.org> writes:
>
>> Bytecode files on-disk are
>> shared across all the processes in the system, so you only get one
>> in-memory copy of a file, which saves both RAM and load time if you're
>> using a file that another process is using.
>
>I assume this means that the plan is to mmap these files. Are most
>systems happy with hundreds (or thousands) of mapped sections of
>memory or are there some negative performance implications of doing
>that?
Most systems I know about are unhappy with hundreds or thousands of
mmaped segments per-process, but that's generally not a problem for
that many segments for the system as a whole. I think that mmap
shares underlying code paths with the code to map in shared libraries
most places, so we shouldn't have to worry about it. If things fail,
we can always fall back to an alternate plan.
>How about the code JITed from the bytecodes. Will it be shared?
Unfortunately not, no. It wouldn't be a bad idea to expand the
bytecode files to allow executable segments that could be used in
trusted situations.
Jeff Clites
> How about the code JITed from the bytecodes. Will it be shared?
The JITed code can't be shared directly--in it's current form, it
(intentionally) includes absolute addresses which wouldn't be valid for
other processes.
But the exec core allows (or, will allow) bytecode to be compiled into
a native executable (or presumably, library), so that would allow the
advantages of native, memory-shared code.
JEff