Hi Thierry,

On Wed, Sep 17, 2014 at 11:46 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:

Hi Eliot

Le 17/09/2014 19:18, Eliot Miranda a ��crit :

Hi Thierry,

Yes, and various dialects have a literal constructor for "compile-time
expressions" (I did one for VW) that provide a manual (and hence
fragile) way of doing this.�� As you pointed out this approach breaks
when one changes the code previously compiled.�� Having Sista regenerate
for you automatically�� is of course preferrable.�� But what do you mean
"do not have any effect in Squeak/Pharo anymore"?

It works but has no effect on performance. Well, this is an optimisation; you gain in certain circonstances, you loose in others and you turn it off.

�� I have colleagues in the same department working on localized,
�� template based JiT of computational kernels and they do 3 inst of
�� JiT for one instruction (and prove that they go faster on some
�� matrix math code, including the JiT overhead, than anything
�� statically optimised off-line).

Sure.�� My JIT optimizes and cannot be reduced to a template approach.
�� But it is still extremely fast.�� As I said, scanning code to
relink/compact/GC is what takes the time, not compilation itself.�� And
the pause times here are bounded (see below).

�� At the same time, a one ms pause at 2.2GHz is a hell of a long time
�� if your target is a MicroBlaze at 50 Mhz or an embedded powerpc at
�� 25 MHz.

Sure, there are bound to be contexts in which Cog can't meet the
required deadlines.�� But that doesn't imply it can never do real time,
does it?�� And processor speeds are climbing.�� Look at Raspberry Pi,
700MHz.�� Not too shabby.

This is the performance of an old desktop :) And a not so old at that. ARM started as a desktop processor, after all.

But, look: Python works very well on the Pi ;) Fast enough, and if not, you call a C lib.

and that's precisely what we want to avoid. ��IMO that;s one reason why the Python (and e.g. PHP) community has been so slow to implement good VMs. ��It has deferred to C code for performance-critical code _where it could_ (e.g. regular expressions) at the expense of rigid dependence on that external library. ��Now that companies such as Dropbox and Facebook are needing Python and PHP to exhibit good performance they are finally implementing faster VMs long after other languages. ��This has meant that Python libraries have not evolved as fast or as conveniently as could have happened if there was no dependency on C.

Of course the situation with Squeak was/is the same, with a proliferation of plugins that would not be necessary if the VM were fast. (of course some plugins exist for good security reasons).

�� The problem is that even a simple JiT is considered too much Jitter :)

But some in some contexts.�� But that doesn't define the entire real time
world.

Yes.

�� The Ocaml guys told once they had to do a special, interpreted VM
�� for a real-time use case. The problem is not going fast, the problem
�� is being predictable. They turn off CPU caches in some cases.

Sure.�� But if one can show that the JIT's pause times are bounded and
well spaced then there is no fundamental problem.�� People have been
implementing real-time GCs and using GC in real time systems for over 20
years now.�� This is no different.�� But you seem absolute in denying that
there is any possibility of using a JIT in real time.�� I think that
claim is clearly false.

If we consider that you would have to do a WCET analysis / stack boundedness analysis to prove that the JIT pauses are deterministic, bounded and are schedulable for the target times (i.e. suitable for a significant part of what real time is about), then that claim will hold true for a while.

Right.

If we change and adjust the definition of real-time and the required processing power needed, then we can consider Cog JIT sufficiently real-time as long as it is reasonably deterministic.

This is my opinion on that: for what I have done in the embedded world and on FPGA so far, any gain on the determinism, performance and portability of Cog is highly significant(*); but I would really like that the language running on top of Cog, and Cog, be able to clearly let a programmer specify bounds / determinism requirements / parallelism so as to ensure that it may communicate well with real-time programs. And then it would be a really nice fit, and a huge boost to both Cog and the Embedded/RT community.

(*) And those benefits would also make it really cool to use everywhere.

(**) A nice target would be to be able to run Cog on a SoC with a general purpose CPU core and a FPGA.

(***) and then I could reuse what I know about synthesizing logic circuits on a FPGA from smalltalk code :)

I look forward to working with you on this! ��We may be a few years behind this curve in first getting Sista and the FFI and 64-bits done, but soon enough we will be ready to tackle challenges like this!

Regards,

Thierry

--
best,

Eliot