On 12/19/2015 04:23 PM, Eliot Miranda wrote:

On Fri, Dec 18, 2015 at 11:25 PM, Robert Withers <robert.w.withers@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@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



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@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