Deprecate .HLL_map
Andrew Whitworth
wknight8111 at gmail.com
Sun Jan 25 17:30:50 UTC 2009
On Sun, Jan 25, 2009 at 10:22 AM, kjstol <parrotcode at gmail.com> wrote:
> Maybe, for sake of documentation of design decisions, it'd be good if you
> could elaborate on the methods.
> (or put it in the book)
Yeah, I have to write a whole section on the Interpreter object, and I
have a lot to write about the topic of HLLs. I'll make sure everything
gets documented eventually.
> A simple principle: Everything that can be done during compile-time is a win
> over doing it during run-time.
> (however, that is not to say that I have a particular opinion on whether to
> keep it, just saying..)
I agree with you. However, we run into a problem where .HLL_map
doesn't work well with classes defined at runtime, and it's difficult
to extend it to be so. I had a few ideas about this that could get us
around this problem, but none of them seem great:
1) Change the HLL type registry to be string based instead of INTVAL
based. If we use the type names in the registry instead of their type
id numbers, this would solve the problem. However, we run into a major
performance problem having to do a string compare/lookup each time we
want to create a mapped PMC.
2) If .HLL_map doesn't find the type name at compile time, it could
enter the name into some kind of cache, to be resolved into a type id
number at runtime when it's first looked up. This is going to require
some significant changes throughout parrot, but shouldn't create too
huge a performance problem
I also kicked around the idea of an "hllmap" opcode, which should be a
significant performance win over having to call getinterp and then the
"hll_map" method after that. I'm willing to do whatever needs to get
done to fix the situation, but deprecating .HLL_map and using the
"hll_map" method instead is a path of least resistance.
> See my remark in 2). I guess it's a question of how much is the total
> performance overhead; if it doesn't happen too often, then this is not a
> problem. It's also nice if there's one canonical way of doing the mapping,
> which means less code, which means less maintenance.
I agree 100%. We need one way to do it that works with all cases.
--Andrew Whitworth
More information about the parrot-dev
mailing list