[Vm-dev] Finally Time to Make Good on "Everything is a message send"?

[Denis Kudriashov]

Hi


> We don't want to give up that performance, but we would like to not get
> caught cheating either. This would be very simple if instead of raising the
> "must be boolean" error, we could simply retry the send as a regular
> message send.


This is already in Pharo :)

2017-09-18 15:32 GMT+02:00 Bert Freudenberg <bert at freudenbergs.de>:

>
> On Sun, Sep 17, 2017 at 3:51 PM, Sean P. DeNigris <sean at clipperadams.com>
> wrote:
>
>>
>> On the "Squeak Beginners" ML, a new Smalltalker wrote:
>> > I don't understand why Smalltalk doesn't allow me to have an or:
>> > method that takes a block argument (except on Boolean).
>>
>> The answer apparently was that the compiler replaces the code with an
>> optimization that is usually what one wants, and the actual message never
>> gets sent:
>> >    Ralph Johnson wrote
>> >    Yes, when the compiler sees   exp or: [ ... ] then it assumes that
>> > "exp" is
>> >   a boolean-valued expression and generates code that fails if it isn't.
>>
>> I remember the pain of tripping over these little "everything is a message
>> send to an object*" sins as a new Smalltalker. I wonder now, with the
>> incredible speed of Cog, Spur, Sista, etc., if these devil's bargains from
>> prior decades are still necessary. It would be psychologically satisfying
>> (and nice for newbies) to remove the asterisk from the principle above.
>>
>
> ​Yes, optimization of boolean-looking expressions is cheating that gets
> caught once in a while.
>
> But even in Cog it's still 400% faster:
>
> [false or: [true]] bench
>
>  '198,000,000 per second. 5.06 nanoseconds per run.'
>  '211,000,000 per second. 4.75 nanoseconds per run.'
>  '209,000,000 per second. 4.79 nanoseconds per run.'
>
> ... and again with #transformOr: disabled:
>
>  '47,100,000 per second. 21.2 nanoseconds per run.'
>  '47,500,000 per second. 21.1 nanoseconds per run.'
> '48,000,000 per second. 20.8 nanoseconds per run.'
> ​
> We don't want to give up that performance, but we would like to not get
> caught cheating either. This would be very simple if instead of raising the
> "must be boolean" error, we could simply retry the send as a regular
> message send.
>
> The major complication here is that in the byte code we don't know the
> original method selector (e.g. ifTrue:ifFalse: etc), and we do not have the
> original block closure arguments, because they never got constructed in the
> first place.
>
> There are various ways to tackle that problem with different speed/space
> tradeoffs. If we don't care too much about the non-boolean receiver
> performance (it's the slow path after all) then no modifications to the VM
> would be needed.
>
> You should be able to do it all in the #mustBeBoolean handler: perform the
> original selector with the block arguments, then jump to after the
> optimized block. Sounds like a fun, if not exactly trivial project :)
>
> - Bert -
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170918/c2b7a67e/attachment-0001.html>