2009/3/1 Eliot Miranda <eliot.miranda at gmail.com>:
>
>
> 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.

I don't agree with defining a kernel modularisation as a constraint :)
The constraint is when you saying: hey pals, you can't have a headless
image - use one with Morphic instead, and if you really really want
it, we invented a workaround - a headless mode in VM. ;)

> Best
> Eliot
>



-- 
Best regards,
Igor Stasenko AKA sig.