[Vm-dev] pluginizing Galois Fields

Robert Withers robert.w.withers at gmail.com
Sat Dec 19 22:05:44 UTC 2015


Well, please excuse me from asking for time with no clear benefit when 
we both have so much going on, Eliot. I was looking for distraction as I 
am completely frustrated by my code riight now. The nexus of nested 
frames & headers, FEC encoding, ASN.1 encoding and pipeline processing 
order is totally challenging myself.

So, yes, it was a distraction request, my apologies.

robert
. ..  ...   ^,^

On 12/19/2015 04:40 PM, Robert Withers wrote:
>
>
> On 12/19/2015 04:23 PM, Eliot Miranda wrote:
>>
>> On Fri, Dec 18, 2015 at 11:25 PM, Robert Withers 
>> <robert.w.withers at gmail.com> wrote:
>>
>>
>>
>>     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> 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.
>>
>>
>> I'd rather not. That's something there's lots of papers on, and I'm 
>> not sure it's really important that I explain.  Yoiu can inform 
>> yourself, and the Sista talks I pointed to at least mention the 
>> topic.  I will say that our thesis is that we can generate efficient 
>> register-based machine code from stack-oriented bytecode, and that's 
>> one of the things we're trying to demonstrate with Sista.
>
> That's all very interesting to me, surely,just to know if not to 
> play.  It is the physics of this world and I studied that and am 
> oriented that way. Clement's talk touched on it (was it constructing 
> and deconstucting the machine code and rewriting the stack to point to 
> registers...I think).
>
> I was actually much more curious about this CPIC. Is there a write-up 
> about that so I minimize my distracting you?
>
> robert
>
>>
>>
>>>
>>>     _,,,^..^,,,_ (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> 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
>>
>>
>>
>>
>> -- 
>> _,,,^..^,,,_
>> best, Eliot
>
> -- 
> . .. .. ^,^ robert

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


More information about the Vm-dev mailing list