[Gambas-user] Replacing the JIT component

[PICCORO McKAY Lenz]

umm in that case, the hole solution wil be carried their own llvm inside
gambas and mantained by own...

but actually the llvm code are very complicated and very api breack !

but i think its best to mantain won code event depends on a project so
unstable in api realted

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

2018-05-13 12:55 GMT-04:00 Adrien Prokopowicz <adrien.prokopowicz at gmail.com>
:

> Le 06/05/2018 à 21:43, Benoît Minisini a écrit :
>
>> Hi,
>>
>> This is just an idea in the fly. There is nothing concrete at the moment.
>>
>> As you may know, there is a JIT component in Gambas (not made by me)
>> based on LLVM. Alas it does not work with recent versions of LLVM, because
>> apparently this huge project is not able to keep backward compatibility
>> between minor versions. (Worse than GTK+, I couldn't imagine it was
>> possible!)
>>
>> What to do now?
>>
>> 1) Rewriting the JIT compiler for newer versions of LLVM. Alas the
>> original author does not give any news, and I have no knowledge about LLVM,
>> and its C++ interface looks horrible to me.
>>
>> 2) gcc has now a JIT library, but it is an alpha version with a big
>> warning that everything may change between releases, even if it is
>> apparently relatively stable. Moreover, no idea about how many bugs the
>> library has.
>>
>> 3) Writing a Gambas -> C translator.
>>
>> My idea is that the compiler, or maybe an external program eventually
>> written in Gambas, takes a class/module source code, and transform it into
>> a C source file.
>>
>> That C source file will call the interpreter functions when needed
>> through a dedicated interpreter API.
>>
>> Then the C source file will be transform into a shared library loaded at
>> runtime by the interpreter (calling the C compiler that hence must be
>> installed).
>>
>> The advantages are:
>>
>> - C syntax is thousand times more stable than a JIT compiler library that
>> changes at each version.
>>
>> - Maybe better optimizations.
>>
>> The disadvantages are:
>>
>> - You need the compiler. But the JIT library needs most of it too, so...
>>
>> - Compiling is slower than calling a JIT library.
>>
>> - JIT library can compile at the function level. This is not practical
>> with a compiler (we won't make a shared library for each JIT function!).
>> One shared library for each class, or even one for the entire project may
>> be the solution.
>>
>> Now I'm waiting for your comments!
>>
>> Regards,
>>
>>
> I don't think the option #3 is a good way to go (not that the others are
> better …).
>
> First, going that route will require a *lot* of work, both on short- and
> long-term.
> You will first have to write a full Gambas-to-C transpiler, which involves
> either plugging into gbc (unless you read the compiled output), or
> maintaining the full grammar on two different compilers.
> Then it requires adding and maintaining extra hooks in the interpreter for
> the generated binary to link onto, which I don't know much about, but is
> probably not trivial either.
>
> Having to perform a full compilation at startup also completely nullifies
> the advantages of Just-In-Time compilation: standard compilation (e.g. GCC
> or LLVM executable invocation) is not just slower, it is orders of
> magnitude slower, which even for small bits could just add a few seconds of
> startup time to any app that uses it. And considering 99.9% of Gambas code
> speed isn't really affected by any kind of compilation to native code (I
> think the only ones that are enhances are long, tight loops that do number
> crunching, but most if not all apps are just a bunch of calls to component
> APIs or similar), the tradeoff becomes not worth it at all in most cases. :/
>
> Considering all of this, the first solution that comes to my mind could be
> to simply drop the gb.jit component : it wouldn't be too big of a breaking
> change I think, considering the interpreter already falls back to normal
> operation if it can't find the gb.jit component to perform the compilation.
> And it seems it already doesn't work for most users, so dropping something
> that doesn't work anyway probably isn't a huge deal …
>
>
> The alternative option (which is much simpler than the first three), would
> be to statically link against a specific version of LLVM (the one that
> works for us, we could use git submodules to do this), bundling only the
> parts of the compiler we need with the gb.jit component. Then it works for
> everybody out of the box, and we can update it only when we want,
> incrementally (and drop all those ugly #ifdef checks).
>
> Now that I think about it, LLVM is not meant to be used as a dynamic
> library at all (which explains the pain you're going through trying to do
> so, and why they release breaking versions regularly). All the projects I
> know that rely on LLVM (like clang, openjdk, mono, emscripten, rustc …)
> link it statically.
>
> --
> Adrien Prokopowicz
>
>
> --------------------------------------------------
>
> This is the Gambas Mailing List:
> https://lists.gambas-basic.org/listinfo/user
>
> Search the list:
> https://lists.gambas-basic.org/cgi-bin/search.cgi
>
> Hosted by https://www.hostsharing.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/user/attachments/20180513/55f7ece3/attachment-0001.html>