[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