Greg Ewing writes: > A worry about that is whether the architecture required to > allow pluggable GC implementations introduces inefficiencies > of its own that would skew the results.
Bob Ippolito > There's no need to worry about that in the case of PyPy. Those kinds > of choices are made way before runtime, so there's no required > indirection. Someone who knows PyPy better than me feel free to chime in if I get things wrong, but I *think* that when it happens well before runtime, well before compile-time, more equivalent to "time at which the interpreter is compiled". So if you have PyPy set up to compile to C and use reference counting GC, then it generates calls to INCR and DECR before and after variable accesses, but if you have it set up to compile to the LLVM which has its own tracing GC then it doesn't generate anything before and after variable accesses. Greg again: > Even so, we're talking about machine-generated code rather > than the sort of hand-crafting you need to get the best > out of something critical like GC. There could still be > room for inefficiencies. Quite true. As further illustration Python's GC is written in C and thus you can't get the kind of efficiency you might out of hand-crafted assembly. Unless of course the machine generating the code is actually smarter about optimization than the hand that's crafting it, or if the two are close enough in performance that we don't mind. I don't think PyPy has anything to teach us about GC performance *yet*, but I think their approach is quite promissing as a platform for running this kind of experiment. -- Michael Chermside _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
