[Vm-dev] pluginizing Galois Fields

[Eliot Miranda]

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>
> 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> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20151219/c4e5dbec/attachment-0001.htm