From: Basile Starynkevitch <basile@starynkevitch.net>
To: jit@gcc.gnu.org
Subject: Re: JIT compilation speed
Date: Thu, 01 Jan 2015 00:00:00 -0000 [thread overview]
Message-ID: <55B6AEAE.9030806@starynkevitch.net> (raw)
In-Reply-To: <1438028999.15571.92.camel@surprise>
On 07/27/2015 22:29, David Malcolm wrote:
> On Sat, 2015-07-25 at 11:28 +0100, Dibyendu Majumdar wrote:
>> Hi
>>
>> Is there a timeframe for the performance improvements to the JIT
>> compilation speed?
> The patch kit I posted here:
> https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00116.html
> gives about a 5x speedup (from about 50ms down to about 10ms on my box),
Of course, I'll be happy if that patch was eventually incorporated in
GCC. I guess that the speedup would be that big only for JIT-ing of
*small* gcc_jit_context-s with few (e.g. only hundreds) of
gcc_jit_object-s and using -O0 or -O1. I guess that for JIT-ing or
larger contexts with -O2, the time for generating assembler code won't
dominate (since it does not dominate in GCC itself), so the effect of
the above patch would be much smaller...
However, I don't think that GCCJIT compilation time (I mean the time
needed for GCCJIT to emit machine code from GCCJIT objects) should
matter that much.
The point is that, by design, GCCJIT is GCC based. And GCC is known to
compile quite slowly but to produce fast machine code. So GCCJIT also
will continue to compile a bit slowly but can be configured -by passing
-O2 using GCC_JIT_INT_OPTION_OPTIMIZATION_LEVEL, to produce fast machine
code.
In that respect, GCCJIT is a bit like LLVM (the library). It won't be
able to produce quickly some machine code, but it will be able to
produce, rather slowly, efficient machine code.
If the generation time matters much more than the performance of the
generated JIT-ed machine code, GCCJIT is not the right tool (and
probably would never be, in particular because -O0 is giving code which
is worse than what many other JIT-ing libraries do, and the GCCJIT
infrastructure won't compete with them).
There are several JIT libraries. On one hand, you have libraries like
GNU lightning and GNU libjit and asmjit. they all are able to emit
*quickly* some machine code (whose runtime performance is poor, but
which can be quickly generated). On the other hand, you have
compiler-related libraries like LLVM & GCCJIT. they can emit quite
performant machine code, at the cost of some quite slow JIT generation.
Ultimately I would rather hope that eventually GCCJIT would be able to
even do, with some even more flags à la GCC_JIT_STRING_OPTION*,
link-time-optimization by doing the equivalent of what GCC is doing
today with -flto -O3. I cannot help on that (because LTO internals are
unfamiliar to me) and for my interests in GCCJIT today this is not a big
priority.
So, for Dibyendu Majumdar: if the GCCJIT compilation time matters a lot
to you in RAVI and the performance of the emitted machine code matters
much less to you, I am afraid that GCCJIT is not the optimal library for
your needs in RAVI (using GNU lightning or asmjit would make JIT-ing
time much faster, at the expense of a produced machine code which runs 2
to 5 times slower than what GCCJIT can achieve with -O1).
If several JIT libraries (GCCJIT, LLVM, libjit, asmjit, GNU lightning)
are co-existing, it is because they have different position in the JIT
spectrum. On one side (GNU lightning, asmjit, libjit, ...) you have
libraries able to emit very quickly some slow machine code. On the other
side (LLVM, GCCJIT) you have compiler-based libraries which are emitting
slowly some quickly running machine code. Different needs have different
libraries! But we cannot realistically hope for a JIT library (or a C
compiler) which emits quickly some fast running machine code. There is
no such thing as a free lunch.
I praise David Malcolm for his good work on GCCJIT, which provides a
GCC-based JIT-ing library able to emit (a bit slowly, since based upon
GCC) some quickly running code, thanks to and leveraging above all the
optimizing infrastructure of GCC. See also this (mine) explanation
http://programmers.stackexchange.com/a/273711/40065 about why there are
so few C compilers!
GCCJIT has also (eventually) a very good side: it enables people
experimenting new language design to profit of GCC infrastructure
without having to generate C code.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
next prev parent reply other threads:[~2015-07-27 22:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-01 0:00 Dibyendu Majumdar
2015-01-01 0:00 ` David Malcolm
2015-01-01 0:00 ` Basile Starynkevitch [this message]
2015-01-01 0:00 ` Dibyendu Majumdar
2015-01-01 0:00 ` David Malcolm
2015-01-01 0:00 ` Dibyendu Majumdar
2015-01-01 0:00 ` Basile Starynkevitch
2015-01-01 0:00 ` David Malcolm
2015-01-01 0:00 ` David Malcolm
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55B6AEAE.9030806@starynkevitch.net \
--to=basile@starynkevitch.net \
--cc=jit@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).