[Vm-dev] following branches and Sista

[Clément Bera]

Hi Eliot,

I've never realised this.

My problem was that in benchmarks such as Richards I had issues with
methods such as:

SMarkRichTaskState>>isTaskHoldingOrWaiting
    ^taskHolding or: [packetPending not and: [taskWaiting]]

which would get really slow due to counters. I believe this method should
have zero or one counter, not 2. I implemented the cheap heuristic to
remove counters on and:/or: for this purpose.

It would be better to have counters on the outermost if (in this case the
or:) instead of the innermost (in this case the and:) for sure.

Now I don't think it matters that much because most counters trip on loops
and most loops are following the #to:by:do: pattern where there is one
condition then branch.

I would like to experiment in the future with other counting logic (more
counters for more accurate profiling information), so I don't know if it
matters to fix that now. I think the next step is either profiling more
accurately, allocation optimisations or changes in the in-image compiler to
decrease compilation time (DeltaBlue can get -30% execution time with high
magic settings but unfortunately that means a huge slow down at first run
due to high compilation time).





On Mon, Jan 16, 2017 at 7:09 PM, Eliot Miranda <eliot.miranda at gmail.com>
wrote:

> Hi Clément,
>
>
>
>     I’m looking at following branches through unconditional jumps and
> through pushBoolean; branchIf’s and notice that the code in
> SistaCogit>>genJumpIf:to: preferentially adds a counter to the innermost
> conditional branch in a sequence of and:s and or:s.  I think we would
> prefer to have the counter at the outermost send, because this is the most
> counted.  Have you thought about this?  What do you think?
>
>
> _,,,^..^,,,_
> best, Eliot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170116/a674a560/attachment.html>