Nicholas -- I agree it would be good to see CG performance (compilation and exeuction speed) with and without optimizations. I haven't done the experiment myself.
I had tinkered with some asm-comment ideas last year when discussing JIT
with Daniel Grunblatt. For
your amusement, I've attached a tarball with a tiny example. I was trying
to insert asm comments for
later parsing. I didn't get far, but that doesn't mean its not possible.
Regards,
-- Gregor
Nicholas Clark <[EMAIL PROTECTED]>
11/04/2002 04:21 PM
To: [EMAIL PROTECTED]
cc: Leopold Toetsch <[EMAIL PROTECTED]>, Brent Dax <[EMAIL PROTECTED]>, 'Andy
Dougherty' <[EMAIL PROTECTED]>, Josh Wilmes <[EMAIL PROTECTED]>,
'Perl6 Internals' <[EMAIL PROTECTED]>
Subject: Re: Need for fingerprinting? [was: Re: What to do if
Digest::MD5 is
unavailable?]
On Mon, Nov 04, 2002 at 10:09:06AM -0500, [EMAIL PROTECTED] wrote:
> While I don't think I'm sophisticated enough to pull it off on my own, I
> do think it should be possible to use what was learned to build the JIT
> system to build the equivalent of a CG core on the fly, given its
> structure. I think the information and basic capabilities are already
> there: The JIT system knows already how to compile a sequence of ops to
> machine code -- using this plus enough know-how to plop in the right JMP
> instructions pretty much gets you there. A possible limitation to the
I'm not convinced. Compiling the computed goto core with any sort of
optimisation turns on *really* hurts the machine. I think it's over a
minute even a 733 MHz PIII, and it happily pages everything else out while
it's doing it. :-(
I doubt that the GC core's stats look anywhere near as impressive for the
unoptimised case. [And I'm not at a machine were I can easily generate
some]
This makes me think that it would be hard to "just in time"
> coolness, here: I think the JIT system bails out for the non-inline ops
> and just calls the opfunc (please forgive if my understanding of what
JIT
> does and doesn't do is out of date). I think the CG core doesn't have to
> take the hit of that extra indirection for non-inline ops. If so, then
the
> hypothetical dynamic core construction approach just described would
> approach the speed of the CG core, but would fall somewhat short on
> workloads that involve lots of non-inline ops (FWIW, there are more
inline
> ops than not in the current *.ops files).
I believe that your understanding of the JIT and the GC cores are still
correct. The problem would be solved if we had some nice way of getting
the
C compiler to generate us nice stub versions of all the non-inline ops
functions, which we could then place inline. However, I suspect that part
of
the speed of the CG core comes from the compiler (this is always gcc?)
being able to do away with the function call and function return overheads
between the ops it has inlined in the GC core.
I've no idea if gcc is allowed to re-order the op blocks in the CG core.
If not, then we might be able to pick apart the blocks it compiles (for
units for the JIT to use) by putting in custom asm statements between
each,
which our assembler (or machine code) parser spots and uses as delimiters
(hmm. particularly if we have header and trailer asm statements that are
actually just assembly language comments with marker text that gcc passes
through undigested. This would let us annotate the assembler output of
gcc)
Nicholas Clark
--
Brainfuck better than perl? http://www.perl.org/advocacy/spoofathon/
asm-fun.tar.gz
Description: Binary data
