Hi all,
I'm trying to set literals as read-only in Pharo. I've got this problem
with this Misc primitive:
translate: aString from: start to: stop table: table
"translate the characters in the string by the given table, in place"
<primitive: 'primitiveTranslateStringWithTable' module:
'MiscPrimitivePlugin'>
<var: #table declareC: 'unsigned char *table'>
<var: #aString declareC: 'unsigned char *aString'>
start to: stop do: [ :i |
aString at: i put: (table at: (aString basicAt: i) + 1) ]
The primitive mutates aString without checking if it's read-only.
What is the right way in Smart syntax plugin to add the read-only check ?
Best,
--
Clément Béra
https://clementbera.github.io/https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq*
Hi all,
*The short version:*
After looking into MiscPlugin with Eliot, we decided to work on a numbered
primitive to speed up String comparison especially String>>#= (which
matters for parsers that are widely used by our communities) as a long-term
replacement for compare:with:collated: Misc primitive. Being numbered
allows the JIT to have an entry for it. We (likely Eliot) will work on
other Misc primitives to compile them differently in the future (No
Smalltalk level smart syntax to ease cross language management) but aside
from String comparison, they will remain in a plugin, since they're not as
critical.
The new primitive is as follow (optional last parameter so 2 versions):
ByteString >> *compareWith:* anotherString
ByteString >> *compareWith:* anotherString *collated:* order
"Return a negative Smi, 0 or a positive Smi if self is < = or > to
anotherString, with the collating order of characters given optionally by
the order array."
Preliminary benchmarks show 20 to 600x speed-up in String comparison (< <=
= > >= on Strings; 600x on small strings, 20x on large strings). String
comparison does not use any more the optional last parameter, only other
APIs do. Sophie in CC did the bulk of the work as part of a 100h student
project, though various discussion in the mailing list involving many of us
but especially Levente, Eliot and me helped a lot. There are still some
tests to write to make sure everything is stable before integration, but my
understanding is that integration should happen anytime soon. Sophie, could
you please answer a time frame for integration to this mail?
*The long version:*
The blog version includes assembly code, Cog's RTL code & Slang code for
each version as well as the exact preliminary benchmarks we ran:
https://clementbera.wordpress.com/2018/02/17/massive-string-comparison-perf…
Levente maybe you want to review the long version in my blog if you have
comments/advises before integration. I guess you will write accurate
micro-benchmarks once it's integrated anyway.
This LLVM/GCC performance difference is very annoying though for correct
evaluation of speed-ups, I wonder, have any one seen a difference there
before for other primitives? PrimitiveStringReplace might have similar
issues. I don't know if we could report those things as bugs to the LLVM
people somehow.
Best,
--
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
Hi.
It is just a question from the space :)
I wonder, can we be a JavaScript engine? Like replacing nodeJs with
Pharo/Squeak.
I imagine that JS prototypes can be easily supported by anonymous classes.
What is missing?
Best regards,
Denis