At 02:34 AM 6/19/2003 +0200, Leopold Toetsch wrote:Jonathan Sillito wrote:(3) One other efficiency thought: I wonder if the interpreter's context could be changed to a pointer to struct Parrot_Context? This would make accessing the stacks slightly slower but would of course make restoring the context very quick. Just a thought ...
I tried this, and there was a distinct slowdown on accessing the regs through the dereference. Dan and I debated this because I had the same idea, but after profiling I proved Dan right. I think it is best optimized to the common case which is register access, not context switches.
Oh, right, that. (I should keep up to speed here ;)
Yeah, the registers in the interpreter were originally Daniel's idea. The first design had an indirect pointer to them and had it so the registers were always on the register stack--when you pushed a frame you just moved the register pointer a bit, which made pushes really fast. When Daniel started in on the JIT he asked if they could be in a fixed location, since that made accessing the registers faster, especially with interpreter-specific JITted code. (Direct, absolute addressing. Darned snappy) It turned out that accessing the registers in the interpreter, not just via the JIT, was faster too, more than outweighing the extra cost to push a frame, given that we access registers much more often than pushing frames.
Context switches and frame pushes will be relatively rare, at least relative to accessing registers. Adding a cycle to each register access to save (say) 70 or 100 cycles on a context switch isn't worth it unless we're doing *far* more context switches than I'm thinking we'll end up doing.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
