Re: [Gretl-devel] basic Julia support
On Thu, 21 Jan 2016, Sven Schreiber wrote:
Am 21.01.2016 um 16:10 schrieb Allin Cottrell:
> On Thu, 21 Jan 2016, Riccardo (Jack) Lucchetti wrote:
>
>
> For sure, that's an example of something that julia does a lot faster
> than gretl. But my notional prize is not yet awarded since if I insert
> this native function
>
>
> Your example shows that recursion is a _lot_ faster in julia; so now we
> want a case where recursion is actually needed.
>
Well I don't have a real use case for recursion, but we had a real use
case back at the gretl conference last year. One young guy (sorry I
forget his name, but I still remember the person very well, I think his
name starts with F (?)) presented timings with pretty bad gretl
performance compared to Matlab. IIRC it was a DSGE solution, so it's
clear that that is not really gretl's target audience, but still.
That was Federico Giri, who showed a hansl port of the RBC code by Jesus
Fernandez-Villaverde.
To be fair, hansl fared much worse than matlab, but much better than
octave, and more or less on par with R.
Plus, we know that the New York Fed switches from Matlab to Julia,
speed
being one of the reasons, so the gap between gretl and Julia for such
applications must be huge. So I believe that addressing these speed
issues would most probably have some positive side effect on other
applications that are more common in gretl's world.
Of course, it would help if we had an idea what exactly is the
bottleneck in gretl that is responsible for the major part of the gap.
But perhaps Allin and Jack already have an idea what's going on? At
least I remember that Jack was not very surprised when he saw he timings
in Berlin.
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.
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.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------