On Mon, Nov 04, 2002 at 09:21:06PM +0000, Nicholas Clark wrote: > 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"
It turns out the optimization does make a difference for gcc at least, but for a strange reason. It seems that without optimization gcc allocates a *lot* more space on the stack for cg_core. I suspect this is because gcc does not coalesce the stack space used for temporary values unless optimization is enabled. (gcc with no optimization) ../parrot mops.pbc Iterations: 100000000 Estimated ops: 200000000 Elapsed time: 13.528871 M op/s: 14.783200 (gcc -O2) ../parrot2 mops.pbc Iterations: 100000000 Estimated ops: 200000000 Elapsed time: 30.111252 M op/s: 6.642035 > 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?) Newer versions of the SUN workshop compiler supports computed goto. > 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) A lot of research has been done on this type of thing under the terms 'partial evaluation' and 'specialization'. There is a working specializing python compiler that might be of interest : http://psyco.sourceforge.net/doc.htm -- Jason
