[Vm-dev] Reed Solomon plugins & performance slow down

Robert Withers robert.withers at pm.me
Mon May 31 00:50:57 UTC 2021


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 ]].



More information about the Vm-dev mailing list