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

[Eliot Miranda]

Hi Nicolas, Hi Clément,

> On Dec 22, 2017, at 6:30 AM, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com> wrote:
> 
> 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

Agreed!

So what this suggests to me is that the right way to go about this is to

- implement the primitives as Clément proposes, using numbered primitives for the performance critical ones, and implementing them in the JIT.

- rewrite all the MiscPrimitivePlugin primitives as methods on MiscPrimitivePlugin using smart syntax slang, dropping the translatedPrimitives hack.  Compile MiscPrimitivePlugin as an external plugin, included for backwards compatibility.


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