[Vm-dev] Implicit Character -> Integer conversion with basicAt:

[Clément Bera]

For this case, it can infer everything. It does not yet optimize
successfully the loop without crashes.

But it's been almost 5 years that the Sista project has been going on. When
I started, there was already a prototype. It took 3 years to get benchmarks
running with little speed-ups. It took a 4th year to get benchmarks showing
2x performance boost and have a benchmark at 10x to show the potential of
Scorch. There is still so much to do to get it to production...

Specifically, there are specificities to our closures: we don't have LIFO
closure like Lars' Smalltalks, we have a reference to outerContext unlike
Javascript, etc. That's a problem mostly solved with FullBlocks but there's
still so much work to do there.

I don't know if on the short term we should take decisions on how to write
code in our code bases based on Scorch.


On Mon, May 7, 2018 at 5:12 PM, Eliot Miranda <eliot.miranda at gmail.com>
wrote:

>
> Hi Clément,
>
>     I provoked some protest last week by rewriting
>
> String>>isAsciiString
>     ^self allSatisfy: [ :each | each asciiValue <= 127 ]
>
> as
>
> String>>isAsciiString
>     1 to: self basicSize do: [:i| (self basicAt: i) > 127 ifTrue:
> [^false]].
>     ^true
>
> The speed up is around 5x to 6x.
>
> The question comes does Scorch know that it can implicitly obtain
> Character asciiValue by substituting a suitable basicAt: for the at:, or is
> the chain of inference too complex (as yet)?
>
> _,,,^..^,,,_ (phone)




-- 
Clément Béra
https://clementbera.github.io/
https://clementbera.wordpress.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20180508/f1bfdb2a/attachment.html>