[Vm-dev] Direct object pointers vs indirect ones pros and cons

Igor Stasenko siguctua at gmail.com
Sun Nov 14 02:03:09 UTC 2010


2010/11/13 Levente Uzonyi <leves at elte.hu>:
>
>
>
> On Sat, 13 Nov 2010, Igor Stasenko wrote:
>
>>
>> On 12 November 2010 17:44, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>>
>>> On 12.11.2010, at 14:41, Igor Stasenko wrote:
>>>
>>>> I'm inviting you to make own version of benchmark
>>>
>>> I don't think this can be realistically simulated inside Squeak. But possibly you could change the macros in sqMemoryAccess.h to fake an object table access?
>>>
>>> I just tried that. Using tinyBenchmarks, byte code performance drops to 63% and sends to 78%.
>>>
>>> Now declaring that variable volatile might be overkill as it prevents all caching, but I couldn't quite figure out a more realistic declaration.
>>>
>> you mean that non-volatile like:
>>
>> int FakeObjTable = 0;
>>
>> could be optimized away by compiler?
>> Well, since compiler compiles module by module (a separate C files),
>> if you remove 'static'
>> it can no longer able to optimize it to no-op, since it can't guess
>> what may happen to this variable in another object file,
>> since even if in one module there only a read-only access to it, some
>> other module could contain a code which modifying it.
>>
>> So, i think this is the worst case performance slowdown. :)
>>
>> If we take into account that to get object location you need to do
>> object table look only once,
>> and then any consequent read/write operations on object won't require
>> table lookup, this can be improved.
>
> You can't do that if you want O(1) time for #become:.
>
Can you elaborate?
For instance, lets take a bytecode read. Should each bytecode read
also go through object table?

>
> Levente
>
>> Consider, for example, that to read ivar, interpreter reads & checks
>> header, and only then ivar slot, so it should cost:
>> 1 table lookup and 2 reads at object location.
>> instead of 2 table lookups + 2 reads at object location.
>>
>>> - Bert -
>>>




-- 
Best regards,
Igor Stasenko AKA sig.


More information about the Vm-dev mailing list