[Gambas-user] Replacing the JIT component

[PICCORO McKAY Lenz]

GHC has a article dedicated to that problem: "The root of all these
problems is *GHC has no control over the LLVM tools it may use*."

An then  implemented a obviously solution:
https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend#Asolution

If more thatn a opensource project has/mantain a LLVM source treee, can
share efforst and produce a good result! it's better rather mantain a new
project "alone" by few manpowers (a gambas to c interpreter/bycompiler?)
and the the most frecuent coders let the team!

We Think about it!

Have the LLVM sources/executables included should ideally be a fork of best
LLVM version that works with gambas code, as other non trivial languages
projects palns to use own LLVM end up patching; is what Haskell GHC and
Swift try do.

All of these due the LLVM dangerous unstable api:
http://smart-cactus.org/~ben/posts/2014-11-28-state-of-llvm-backend.html

Gambas still are linux close, but if we want to use on others platform, we
need to control the sources that rely on: we cannot rely on the system's
version of clang for example: on OS X the default clang is built against
Apple's LLVM, whose source code is unknown as pointed in the GHC threath.

scala native alto has some problems, but alway the reason are the mantain
effors..

so the real solution its to join forces with other teams of open source
projects and then prodduce a llvm "for us"

as i said, we think about it!


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

2018-05-13 14:02 GMT-04:00 Benoît Minisini <g4mba5 at gmail.com>:

> Le 13/05/2018 à 18:55, Adrien Prokopowicz a écrit :
>
>> 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.
>>
>
> I don't say it's simple, but it should not be very difficult to generate C
> code once the source code has been parsed by the reader and the tree
> expression generator.
>
> Moreover, the compiler tree expression generator statically computes the
> datatype of every intermediate expression, which can be used to generate
> static C code accurately.
>
>
>> 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. :/
>>
>
> By using a cache, the compilation will be done once (or if the system CPU
> changes, but it is usually not frequent).
>
> And no, I don't think calling the compiler will be magnitude slow, as the
> source code will only include one header for the interpreter API, and not
> the tons of headers a standard C program includes.
>
> Moreover, even if 99% of your code does not need speed, the other 1% may
> need it badly.
>
>
>> 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.
>>
>>
> Statically linking to LLVM 3.5 does not solve these problems : some Gambas
> instructions are not supported, and new ones cannot be added as I do not
> master the original code at all.
>
> But using C allows to not be dependant on the compiler version, as C is a
> relatively stable standard.
>
> Regards,
>
> --
> Benoît Minisini
>
>
> --------------------------------------------------
>
> 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/20180514/e761c962/attachment-0001.html>