[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