I implemented a set of 5 primitives for Polynomial math in the RSFECPlugin class and added a RSFECGenericGFPolyWithPlugin to call them. In testing FEC I get a segFault, but looking at the Smalltalk stack dump it is happening in the RSErasurePlugin which is not called by the RSFEC code. It looks like a DoIt and I cannot find the offending code. Where can I look for a DoIt that is calling RSErasure code when running RSFEC code? Here is the smalltalk stack dump and I am attaching the crash.dmp file.

    0x7ffde5e6a1b0 I RSErasureGaloisWithPlugin>galoisMultiply:by: 0xc7ed9d8: a(n) RSErasureGaloisWithPlugin
    0x7ffde5e6a220 I RSErasureGaloisWithPlugin>generateMultiplicationTable 0xc7ed9d8: a(n) RSErasureGaloisWithPlugin
    0x7ffde5e59df0 I RSErasureGaloisWithPlugin>initialize 0xc7ed9d8: a(n) RSErasureGaloisWithPlugin
    0x7ffde5e59e20 M RSErasureGaloisWithPlugin class(Behavior)>new 0x7fdeec8: a(n) RSErasureGaloisWithPlugin class
    0x7ffde5e59e60 I RSErasureGalois class>newGalois 0x6a89510: a(n) RSErasureGalois class
    0x7ffde5e59e90 M UndefinedObject>DoIt 0x2de78e0: a(n) UndefinedObject

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