Hi Levente,
Thank you for having a look-see and letting me know your thoughts! It makes sense what you are saying. so I think the only way to speed it up is to embed the loops into primitives. I have 5 of 6 methods from Poly that I am stuffing into the plugin. The #dividePoly: is a bit more complicated, updating the remainder poly and so forth. I do not think a Poly can be within a primitive. Hopefully, {product := Array new: size withAll: 0} will work in translation. I fixed #initializeExpTable per your suggestion.
Thanks!
--- Kindly, Robert
On 5/30/21 8:18 PM, Levente Uzonyi wrote:
Hi Robert,
I had a quick look at the plugin code. The operations you implemented in the plugin are way too simple. The VM's JIT makes the smalltalk code run faster, because it has the same operations implemented, and it can avoid calling the overhead of calling the primitive many times. Hence the slowdown.
For example, RSFECPlugin >> #primitiveAddOrSubtractby seems to implement bitwise xor on two 32-bit unsigned values, but the arguments are always 0-255. The VM has primitive 16, which does bitwise xor and covers that input range, so the JIT, combined with other operations can generate machine code directly with that without jumping back and forth between native code and smalltalk.
If you want a plugin to provide any noticable speedup, you need to do more computation in a single primtiive call.
Levente
P.S.: I think, in RSFECGenericGC >> #initializeExpTable, the lines
x := x bitXor: primitive. x bitAnd: (size - 1)]].
should read
x := (x bitXor: primitive) bitAnd: size - 1 ]].