[Vm-dev] Class checks in the vm

Eliot Miranda eliot.miranda at gmail.com
Tue Apr 17 17:47:35 UTC 2012


On Tue, Apr 17, 2012 at 10:33 AM, Igor Stasenko <siguctua at gmail.com> wrote:

>
> On 17 April 2012 19:14, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> >
> >
> >
> > On Tue, Apr 17, 2012 at 9:54 AM, Igor Stasenko <siguctua at gmail.com>
> wrote:
> >>
> >>
> >> Performance, yes...
> >>
> >> But i wonder, how much performance we will lose by having more
> >> flexible implementation for ByteString..
> >>
> >> So, here what i did:
> >>
> >> ByteString>>bat: index put: aCharacter
> >>
> >>        ^ aCharacter putIntoByteString: self at: index
> >>
> >> Character>>putIntoByteString: string at: index
> >>
> >>        ^ value < 256
> >>                ifTrue: [ string basicAt: index put: value ]
> >>                ifFalse: [  string at: index put: self ]
> >>
> >>
> >> Now benchmark:
> >>
> >> | s chars |
> >>
> >> s := ByteString new: 1000.
> >> chars := (1 to: 255) collect: [:i | Character value: i ].
> >>
> >> [
> >> 1 to: 1000 do: [:i |
> >>        chars do: [:char| s at: i put: char ]
> >>        ].
> >> ] bench
> >>
> >>  '105 per second.'
> >>
> >> | s chars |
> >>
> >> s := ByteString new: 1000.
> >> chars := (1 to: 255) collect: [:i | Character value: i ].
> >>
> >> [
> >> 1 to: 1000 do: [:i |
> >>        chars do: [:char| s bat: i put: char ]
> >>        ].
> >> ] bench
> >>
> >>
> >>  '91.9 per second.'
> >>
> >> ~10%...
> >>
> >> Such kind of difference is IMO laughable,
> >
> >
> > I disagree.  10% is a significant loss of performance.  It can take huge
> effort to gain 10% in a VM implementation.  It is not at all laughable.
>  Cog is significantly faster than the Interpreter (by factors of 3 or 5).
>  And that performance difference is worth-while.  The straw man below isn't
> a convincing argument either.  I don't see what is wrong with using a
> slower more flexible VM for bootstrapping (or indeed a simulation, or ...).
>  But do we really have to spend time arguing this point?  If you think you
> can do better, then  do so.  Build a more flexible VM.  Then we can compare
> the two.
>
> Calm down, Eliot. I am not challenging and don't want to be
> challenged. Yes, we can squeeze 1 or 2 % here and there, but at costs
> of having additional constraints/contracts like compact classes,
> ifTrue/ifFalse inlining etc.. which , if we follow that path all the
> way, we end up with strongly typed system like C or Java and little
> room for smalltalk powers.
>

I'm not uncalm :)  I just get frustrated with these performance arguments,
having a coherent vision for better performance and having failed to make
satisfactory progress.  The better object representation followed by more
machine-code primitives step will get another factor of 2 and result in a
simpler VM (immediate characters for example).  Speculative
inlining/adaiptive optimizing in Smalltalk will get another factor of 3.
 But I'm not paid to work on these things.  And I find having discussions
about small points like this adds to my frustration because they're not
getting us very far and I feel I'm wasting my breath.  Sorry...



>
> The good question is where to put optimizations to not constrain the
> system more than necessary and do not sacrifice flexibility in favor
> of speed.
>

Right.  Better object representation, followed by speculative inlining.


>
> --
> Best regards,
> Igor Stasenko.
>



-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20120417/7f24ad0f/attachment-0001.htm


More information about the Vm-dev mailing list