[Vm-dev] pluginizing Galois Fields

Robert Withers robert.w.withers at gmail.com
Sat Dec 19 07:25:48 UTC 2015



On 12/19/2015 02:09 AM, Eliot Miranda wrote:
>   
>
>
> Hi Robert,
>
> On Dec 18, 2015, at 9:51 PM, Robert Withers 
> <robert.w.withers at gmail.com <mailto:robert.w.withers at gmail.com>> wrote:
>
>> Eliot, what does Sista do and how is that accomplished?
>
> Run-time adaptive optimisation via an SSA-based image-level 
> bytecode-to-bytecode inlining compiler.  See
>
> http://www.mirandabanda.org/cogblog/on-line-papers-and-presentations/
>
>
>> It sounds like a next level kind of system. Does it compare to what 
>> other JITs are doing in various VMs?
>
> Yes it does. Clément recently attended a workshop at Google and found 
> that Sista is very similar in the kinds of optimisations it performs 
> to V8 and Dart.  The key research funding will be how close the 
> performance of targeting stack-oriented bytecode that the Cog JIT 
> converts to register-based code can be made to JITs that directly 
> target register-based machine code.

This sounds like you are saying that Sista performs better or more 
naturally with stack-oriented bytecode. If you wouldn't mind taking the 
time to explore it with us, what's the difference between stack-oriented 
and register-based code, such that Sista would be different between 
them? I'm off to read some.


>
> _,,,^..^,,,_ (phone)
>
>>
>> thank you,
>> robert
>>
>> .    ..               ... 
>>                                                 ^,^
>>
>>
>>
>> On 12/18/2015 11:11 PM, Eliot Miranda wrote:
>>>  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 
>>>> <mailto: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
>>>>
>>
>> -- 
>> . .. .. ^,^ robert

-- 
. .. .. ^,^ robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20151219/b7a49579/attachment-0001.htm


More information about the Vm-dev mailing list