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

[Clément Bera]

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.

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