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

Eliot Miranda eliot.miranda at gmail.com
Sun Mar 1 21:24:15 UTC 2009


On Sun, Mar 1, 2009 at 1:01 PM, Igor Stasenko <siguctua at gmail.com> wrote:

> 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.


No need to apologise.  Everyone (me especially) can take a few mail messages
to converge on the right meaning from time to time.

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).


You're absolutely right.  The major image-level change I will require is for
Behavior to implement identityHash with a primitive that is different form
that in Object.  Doing this allows me to implement a hidden class table in
the VM where a class's identity hash is the index into the class table.  An
instance of a class has the class's class table index (the class's id hash)
stored in its header, not a direct pointer to the class.  So every object
has a more compact class reference, say 16, 20 or 24 bits.  Also, class
references in in-line and method caches are class indices, not direct class
references, which means less work on GC.  But to ensure a class can be
entered in the table by the VM at an unused index Behaviour>>identityHash
must be a special primitive that the VM implements as searching the table
for an unused index.

But the imager-level code for compact classes can still exist; its just that
the VM will ignore it :)

Of course you're right about SpaceTally.  Perhaps the VM should provide some
primitives that allow SpaceTally to be parameterised.  of course it's not
until one tries to use such a parameterised SpaceTally on more than one
object representation that one knows the design works across a range of
object representations.  And its not as if one will be trying new object
representations every week (although I don't know :) ).  But it might be
worth the effort.  But probably simpler is having the kernel of SpaceTaly's
computatioons be in the microkernel image, and writing some suitable tests
to be run in a derivative image.

But my experience with 64-bit VW is that there are very few changes.  We had
the Behaviour>>identityHash primtiive, the primitive that answered the size
of the hash field, and that's about it.  Note that the image already
computes the size of SmallInteger by doing subtractions until overflow at
start-up.

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.


Right.  Agreed.  And experience shows (16-bit => 32-bit, Squeak & VW 64-bit)
that the new constraints introduced by the microkernel will be very few and
unobtrusive.

Best
Eliot


>
>
> >>
> >> > Cheers,
> >> >  - Andreas
> >> >
> >> --
> >> Best regards,
> >> Igor Stasenko AKA sig.
> >
> > Best
> > Eliot
> >
> >
> >
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090301/335a127f/attachment.htm


More information about the Squeak-dev mailing list