2013/6/27 Levente Uzonyi <le...@elte.hu>
> On Wed, 26 Jun 2013, Guillermo Polito wrote:
>
>
>> On Wed, Jun 26, 2013 at 11:20 PM, Levente Uzonyi <le...@elte.hu> wrote:
>> On Wed, 26 Jun 2013, Clément Bera wrote:
>>
>> Actually this code:
>> True basicNew ifTrue: [ "some code" ]
>> works fine on the latest Pharo 3 because of Opal :)
>>
>>
>> So the Opal compiler lacks important optimizations. :)
>>
>>
Actually Opal generates almost the same bytecode as the old compiler. As a
proof, Benchmarks run at the same speed when compiled with one or the other
compiler. So no lack of optimizations.
Moreover Pharo and Squeak cannot be compiled without optimizing control
flow structure or the compilation fails by image crash. This is due for
example to the implementation of BlockClosure>>whileTrue: .
>
>> Not at all. In fact, the the code is optimized and falls back to the
>> normal lookup in case of exceptional #mustBeBoolean, so the existing code
>> keeps running the same speed ;)
>>
>
> So it generates a bunch of extra bytecodes for every #ifTrue:, #ifFalse:,
> #ifTrue:ifFalse: and #ifFalse:ifTrue: messages, in order to make this thing
> work? Or is there a trick to avoid the duplicaiton of the code in the
> blocks?
>
>
I understood the problem.
In Pharo 3 we will support conditional optimized messages ( #ifTrue:,
#ifFalse:, #ifTrue:ifFalse: and #ifFalse:ifTrue: ) sent on non boolean
receiver. However, this feature will be slow, so one should not use it too
much (as #become:, #isKindOf:, ...). Basically Opal compiles on the fly
without optimizing it the conditional messageNode as a DoIt, run it, and
jump in the context to the pc corresponding to the next ast node. We don't
generate extra bytecode as you suggested, because it will grow the size of
the image a lot and slow down the system with extra conditions.
Right now the feature is still under development and very buggy (it is just
a prototype). It is activated only when Opal is set as default compiler,
which is wrong, and there is a bug report. This bug report will be fixed
during the sprint on Friday.
So actually I didn't look carefully enough but:
True basicNew ifTrue: [ "some code" ]
works fine because it sends it to a NonBooleanReceiver but Pharo 3 supports
#ifTrue: sent on a NonBooleanReceiver.
However, what you can do in Pharo 3 / Opal if you know explicitly that you
will send the optimized message to a NonBooleanReceiver, to avoid slowness
due to on the fly do it compilation, you can specify it to the compiler in
the class:
MyClass class>>#compiler
^ super compiler options: #(- optInlineIf)
or in the method :
MyClass>>#foo
<compilerOptions: #(- optInlineIf)>
^ #myNonBooleanObject ifTrue: [ 1 ] ifFalse: [ 0 ]
There are different options like this one. I wrote them down here to
remember (section compilerOptions):
http://clementbera.wordpress.com/2013/05/28/modular-compilation-with-opal/
But it is not very nicely written, I've just write it to remember ..
Compiler options as this one are not for daily use, there are here to
enable some stuff like boolean proxies.
> Levente
>
>
>
>>
>>
>> Levente
>>
>>
>> But nice trick for the old compiler :)
>>
>>
>> 2013/6/26 Nicolas Cellier <nicolas.cellier.aka.nice@**
>> gmail.com <nicolas.cellier.aka.n...@gmail.com>>
>> Because you don't know the tricks... This one should be
>> just fine
>>
>> True basicNew ifTrue: [ "some code" ] yourself
>>
>>
>> 2013/6/26 Clément Bera <bera.clem...@gmail.com>
>> True basicNew ifTrue: [ "some code" ]
>>
>> hehe raises NonBooleanReceiver :)
>>
>>
>> 2013/6/26 Camillo Bruni <camillobr...@gmail.com>
>> why not, let's "forbid" them with an error message!
>>
>> => maybe you can and error to #become: on nil / true /
>> false as well?
>>
>> On 2013-06-26, at 14:20, Torsten Bergmann <
>> asta...@gmx.de> wrote:
>>
>> > Boolean new -> error
>> > Boolean basicNew -> is possible
>> >
>> > should we care?
>> >
>>
>>
>>
>>
>>
--
Clément Béra
Mate Virtual Machine Engineer
Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq*
