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

[Eliot Miranda]

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 :-)

> 
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20171222/30f73b84/attachment-0001.html>