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

Clément Bera bera.clement at gmail.com
Sat Dec 23 08:56:51 UTC 2017


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/5b11474f/attachment-0001.html>


More information about the Vm-dev mailing list