Efficient thread-local shared variables
bert at freudenbergs.de
Tue Oct 24 16:20:44 UTC 2006
Just as a side not on efficiency - globals are much more often read
than written. The original goal might even be fulfilled by read-only
variables (not sure about that). So optimizing for read is essential,
but I have a hunch that writing could be much slower without any
noticeable effect on performance.
- Bert -
Am 24.10.2006 um 18:07 schrieb ncellier at ifrance.com:
> Yes, despite very confusing names i used, you understood me well,
> "key" was to be replaced with any variable name lying in the pool
> Thank you for these explanations.
> I understand that having mutable literals would break VW JIT.
> It may be worse if we use a trick to share a literal reference
> between two methods (the getter and setter), and that trick is not
> recognized at JIT level...
> In order to use traditional compiler optimizations, you could maybe
> use a class var for each pool dictionary entry in your anonymous
> class instead of a literal reference.
> This way, no use to flush the VM cache whenever the value changes...
> Compared to traditional global variable access that directly
> adresses the association (with value or value:), this cost a first
> method call to get the thread-dependent pool dictionary and an
> additional method lookup to get/set the value.
> Could such kind of method lookup be reduced by an inlining cache a
> la strongtalk ?
> Le Mardi 24 Octobre 2006 16:17, vous avez écrit :
>> On Oct 24, 2006, at 12:18 PM, ncellier at ifrance.com wrote:
>>> So you have to share the first literal between read and write
>>> access methods ?
>>> like pseudo byte code:
>>> ^(literalAt: 1) value
>>> key: aValue
>>> ^(literalAt: 1) value: aValue
>> Your code confuses me, but you seem to be talking about implementing
>> Association behavior. In my scheme CompiledMethods come closest to
>> this role.
>> So getting to the 'association' could be implemented on the anonymous
>> class as
>> associationAt: aSymbol
>> ^self compiledMethodAt: aSymbol
>> then CompiledMethod could implement
>> ^self selector
>> ^self localAt: 1
>> Changing the value is something I haven't needed/tried yet because in
>> VW matters are complicated by the JIT cache that would (might?) need
>> to be flushed. This requires me getting to the class that holds this
>> CompiledMethod. Conceptually:
>> value: anObject
>> self localAt: 1 put: anObject.
>> self classThatImplementsMe flushVMMethodCashesFor: self selector.
>> Overall I'm not too keen on modeling full dictionary behavior because
>> my 'dictionary' is already different in that it is reified as two
>> objects (the anonymous class and its singleton instance), the class
>> can be regarded as a mirror-like accessor to the dictionary for doing
>> 'meta' queries like getting to an 'association' and for altering the
>> dictionary contents. The singleton instance is used for lookup only
>> (any support methods implemented on it would clash with keys you
>> might want to use, currently only #doesNotUnderstand: is implemented
>> on my anon class).
>> One of my pet peeves about St is that #doesNotUnderstand: should be
>> implemented on he class side so it doesn't pollute the object's
>> selector namespace...
> iFRANCE, exprimez-vous !
More information about the Squeak-dev