<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
</head>
<body>
<p>Alright, Levente! Thank you so very much! You are a generous soul
& an angel! Your suggestions (the first two) worked like a
charm and I have a running plugin to GF arithmetic, GFPoly
arithmetic and RSDecoder arithmetic {#findErrorLocation: &
#findErrorMagnitudes:errorLocations:} both plugganized. The <strong>cumulative
speedup is 568%</strong> and all the hotspots changed again.</p>
<p>I tried to implement GFPoly>>#initializeField:coefficients:
in a plugin function, but my image is crashing on startup, when
standard GFs are created in GF class>>#startUp:, when each
GF initializes it attempts to create a one and a zero polynomial.
This would call the primitive for #initializePoly. This code can
be seen in the package: CryptographyRSFECPluginsInitializeGFPoly.
I am attempting to run:</p>
<blockquote>
<p> (firstNonZero > coefficientsLength)<br/>
ifTrue: [<br/>
mutableCoefficients := <b>interpreterProxy</b><b><br/>
</b><b> instantiateClass:
interpreterProxy classByteArray</b><b><br/>
</b><b> indexableSize: 1</b>]<br/>
ifFalse: [<br/>
mutableCoefficients := <b>interpreterProxy</b><b><br/>
</b><b> instantiateClass:
interpreterProxy classByteArray</b><b><br/>
</b><b> indexableSize:
(coefficientsLength - firstNonZero + 1)</b>.<br/>
<br/>
</p>
</blockquote>
<p>The <strong>cumulative speedup is 568%</strong> and all the
hotspots changed again. Here are the profiling results from just
the RSFEC code alone, no RSErasure code is in the profiles. The
new hotspots are, with RSFECPlugin, then without.</p>
<blockquote>
<pre class="lang-c s-code-block hljs"><code><span class="hljs-function"><font size="+1"><i><b><code><span class="hljs-function">((128683</span></code></b></i><i><b> / 22648) asFloat * 100) asInteger = 568%</b></i></font>
</span></code></pre>
</blockquote>
<p>The remaining potential plugganization relates to complex object
instantiation inside the plugin functions. {#decode:twoS:,
#runEuclideanAlgorithm: and #initializeField:coefficients:}. The
best value for work return is to plugganize
#initializeField:coefficients: at 3.3 seconds (14%)</p>
<blockquote>
<pre class="lang-c s-code-block hljs"><code><span class="hljs-function">WITH GF & GFPOLY PRIMITIVES AND DECODER <span class="hljs-title">PRIMITIVES</span>
<span class="hljs-params">(<span class="hljs-number">3</span> asterix <span class="hljs-keyword">for</span> in-progress plugganization)
</span> - 22194 tallies, 22648 msec.
</span></code><code><span class="hljs-function">**Leaves**
29.1% </span>{<span class="hljs-number">6586</span>ms} RSFECDecoderWithPlugin>>decode:twoS:
<span class="hljs-number">14.7</span>% {<span class="hljs-number">3329</span>ms} RSFECGenericGFPoly <span class="hljs-class"><span class="hljs-keyword">class</span>></span>>newField:coefficients:
<span class="hljs-number">7.3</span>% {<span class="hljs-number">1646</span>ms} RSFECDecoderWithPlugin>>primFindErrorLocationsDegree:coefficients:result:fieldSize:
<span class="hljs-number">2.9</span>% {<span class="hljs-number">654</span>ms} RSFECDecoderWithPlugin>>findErrorMagnitudes:errorLocations:
<span class="hljs-number">1.0</span>% {<span class="hljs-number">237</span>ms} RSFECDecoderWithPlugin>>runEuclideanAlgorithmPoly:poly:rDegrees:</code></pre>
</blockquote>
<pre class="lang-c s-code-block hljs"><code></code>Calls to plugganized GF/GFPoly methods:</pre>
<blockquote>
<code><span class="hljs-number">1.4</span>% {<span class="hljs-number">317</span>ms}
RSFECGenericGFWithPlugin>><span class="hljs-built_in">log</span>:
</code></blockquote>
<p>And:</p>
<blockquote>
<pre class="lang-c s-code-block hljs"><code>WITHOUT GF & GFPOLY PRIMITIVES - NO RSFEC PRIMITIVES
- <span class="hljs-number">98352</span> tallies, <span class="hljs-number">128683</span> msec.
**Leaves**
GF arithmetic
<span class="hljs-number">23.4</span>% {<span class="hljs-number">30126</span>ms} RSFECGenericGF>><span class="hljs-built_in">exp</span>:
<span class="hljs-number">13.4</span>% {<span class="hljs-number">17229</span>ms} RSFECGenericGF>>addOrSubtract:by:
<span class="hljs-number">11.9</span>% {<span class="hljs-number">15251</span>ms} RSFECGenericGF>>maskValue:
<span class="hljs-number">10.0</span>% {<span class="hljs-number">12916</span>ms} RSFECGenericGF>><span class="hljs-built_in">log</span>:
<span class="hljs-number">8.6</span>% {<span class="hljs-number">11059</span>ms} RSFECGenericGF>>normalizeIndex:
<span class="hljs-number">6.8</span>% {<span class="hljs-number">8792</span>ms} RSFECGenericGF>>multiply:by:
GFPoly arithmetic
<span class="hljs-number">2.7</span>% {<span class="hljs-number">3529</span>ms} RSFECGenericGFPoly>>evaluateAt:
<span class="hljs-number">2.1</span>% {<span class="hljs-number">2715</span>ms} RSFECGenericGFPoly>>addOrSubtractPoly:
<span class="hljs-number">2.0</span>% {<span class="hljs-number">2578</span>ms} RSFECGenericGFPoly>>multiplyByMonomialDegree:coefficient:</code>
<code><span class="hljs-function"></span></code></pre>
</blockquote>
<div class="moz-signature">---<br/>
Kindly,<br/>
Robert<br/>
<br/>
<br/>
</div>
<div class="moz-cite-prefix">On 6/3/21 8:43 PM, Levente Uzonyi
wrote:<br/>
</div>
<blockquote type="cite" cite="mid:alpine.DEB.2.02.2106040230370.30557@login03.caesar.elte.hu">
<pre class="moz-quote-pre" wrap="">Hi Robert,
I see the following potential causes:
In #findErrorLocationsDegree:coefficients:count:fieldSize:result: the
return value in ambiguous. You make the primitive fail if not enough
errors are found. But after the send, you don't check for failure
but simply send #methodReturnReceiver.
Instead, you should either check for primitive failure after the send
or make #findErrorLocationsDegree:coefficients:count:fieldSize:result:
return boolean value: the method was successful or not.
E.g. when numErrors = 1, return true, in the other branch, return e =
numErrors. (If slang doesn't support boolean types, just use 0 and 1).
In the actual primitive method, check for the value returned by that
method and fail the primitive when needed. Once the primitive has failed,
you ought to return from it.
I see the above pattern in other methods too (marking the primitive as
failed in a not-top-level method without checking for failure outside).
Those need to be fixed as well.
Another potential issue I see is that the validation of the arguments is
not complete.
E.g.: #stackIntegerValue: may have already set the primitive to failed if
the argument was not an integer. So, before continuing, that has to be
checked.
Another possible but unlikely problem is that you assume that both result
and coefficients have at least one field. But that may not be true which
can result in segfaults.
Levente
</pre>
</blockquote>
</body></html>