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

Robert Withers robert.withers at pm.me
Mon May 31 19:43:29 UTC 2021


My previous email is awaiting approval as it is too big. I attached a crash.dmp. Here is the email with a link to the crash dump I placed on dropbox.

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

> 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

[]1 crash.zip - https://www.dropbox.com/s/qyq735yksmc4dbr/crash.zip?dl=0

>

---
Kindly,
Robert
---
Kindly,
Robert

On 5/30/21 8:50 PM, Robert Withers wrote:

> 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 ]].
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20210531/21f9d83c/attachment.html>


More information about the Vm-dev mailing list