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

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Fri Dec 22 14:30:16 UTC 2017


Hi Clement,


2017-12-22 11:28 GMT+01:00 Clément Bera <bera.clement at gmail.com>:

>
> 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.
>
> *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 Sound primitive*
>
> This primitive can simply be moved to the SoundGenerator plugin.
> SoundGenerator is also built using SmartSyntax. Agreed ?
>
> *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.
>
> *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.
>
> *3. findFirstInString, indexOfAscii, findSubString*
>
> For these 3 primitives we can either add a ByteStringPlugin or add them as
> numbered primitive.
>
> *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).
>
> Alternatively we can add a numbered String>>#= numbered primitive and put
> the compare primitive in a ByteStringPrimitive.
>
> Also let the primitive return standard -1,0,1 code as the rest of the
world instead of Squeak-only 1,2,3

*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.
>
> *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.
>
> 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.
>
>
> --
> 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/8adcfefc/attachment.html>


More information about the Vm-dev mailing list