Re: [Gretl-devel] basic Julia support

On Thu, 21 Jan 2016, Sven Schreiber wrote: > Am 21.01.2016 um 21:02 schrieb Riccardo (Jack) Lucchetti: > >> >> >> Oh, it's very easy. All these super-fast languages use some form of JIT. >> The big difference between Matlab and Octave, for example, comes from >> Octave being a classic interpreted language, while Matlab switched to a >> microcode+VM architecture some time ago. Julia just happens to be build >> on top of LLVM, which is a notoriously fast VM. > > Ok, but why then do many (?) examples here show the same speed between > hansl (interpreted) and Julia (JIT-compiled)? Are the examples so tiny > that the JIT overhead outweighs the other speed gains, or what's going on? It's hard to say in general. However, the heaviest penalty is when you do "lots of small things": for example, big nested loops, lots of recursion, lots of user-function calls, lots of conditionals, stuff like that. >> In principle, Hansl could display similar performance, if we had the >> resources to rewrite the whole interpreter code as a front end to LLVM. >> Believe me, it's a HUGE job. > > I believe you, and I am continuing to admire the extent to which gretl > is competitive or more in terms of speed. At the end of the day, > however, the underlying reason doesn't matter for the customers. Perhaps > it will become necessary, for example, to allow some foreign language > also in gretl function packages, when that enables the package author to > work around a serious speed bottleneck. (The value added of the foreign > language of course would have to be demonstrated in the concrete case.) Hmmm. I'm not convinced, but I'm open to discuss the possibility in the longer run. However, my first best would still be finding the resources (time, manpower and skills) necessary to re-implement hansl as a JIT language. My guess is that someone with a PhD in CompSci, familiar with compiler design would do this comfortably in a year or so.