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

Fri Dec 22 20:17:15 UTC 2017

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