[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