[squeak-dev] Re: Burn the Squeak Image! (Why I am running for board)

Igor Stasenko siguctua at gmail.com
Sun Mar 1 21:01:03 UTC 2009


2009/3/1 Eliot Miranda <eliot.miranda at gmail.com>:
>
>
> On Sun, Mar 1, 2009 at 12:23 PM, Igor Stasenko <siguctua at gmail.com> wrote:
>>
>> 2009/3/1 Andreas Raab <andreas.raab at gmx.de>:
>> > Igor Stasenko wrote:
>> >>
>> >> Changing the object formats alone does not gives any benefits. What is
>> >> the point in having new format when you keep using old semantic model
>> >> as before?
>> >
>> > Speed. That is the only point of the exercise to begin with.
>> >
>> >> This is like swapping instance variables order in your class.. Apart
>> >> from a better aestetical view it gives you nothing :)
>> >
>> > If swapping ivars in a class would give me a 3x in performance I'd be
>> > doing
>> > this all day long...
>> >
>> but we both know that this is too good to be true.  :)
>> unless you change the way how things working, you can't achieve
>> significant performance boost. And often this means rewriting
>> interfaces, which inevitably leads to changing a lot of code on
>> language side etc.
>
> Uh, no.  Here is the inline cache check in Cog, which is as complicated as
> it is because of compact classes:
> 00009588: movl %edx, %eax : 89 D0
> 0000958a: andl $0x00000001, %eax : 83 E0 01
> 0000958d: jnz .+0x00000011 (0x000095a0=singleRelease at 40) : 75 11
> 0000958f: movl %ds:(%edx), %eax : 8B 42 00
> 00009592: shrl $0x0a, %eax : C1 E8 0A
> 00009595: andl $0x0000007c, %eax : 83 E0 7C
> 00009598: jnz .+0x00000006 (0x000095a0=singleRelease at 40) : 75 06
> 0000959a: movl %ds:0xfffffffc(%edx), %eax : 8B 42 FC
> 0000959d: andl $0xfffffffc, %eax : 83 E0 FC
> 000095a0: cmpl %ecx, %eax : 39 C8
> 000095a2: jnz .+0xffffffda (0x0000957e=LSICMissCall) : 75 DA
> In VisualWorks the code looks like
>     movl %ebx, %eax
>     andl $3, %eax
>     jnz LCompare
>     movl (%ebx), %eax
> LCompare:
>     cmpl %eax, %edx
>     jnz +0xffffff??=LSICMissCall
> That's 9 or 11 instructions (compact vs non-compact) vs 6 instructions in
> the common case, but vitally, for non-compact classes 2 memory reads vs one.
> So indeed object representation can make a major difference in run-time
> performance.  Consider how much quicker object allocation is in VW, which
> does not have to check if the receiving class is compact or not, compared to
> Squeak. Consider how much quicker string access is in VW, which has
> immediate characters, than Squeak with the character table and the inability
> to do == comparisons on Unicode characters. etc. etc.

Sometimes I having troubles with expressing my thoughts clearly.. sorry.
I din't mean that changing object format does not improves the speed.
I meant that such changes alone is very hard to adopt without ANY
changes on language side.
See
Behavior>>becomeCompact
becomeCompactSimplyAt: index
becomeUncompact

see also
#compactClassesArray

and i suspect this list is only a top of the iceberg (for instance,
you may need to change SpaceTally to report things properly).

Now, defending you point, that really, it would be much easier to deal
with such things in a micro-image (consider the amount of code and
tests which you need to perform when producing new update).

This makes you, as a VM developer be responsible from good integration
of VM with language side.
Then rest images, which is based on it will have to use things
strictly in manner, as it put in kernel.
It is important to draw a line between kernel and rest of the code in
image, which depends on it.

>>
>> > Cheers,
>> >  - Andreas
>> >
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>
> Best
> Eliot
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list