Re: JIT - automated mexing

[Jaroslav Hajek]

On Wed, Jul 28, 2010 at 11:00 PM, Judd Storrs <address@hidden> wrote:
> On Wed, Jul 28, 2010 at 5:25 AM, Jaroslav Hajek <address@hidden> wrote:
>>
>> Don't you feel it's just simpler to use the C++ API?
>
> To be fair, if it was "just simpler" to use the C++ API, then automatic
> translation of m files to C++ API-based code would be simple, too. Right?
>

No, absolutely not. I don't understand this conclusion. What I was
saying is that the markup would actually duplicate a lot of C++ (type
declarations, templates) and share its disadvantages (requires
rewriting code). So it doesn't seem much better than using C++
directly. The "simpler" comes from the fact that using C++ is possible
in today's world.


> I think the idea of markup is interesting, but maybe there are probably
> better ways of achieving useful type information than marking up the entire
> code stack with type contracts. Perhaps by tracing parameter types while
> executing the m-code in a special mode. In any case, because the language
> itself is dynamically typed and does not include type information in
> function declarations, it will always be very easy to invent nasty
> functions. For example a function that changes return types based on the
> output of a random number generator. On the other hand, I think what
> Alexander is suggesting is that something simple may work for many
> real-world cases. It would put the onus on the user to structure their code
> to avoid nasty functions similar to how currently it is the user's
> responsibility to vectorize.

There's a fundamental difference, however. The compiler has no tools
to check or verify the declared non-nastiness and type info, it has to
trust it, use conversions where needed or at best gripe when a
conversion doesn't seem to exist. But still inserting type
declarations may change the meaning of the code, and the compiler
can't verify it (if it can, it can just as well do JIT compiling).

In the end I believe you would end up reinventing Fortran/C/C++
pursuing this path, which I think is lots of work for too little
music.
If you think you can come with something fundamentally simpler, your
contribution would surely be welcome.

> In any case it seems to me that whether the type annotation ultimately comes
> from manually marked-up code/declarations or is automatically generated by
> profiling, the mex translation step should be nearly identical. i.e. if the
> auto-mex works based in input of type-annotated code, octave could very
> likely be modified to output type-annotated code in a profiling mode.
>

It has been said multiple times that inferring the type information is
actually the hard part of JIT compiling. Once you have that,
generating the code via LLVM would be, well, not quite a piece of
cake, but definitely the simpler part.

Tracing the types via profiling is an interesting idea, but useless in
many cases, where I want my computation to run efficiently at the
first attempt, not the second and later ones. Besides, that wouldn't
quite solve the problem of type-generic functions.

regards

-- 
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz