[Vm-dev] Fwd: MiscPrimitive plugin: plan for next 6 months, please read

Fabio Niephaus lists at fniephaus.com
Sat Dec 23 13:33:46 UTC 2017


Hi Clément,

Thanks for improving the VM with cleanups and refactorings like this!
I've opened issue #117 [1] to track the progress of this effort if you
don't mind :)

Best,
Fabio

[1] https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/177


On Sat, 23 Dec 2017 at 9:57 am, Clément Bera <bera.clement at gmail.com> wrote:

>
> Hi,
>
> Backward compatibility is no problem Eliot.
>
> First you can compile a VM with both the existing MiscPrimitivePlugin and
> the new plugins/numbered primitives so all images work fine.
> Second all MiscPrimitives are optional, so once MiscPrimitivePlugin
> support is dropped, everything is backward/forward compatible.
>
> Ok so it's decided.
>
> On Fri, Dec 22, 2017 at 9:17 PM, Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> wrote:
>
>>
>>
>>
>> 2017-12-22 17:49 GMT+01:00 Eliot Miranda <eliot.miranda at gmail.com>:
>>
>>>
>>> Hi Clément, Hi All,
>>>
>>>
>>> On Dec 22, 2017, at 2:28 AM, Clément Bera <bera.clement at gmail.com>
>>> wrote:
>>>
>>> Hi all,
>>>
>>> As I said earlier I am on my way through a student project (cc'ed) to
>>> re-write/split/kill MiscPrimitive plugin. The plugin is composed of:
>>> - 2 Bitmap primitives
>>> - 1 Sound primitive.
>>> - 6 ByteObject primitives
>>>
>>> I will discuss here what is plan for each category of primitives. I
>>> would like comments and Eliot's approval before moving forward with the
>>> student project.
>>>
>>>
>>> IMO you should definitely go ahead. There is s backwards compatibility
>>> issue so it would be good to coordinate with a major release and maybe we
>>> can still support older images with some name hack in the vm which
>>> continues to recognize the 'MiscPrimitivePlugin' name in primitive
>>> pragmas, mapping to the correct name.
>>>
>>>
>>> *2 Bitmap primitives*
>>>
>>> Those are the compress and uncompress Bitmap primitives. Tim suggested
>>> that we move the primitive to the BitBlt plugin (hence converting from
>>> SmartSyntax to Slang). I think this is the right thing to do. Agreed ?
>>>
>>>
>>> +1
>>>
>>> IIRC, Tim Rowledge wrote a primitive that uses smart syntax in the
>>> BitBlt plugin (BirBltSimulation) and so you don't have to use pure slang.
>>> You can at least use the smart syntax signature mechanism.  I think this
>>> means that it is wrong to say that the translated primitives are written in
>>> smart syntax.  They are written in a pure Smalltalk syntax that is
>>> different again from the syntax use to write primitives under
>>> SmartSyntaxPlugin (how confusing!! :-) )
>>>
>>> *1 Sound primitive*
>>>
>>> This primitive can simply be moved to the SoundGenerator plugin.
>>> SoundGenerator is also built using SmartSyntax. Agreed ?
>>>
>>>
>>> +1
>>>
>>> *6 ByteObject primitives*
>>>
>>> *1. translate: aString from: start  to: stop  table: table*
>>>
>>> This primitive seems to be unused. I suggest we move it from a primitive
>>> to plain Smalltalk code.
>>>
>>>
>>> +1
>>>
>>> *2. stringHash: aString initialHash: speciesHash*
>>>
>>> Since we now have hashMultiply as a primitive, the stringHash primitive
>>> is now faster for very small strings with a Smalltalk version using
>>> hashMultiply, and slower (2x) on medium to large strings. I suggest we move
>>> it to plain Smalltalk code.
>>>
>>>
>>> +1.  And I've already suggested we sample a subset of elements for large
>>> strings, so we could beat the primitive if, say, we sampled no more than
>>> some large number of characters for very large strings.
>>>
>>> *3. findFirstInString, indexOfAscii, findSubString*
>>>
>>> For these 3 primitives we can either add a ByteStringPlugin or add them
>>> as numbered primitive.
>>>
>>>
>>> Whatever you do it would be really nice not to break vm backward
>>> compatibility/image forward compatibility.  Otherwise this should be
>>> coordinated with a major release and we should provide a file in for older
>>> images.
>>>
>>> *4. compare: string1 with: string2 collated: order*
>>>
>>> This primitive is really important for performance, there are production
>>> application spending a huge amount of times for string equality. I suggest
>>> that we move this one to a numbered primitive that takes 2 or 3 parameters,
>>> the order being optional, and to rewrite the version without order (i.e.
>>> the version used by String>>#=, String>>#>, String>>#>=, etc.) in the JIT
>>> (numbered primitives are required for that).
>>>
>>>
>>> +1.  Do you imagine the primitive being polymorphic in element widths
>>> (being able to compare an n byte string with an m byte string)?  There are
>>> only 8 combinations.
>>>
>>> Alternatively we can add a numbered String>>#= numbered primitive and
>>> put the compare primitive in a ByteStringPrimitive.
>>>
>>>
>>>
>>>
>>> *5. String concatenation*
>>>
>>> I would suggest to add in addition ByteString>>#, as a primitive. String
>>> concatenation is really important performance wise and that will ease
>>> deforestation (i.e. removing the allocation of temporary byte strings) in
>>> the Sista JIT which is quite difficult right now.
>>>
>>>
>>> Sure, but it might be better to investigate tree strings with O(1)
>>> concatenation.  Mapping tree strings to flat strings would then occur in
>>> primitive failure code of primitives expecting flat strings.  IIUC
>>> JavaScript VMs use tree strings right?
>>>
>>>
>>> *Conclusion*
>>>
>>> The main question is do we want 1 numbered primitive and 3-5 primitives
>>> in a small ByteStringPlugin, or do we want 3-5 numbered primitive. I don't
>>> mind either.
>>>
>>>
>>> The main question here is what the backward compatibility story is.
>>> What you're proposing will break backwards compatibility meaning older Spur
>>> images will not be able to run on new VMs.  That's ok only if we coordinate
>>> these changes with a major release.
>>>
>>> There's a smaller intermediate step which is to eliminate the Smalltalk
>>> syntax for MiscPrimitivePlugin and simply rewrite it using traditional
>>> smart syntax slang as methods on MiscPrimitivePlugin.  Perhaps we could add
>>> some mechanism to invoke jitted versions of these primitives for the
>>> performance critical ones, but it sounds like a lot of work.
>>>
>>> To be clear, Clément, I like the conceptual clarity of your proposal,
>>> and would be fully behind if we're if not for backward compatibility.  It
>>> would be preferable to me if we can add some hack to use your new scheme
>>> but still run older images unchanged.  This hack can then be discarded some
>>> time in the future.  I don't want to have to maintain legacy VMs :-)
>>>
>>>
>> Hi Eliot,
>> Aren't all these primitives optional?
>> Running an old image on a new VM woud fail to find primitives and
>> fallback to Smalltalk (slang) code.
>> That would mean that we don't have to maintain any compatibility at all
>> (old image + new VM would just be slower).
>> New image would require new VM, but we could also add fallback code to
>> make the primitives optional.
>>
>>
>>> I looked at the performance on the Sista VM, but there is still quite
>>> some work to make all of those efficient and in production. Recently other
>>> VMs (especially V8) decided to loose some peak performance in exchange for
>>> better baseline performance since many applications they were running were
>>> spending only 15-20% of the time in optimised code and 80-85% in baseline
>>> code, so primitive performance is a big deal no matter what we have in the
>>> future.
>>>
>>>
>>> +1
>>>
>>>
>>> Clément Béra
>>> https://clementbera.wordpress.com/
>>> Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq*
>>>
>>>
>>>
>>
>>
>
>
> --
> Clément Béra
> Pharo consortium engineer
> https://clementbera.wordpress.com/
> Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20171223/a6310e58/attachment.html>


More information about the Vm-dev mailing list