[Vm-dev] pluginizing Galois Fields
Robert Withers
robert.w.withers at gmail.com
Sat Dec 19 21:55:50 UTC 2015
Eliot, I read what you wrote about a partial read barrier (to own memory
for scans?) to support fast become which allows for forwarders in the
stack execution. Is this right? If so it is a read barrier into
ObjectMemory. And so I think the forwarders access the CPIC somehow.
I was under a different conceptualization...that if you had a read-only
mode, where all non-local/temp variables were immutable (you could set
local vars), then more than one OS thread could be in the image, if only
one had the write lock. Perhaps this is a write barrier.
The idea being that the lookup could occur separately from the
invocation and could be threaded. Just a thought and I am not sure
where it may fit. Please carry on.
best,
robert
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.
>
>
>
>>
>> _,,,^..^,,,_ (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/09816045/attachment-0001.htm
More information about the Vm-dev
mailing list