On Mon, Feb 9, 2009 at 2:50 PM, chromatic <[email protected]> wrote: > On Monday 09 February 2009 11:21:52 Andrew Whitworth wrote: > >> On a tangential matter, maybe we need to consider changing "puts" to >> be a VTABLE instead of a METHOD? > > No. We have to fix PCCINVOKE. Ideally, we'll excise it from the system > entirely. Every time we call into the runloop again from C, we lose. > > 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. >> I still can't really understand where all these PMCs are coming from. > > Invoking a PMC from C requires generating call signatures and integer arrays. That's what I really don't understand, why do we need to generate so many complex data items in order to invoke a single subroutine? The whole operation should be possible with a fraction of the data shuffling that we do currently. It's not just PMCs that we're creating, either. There are lots of little structures created here and there that aren't GCable. We need a serious overhaul of these mechanisms to get this right, sooner rather then later. >> Looking at the generated C code for the puts method, I can immediately >> see a few things that are suspect, which brings a lot of questions to >> mind: Why are we generating a _params_sig PMC here it seems to serve >> no purpose whatsoever? Why are we creating a _returns_sig too? Don't >> we have the signature for the method already generated as part of >> Parrot_PCCINVOKE? It doesn't look like the _params_sig PMC is actually >> being used anywhere either. Also, why do we create a RetContinuation >> PMC here, what is it's purpose? Parrot_PCCINVOKE, and variants, create >> a new context for the method when it's called, although >> NCI.pmc:invoke() doesn't. So in some cases we appear to be creating >> two contexts for a method call instead of just one. > > 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. > Sure, but that's going to improve this benchmark by no more than 20%. The > real solution is not to perform expensive operations, not to make it cheaper > to clean up after sloppy, expensive operations. Every little bit helps :). You're right of course, we shouldn't be prematurely optimizing our GC for a particular resource usage profile when there are a lot of things in that profile that need to be changed. --Andrew Whitworth _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
