Hi,

Apparently I've never announced this here, so here we go.

I have written, and started maintaining D bindings for the GCCJIT library, available on github at this location:

https://github.com/ibuclaw/gccjitd


What is GCCJIT?
---
GCCJIT is a new front-end for gcc that aims to provide an embeddable shared library with an API for adding compilation to existing programs using GCC as the backend.

This shared library can then be dynamically-linked into bytecode interpreters and other such programs that want to generate machine code "on the fly" at run-time.

The library is of alpha quality and the API is subject to change.  It is however in development for the next GCC release (5.0).


How can I use it?
---
See the following link for a hello world program.

https://github.com/ibuclaw/gccjitd/blob/master/tests/dapi.d

I am currently in the process of Ddoc-ifying the documentation that comes with the C API binding and moving that across to the D API.  Improvements shall come over the next months - though any assistance in making the Ddocs prettier are welcome contributions.


Regards
Iain.

For a more practical example, I've added an example jit compiled brainf*** interpreter.

https://github.com/ibuclaw/gccjitd/blob/master/tests/brainf.d

Also will be adding instructions on how to build the libgccjit frontend later this week - if you haven't already worked it out from the gccjit homepage.

Iain.

Iain Buclaw:

> For a more practical example, I've added an example jit compiled brainf*** interpreter.
>
> https://github.com/ibuclaw/gccjitd/blob/master/tests/brainf.d

Here I have put a little program you can use as performance benchmark:
http://codepad.org/hogVnlIS

Bye,
bearophile

On Saturday, 27 December 2014 at 10:47:55 UTC, bearophile wrote:
> Iain Buclaw:
>
>> For a more practical example, I've added an example jit compiled brainf*** interpreter.
>>
>> https://github.com/ibuclaw/gccjitd/blob/master/tests/brainf.d
>
> Here I have put a little program you can use as performance benchmark:
> http://codepad.org/hogVnlIS
>
> Bye,
> bearophile

Sure, what is that supposed to do?

Iain.

Iain Buclaw:

> Sure, what is that supposed to do?
>
> Iain.

To print a classic image of the Mandelbrot Set (but Codepad seems down currently).

Bye,
bearophile

On 28 December 2014 at 10:24, bearophile via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
> Iain Buclaw:
>
>> Sure, what is that supposed to do?
>>
>> Iain.
>
>
> To print a classic image of the Mandelbrot Set (but Codepad seems down
> currently).
>
> Bye,
> bearophile

Thanks - turns out that I had to increase the stack size to make it work.

As I'd know you'd want to hear it, these are benchmarks done on my machine - if you had any specific BFI in mind bearophile, let me know.

  1.086s: bfgccjitd-runtime-O2
  1.139s: bfgccjitd-runtime-O1
  2.759s: bfgccjitd-O1
  3.646s: bfgccjitd-O2
  4.959s: bff-O2
  5.065s: bff4-O2
  6.104s: bff4-O1
  6.145s: bfsree-O2
  6.200s: bff
  7.361s: bff-O1
  8.185s: bfsree-O1
11.071s: bff4
13.107s: bfsree
16.945s: bfgccjitd-runtime
17.599s: bfgccjitd

There are two readings for the gccjitd timings, one taking into account the entire compilation time (parse, compile, link, load, run), the other (-runtime) just the execution time of the compiled function once loaded.  For instance, you can observe that running mandelbrot.b with -O2 is faster, but you end up loosing time overall on account that it takes gcc 1 second longer to compile with such high optimisations.


bff, bff4 and bfsree can be found at the following locations respectively.

https://github.com/apankrat/bff
http://mazonka.com/brainf
www.kotay.com/sree/bf

Regards,
Iain.

Iain Buclaw:

>   1.086s: bfgccjitd-runtime-O2
>   1.139s: bfgccjitd-runtime-O1
>   2.759s: bfgccjitd-O1
>   3.646s: bfgccjitd-O2
>   4.959s: bff-O2

Five times faster than bff is a lot :-)

My best timings are usually around two times faster than bff. I guess gccjit is not an average JIT-tter.

Bye,
bearophile

On 28 Dec 2014 21:25, "bearophile via Digitalmars-d-announce" < digitalmars-d-announce@puremagic.com> wrote:
>
> Iain Buclaw:
>
>
>>   1.086s: bfgccjitd-runtime-O2
>>   1.139s: bfgccjitd-runtime-O1
>>   2.759s: bfgccjitd-O1
>>   3.646s: bfgccjitd-O2
>>   4.959s: bff-O2
>
>
> Five times faster than bff is a lot :-)
>
> My best timings are usually around two times faster than bff. I guess
gccjit is not an average JIT-tter.
>
> Bye,
> bearophile

You could say that again.  I found a nice ASCII diagram that shows the workflow between client and gcc to generate the object.

https://dmalcolm.fedorapeople.org/gcc/libgccjit-api-docs/internals/index.html#overview-of-code-structure

Iain.

On Saturday, 27 December 2014 at 09:53:42 UTC, Iain Buclaw wrote:
> For a more practical example, I've added an example jit compiled brainf*** interpreter.
>
> https://github.com/ibuclaw/gccjitd/blob/master/tests/brainf.d
>

Another practical example has been published which implements a made up toy language using the gccjitd library as a backend.

Using a vistor class to split backend and frontend was shamelessly borrowed from DMD.  :)

https://github.com/ibuclaw/gccjitd/tree/master/tests/toy

This I plan to be the last example that will be pushed in.

Regards
Iain.