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.
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. 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 :) Regards, Thierry