On Monday 09 February 2009 12:10:26 Andrew Whitworth wrote: > > The problem here, as usual, is that we have too much code written in C. > That's fair, but operations on PMCs that are common enough really > could be VTABLEs. Another discussion for another day.
No. That makes the problem worse. Please understand this: *Every time we convert between C and Parrot calling conventions, we throw away almost every hope of speed.* We can't hope for JIT to save us there, because that calling conventions conversion barrier *prevents* smart JITting. We can't hope for clever escape analysis to save us, because that calling conventions conversion barrier *prevents* us from knowing if a GCable element has escaped the realm of stack-allocation-okay to heap-allocation-essential -- unless we somehow instrument and analyze all of the potential C code callgraphs to give an idea of whether an element has escaped. > > We might half the amount of garbage created here by being smarter about > > this, but that's the calling conventions branch, and we're blocked on > > optimizing this until we can unify this code. > Give me a priority task and I'll work on it. If unifying NCI/PIR > calling conventions is high-priority, then I'll get started on that > ASAP. Top priority: get the generated PCCINVOKE headers out of METHODs in the .c files generated from .pmc files. Then we can look at ways to optimize that. Second priority: refactor all invocations of Subs and Sub-like PMCs to use CallSignature PMCs, so we can either prove that that line of thinking is horribly flawed and will give us another order of magnitude slowdown, or we can optimize it so it's not nearly as expensive. -- c _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
