[Vm-dev] New Cog VMs available

[Clément Bera]

Hi Holger,

I'm sorry for the delay since you reported the bug. Everyone working on the
VM is very busy (In my case, my time is consumed by my phd and sista, I'm
trying to open an alpha of the image+runtime before ESUG running at ~1.5x).

Now that the VM profiler is fully working I was able to look into the
regression.

Old VM vanilla code:

27.94%    (11.54%) scavengeReferentsOf (528) (27.94%)
10.21%    (  4.22%) processWeakSurvivor (193) (38.15%)
  8.15%    (  3.36%) copyAndForward (154) (46.30%)
  7.41%    (  3.06%) doScavenge (140) (53.70%)
  5.19%    (  2.14%) lookupOrdinaryNoMNUEtcInClass (98) (58.89%)
  4.71%    (  1.94%) primitiveStringReplace (89) (63.60%)
  4.29%    (  1.77%) moveFramesInthroughtoPage (81) (67.88%)
  2.06%    (  0.85%) isWidowedContext (39) (69.95%)
[...]
  0.90%    (  0.37%) ceSendFromInLineCacheMiss (17) (85.61%)
  0.85%    (  0.35%) addNewMethodToCache (16) (86.46%)

New VM vanilla code:

% of vanilla vm code (% of total) (samples) (cumulative)
22.41%    (10.44%) scavengeReferentsOf (609) (22.41%)
*14.46%    (  6.74%) lookupOrdinaryNoMNUEtcInClass (393) (36.87%)*
  6.88%    (  3.21%) copyAndForward (187) (43.75%)
  6.59%    (  3.07%) processWeakSurvivor (179) (50.33%)
*  6.36%    (  2.97%) addNewMethodToCache (173) (56.70%)*
  4.19%    (  1.95%) doScavenge (114) (60.89%)
  4.08%    (  1.90%) primitiveStringReplace (111) (64.97%)
  2.91%    (  1.35%) moveFramesInthroughtoPage (79) (67.88%)
*  2.87%    (  1.34%) ceSendFromInLineCacheMiss (78) (70.75%)*
  2.21%    (  1.03%) marryFrameSP (60) (72.96%)
  1.80%    (  0.84%) executeNewMethod (49) (74.76%)
  1.36%    (  0.63%) isWidowedContext (37) (76.12%)

I highlighted the problematic methods. It is likely that it has to do with
slang inlining.

The 3 methods highlighted seems to be responsible for an overhead of ~8.5%
in the overall runtime. You seem to have an overhead of ~14% on my machine.
There's quite a difference. The slang inlining overhead may have impacted
other functions, and C profilers are never 100% accurate, so we will see
when the problem is fixed if something else is also problematic. Now that
we know what the problem is, I believe it will be fixed in the incoming
weeks when someone (likely Eliot, maybe me) has time. Thanks for reporting
the regression.

Regards

Clement


On Wed, Jul 6, 2016 at 8:00 PM, Holger Freyther <holger at freyther.de> wrote:

>
> > On 04 Jul 2016, at 20:59, Clément Bera <bera.clement at gmail.com> wrote:
> >
>
> Hi!
>
> > Is this problem solved or not ?
>
> not that I am aware of.
>
> kind regards
>         holger
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160707/3be1c61a/attachment-0001.htm