[Openmcl-devel] Couple implementation questions...
gb at clozure.com
Wed Sep 2 16:08:20 EDT 2009
On Wed, 2 Sep 2009, Jon S. Anthony wrote:
> A couple of (I believe) quick questions on some implementation details
> with CCL.
> 1. Does CCL cache in some fashion the hash for a symbol? ACL does this
> and it can be a real win when using symbols as keys in a hashtable.
> But, I don't see a slot in the symbol def for this, so maybe this isn't
> done in CCL. If not, is there a compelling reason not too or just not
> something anyone thought that important? It wouldn't take much to build
> hack using say the property list, but that doesn't seem satisfactory if
> something better is available.
It does; I don't think that it's very important, but a customer once
thought that it did.
I don't know for sure which of us was right or to what degree. My
intuition was/is that the costly cases of hashing a symbol (which is
hashing its pname in CCL) involve (hardware data) cache misses. If
you cache the result of that operation, you've got to put that result
somewhere. If you just happen to have an unused word in the symbol
that's otherwise (due to alignment issues or something) wasted, you
might win; if you have to make symbols bigger or somehow pack this
cached info into some other field in the symbol, you probably introduce
more cache misses elsewhere.
I don't remember this change making any measurable difference in
performance; in that customer's case, locking on concurrent access
to hash tables tended to be a much bigger source of overhead. That
other overhead is usually less than it was a few years ago, and it
might be easier to evaluate the positive and negative effects of
this change. I've never done that, but I'm not a big fan of the
> 2. I've noticed that ivectors (created via ccl:make-heap-ivector) don't
> seem to show up in the stats from (room t). Is this as expected (i.e.,
> known consequence of design) or a bug/missing functionality? Oddly, the
> space doesn't seem to show up in TOP (the RES field) either. This is on
> Linux (and 32 bit - I didn't check 64 bit).
I can't think of any reason for ROOM not to tell you about heap-allocated
ivectors, but unless user code is using them heavily (IIRC, you are), there
are usually just a few KB worth of stream buffers allocated in foreign
> Thanks in advance!
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel