Nicholas Clark wrote:
On Mon, Nov 04, 2002 at 10:09:06AM -0500, [EMAIL PROTECTED] wrote:
[ JIT + cg_core ]
I'm not convinced. Compiling the computed goto core with any sort of
optimisation turns on *really* hurts the machine.
Here gcc 2.95.2 just fails (256 MB Mem, same swap)
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"
... 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.
Yes, saving the function code overhead is the major speed win in CGoto.
I've no idea if gcc is allowed to re-order the op blocks in the CG core.
Doesn't matter IMHO (when we annotate the source) ...
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)
.... but this is only half of the work. JITs current outstanding integer performance depends on explict register allocation for the must used IRegs in one block. Mixing of JIT instructions and gcc generated wouldn't work because of this register allocation.
My experiment with microops could help here, where the optimizer would basically generate code for a 3-register machine.
Nicholas Clark
leo
