[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