At 05:28 PM 9/25/2001 -0700, Damien Neil wrote:
>On Tue, Sep 25, 2001 at 08:18:04PM -0400, Dan Sugalski wrote:
> > That'd be interesting. Try cobbling up a version of the assembler that
> does
> > big-endian assembly and a loader that reads and byteswaps, and see what
> you
> > get for start-to-finish performance.
>
>I'm going to take a crack at that Real Soon Now. I'm betting that
>the penalty is a) overwhelmed by I/O and syscall overhead to load
>the bytecode in the first place, and b) very small compared to the
>execution time of the bytecode.
Bet you'll find that not to be the case. :) While it might not be a huge
amount of work, it is extra work that'll have to be done when we could
otherwise just not do it. Not doing something's generally more efficient
than doing something. :)
> > Don't forget that this also kills mmap and the potential to share one copy
> > of the code across multiple simultaneous invocations of Parrot.
>
>Yes. On the other hand, I'm not certain how much of a win mmaping
>bytecode will really give us in the long run. It depends on how
>large bytecode files are, and what manner of fixups will be needed
>on it. (If most bytecode pages are touched during the fixup pass,
>mmap isn't a win at all.)
If we touch most of the bytecode pages then we've really failed in our
on-disk format design.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
