[Vm-dev] pluginizing Galois Fields

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



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 <mailto: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 <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.
>
>
> 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 <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
>
>
>
>
> -- 
> _,,,^..^,,,_
> best, Eliot

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


More information about the Vm-dev mailing list