[Vm-dev] pluginizing Galois Fields

Robert Withers robert.w.withers at gmail.com
Sun Dec 20 06:55:32 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.

Having had a little bit of sleep, upon waking I just have to say I am 
disappointed in this response. As a seeker of knwoledge, I'm certainly 
willing to research deeply, yet that is a time investment when I also 
have a full plate. Nonetheless, the negative response to a search of 
knowledge is indicative of an attitude I often find and it is a real 
shame, a real shame for everyone. I reread what I wrote and yes, in the 
scope of an exploration, as I said, denotes a big time investment to 
dive deep. You could have said so, not a big time investment, but go 
towards more of a paragraph then a sentence in helping to feed me when I 
was hungry. A more paranoid personality that lives within me thinks it 
may have been something I personally did to garnish a more negative 
response, but I'm convinced it was the way I broached.

You see how I talk myself out of being frustrated? I try to stand in 
your shoes, for a moment, without ego nor assuming the worst. It works.


alright then, best,
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/20151220/00cc85ea/attachment-0001.htm


More information about the Vm-dev mailing list