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

Robert Withers robert.withers at pm.me
Tue Jun 1 18:43:43 UTC 2021


Hey ya, Levente,

Woot!!! I was able to get all the primitives working with ByteArrays. Everything is passing green! (except for several GF fields: Aztec and Maxicode and QRCode) I think I will primitize one of the codingLoops on the RSErasure side. Here are the numbers. Take note of the tallies and time: 50 seconds versus 114 seconds.

I updated the squeak wiki Cryptography page (http://wiki.squeak.org/squeak/5776) with d/l links to the plugins. Here are those links:

[1] RSErasurePlugin - https://www.dropbox.com/s/kog96d3pqentket/RSErasurePlugin.so?dl=1
[2] RSFECPlugin - https://www.dropbox.com/s/a1vvihi7o2fqtkj/RSFECPlugin.so?dl=1

Thanks so much for your help! You are an angel!
Robert

> WITH PLUGINS
>
> - 49238 tallies, 50468 msec.
>
> **Leaves**
> 13.0% {6580ms} RSFECDecoder>>decode:twoS:
> 7.8% {3931ms} RSErasureGaloisWithPlugin>>galoisMultiply:by:
> 6.8% {3450ms} RSErasureGaloisWithPlugin>>addOrSubtract:by:
> 6.1% {3063ms} RSErasureGaloisWithPlugin>>maskValue:
> 6.1% {3053ms} RSFECGenericGFPoly class>>newField:coefficients:
> 4.0% {2032ms} RSFECDecoder>>findErrorLocations:
> 2.4% {1197ms} RSErasureGaloisWithPlugin>>tableMultiply:by:
> 1.8% {917ms} RSFECGenericGFWithPlugin>>multiply:by:
> 1.7% {877ms} [] RSErasureOutputByteInputExpCodingLoop>>codeSomeShardsGalois:matrixRow...:outputCount:offset:byteCount:
> 1.6% {823ms} RSErasureGaloisWithPlugin>>normalizeInImageIndex:
> 1.2% {609ms} RSFECDecoder>>findErrorMagnitudes:errorLlocations:

And:

> WITHOUT PLUGINS
>
> - 112019 tallies, 114572 msec.
>
> **Leaves**
> 20.2% {23095ms} RSFECGenericGF>>exp:
> 12.0% {13745ms} RSFECGenericGF>>addOrSubtract:by:
> 10.8% {12381ms} RSFECGenericGF>>maskValue:
> 7.8% {8910ms} RSFECGenericGF>>log:
> 7.6% {8655ms} RSFECGenericGF>>normalizeIndex:
> 6.0% {6931ms} RSFECGenericGF>>multiply:by:
> 3.1% {3508ms} RSFECGenericGFPoly>>evaluateAt:
> 2.8% {3190ms} RSErasureGalois>>maskValue:
> 1.9% {2182ms} RSErasureGalois>>normalizeIndex:
> 1.8% {2009ms} RSFECGenericGFPoly>>addOrSubtractPoly:
> 1.7% {2003ms} RSFECGenericGFPoly>>multiplyByMonomialDegree:coefficient:
> 1.4% {1564ms} RSErasureGalois>>log:
> 1.3% {1522ms} RSErasureGalois>>galoisMultiply:by:
> 1.2% {1350ms} RSErasureGalois>>exp:
> 1.1% {1308ms} RSErasureGaloisTest(TestCase)>>assert:description:

---
Kindly,
Robert

On 5/31/21 8:27 PM, Robert Withers wrote:

> Awesome, Levente! My bad. Thanks so much! So glad you were able to clear
> it up. I will make the appropriate changes. As the field size is max
> 256: { 0-255 }, perhaps using ByteArrays everywhere would be better. I
> should make sure ParrotTalk uses them as well. In 64-bit VMs are
> "unsigned ints" 64 bits? Thus the DoubleWordArray?
>
> ---
> Kindly,
> Robert
>
> On 5/31/21 8:05 PM, Levente Uzonyi wrote:
>
>> Hi Robert,
>>
>> After a quick look, the problem seems to be that you're reading the first
>> parameter, selfCoefficientsOop with #stackIntegerValue:, but the parameter
>> is an array, not an integer, so it needs to be read with #stackObjectValue:.
>> I don't think #stSizeOf: does any good when its argument is an integer
>> oop, hence the crash.
>>
>> For simplicity and efficiency, I suggest you should pass a WordArray to
>> the primtive (and use WordArrays in the image as well). It maps to the
>> unsigned ints the primitive uses, and you can use #firstIndexableField:
>> safely.
>> Passing an Array would complicate things, as an Array can hold any kind of
>> objects (which the primitive would have to check before using them), and
>> its field size doesn't fit into an unsigned int on 64-bits.
>>
>> Also, validation of the arguments should be strict in the primitive. Have
>> a look at e.g. DESPlugin >> #primitiveDESTransform to see how it validates
>> its two arguments, a ByteArray and a WordArray.
>>
>> Levente
>>
>> P.S.: If the coefficients fit into smaller fields, it's worth to use a
>> ByteArray or a DoubleByteArray instead of a WordArray for better
>> performance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20210601/72d35cf5/attachment-0001.html>


More information about the Vm-dev mailing list