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

2009/3/1 Eliot Miranda <eliot.miranda@gmail.com>:

>
>
> On Sun, Mar 1, 2009 at 12:23 PM, Igor Stasenko <siguctua@gmail.com> wrote:
>>
>> 2009/3/1 Andreas Raab <andreas.raab@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@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@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.