Re: [Gretl-users] Julia Micro-Benchmarks
Am 26.02.2018 um 20:08 schrieb Riccardo (Jack) Lucchetti:
On Mon, 26 Feb 2018, Sven Schreiber wrote:
> I have started work on a proof of concept that would take the
code of
> a number-crunching function written in pure (and maybe somewhat
> simplified) hansl, would translate it to julia automagically and would
> thus use julia as a JITting backend.
This sounds like a lot of fun, but I have the feeling that in order
to
run Hansl code on LLVM going through Julia may not be the best idea
('cause that's what you'd be doing, since Julia runs on top of LLVM). I
suspect that producing a Hansl->Julia translator is going to be VERY
tough, if we want it to work in more than 90% of arbitrary hansl scripts
that you have out there in the wild.
I agree with the latter point, and that's exactly why this is _not_ the
aim. I'm not talking about entire scripts, and not talking about
"arbitrary", either. Instead, the aim would be to:
- write a prototype hansl program for the problem at hand
- identify the bottleneck computation
- rewrite this bottleneck in a simple loop-oriented hansl function
(which would be very inefficient in normal hansl usage, but very simple
to write, and very good input for the compiler)
- have the yet-to-be-written tool translate only this one "loopy" hansl
function to julia and execute it there
- leave all the rest in hansl
I'm not saying this approach would cover 100% of all needs, but I would
bet up to 95%. So far I found the automatic translation of matrix- and
math-oriented code from (simplified) hansl to julia quite doable, with a
lot of help from the regsub() function.
It wouldn't be fully automatic because you would have to come up with an
additional specialized hansl function. But from a user's point of view
you would never leave the gretl+hansl world.
credible guess on how hard that would be to do is Allin. My guess is
that it'd require several months of very-high-skilled work.
["it" being: "writing a frontend ... to produce IM (LLVM's
"machine code")]
Yes, I can easily believe that estimate. That's why I think my
simplistic workaround is a viable alternative, because it's so much less
sophisticated and would require perhaps weeks of moderately-high-skilled
work.
cheers,
sven