On Wed, Oct 27, 2004 at 12:00:33PM +0100, Peter Hickman wrote: > 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.
>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
Dan Sugalski wrote: > At 12:00 PM +0100 10/27/04, Peter Hickman wrote:
>> 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
Thanks for that, I was pretty sure that it should have been doable.
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?
How about the code JITed from the bytecodes. Will it be shared?
>> 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. -- Dan
--------------------------------------it's like this------------------- Dan Sugalski even samurai d...@sidhe.org have teddy bears and even teddy bears get drunk
> 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.
|
