[Vm-dev] pluginizing Galois Fields

Eliot Miranda eliot.miranda at gmail.com
Sat Dec 19 04:11:22 UTC 2015


Further, please keep the original Smalltalk non-primitive implementation around do that when we deliver Sista we can see how well we stack up against C.

_,,,^..^,,,_ (phone)

> On Dec 18, 2015, at 5:59 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> 
> 
>> On Fri, Dec 18, 2015 at 08:13:00PM -0500, Robert Withers wrote:
>> 
>>> On 12/18/2015 08:07 PM, David T. Lewis wrote:
>>> 
>>> If you are implementing your algorithm from scratch, then it would be
>>> nice if it could be done in Smalltalk, because that means we can all
>>> read it, play with it in the image, and write unit tests to validate and
>>> document its behavior. We can figure out the translation to C afterwords,
>>> once you have a good implementation in Smalltalk (and yes I will help
>>> with that).
>> 
>> I have a smalltalk implmentation that came from Google Java code and is 
>> fully implemented in squeak/pharo. I am intermittently fixing byte 
>> mutations in the payload, so it is working to a degree. Check out the 
>> classes GenericGF, GenericGFPoly and GaloisField to see the insides.  
>> FECEncoder and FECDecoder are calling the galoisField which builds a 
>> ReedSolomon Decoder. That last is where the error detection occurs.
>> 
>> Thank you all very much for looking out!
> 
> I guess my suggestion would be that once you have a fairly good working
> implementation that you are comfortable with from a functional point of
> view, then let's look at which methods in that implementation would benefit
> from being translated to primitives in C. It would be especially good if
> you can run a profiler on your Smalltalk implementation and see where the
> time is being spent. Those would be the things we would want to turn into
> primitives. But first things first, let's get it working 100% (not "to a
> degree") and then we can do the translation to primitives.
> 
> Dave 
> 


More information about the Vm-dev mailing list