From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121497 invoked by alias); 28 Jul 2015 15:19:07 -0000 Mailing-List: contact jit-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Subscribe: Sender: jit-owner@gcc.gnu.org Received: (qmail 121486 invoked by uid 89); 28 Jul 2015 15:19:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.98.7 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mx1.redhat.com Message-ID: <1438096253.15571.142.camel@surprise> Subject: Re: JIT compilation speed From: David Malcolm To: Basile Starynkevitch Cc: Dibyendu Majumdar , jit@gcc.gnu.org Date: Thu, 01 Jan 2015 00:00:00 -0000 In-Reply-To: <55B6B80F.5030506@starynkevitch.net> References: <1438028999.15571.92.camel@surprise> <55B6AEAE.9030806@starynkevitch.net> <55B6B80F.5030506@starynkevitch.net> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-SW-Source: 2015-q3/txt/msg00119.txt.bz2 On Tue, 2015-07-28 at 01:00 +0200, Basile Starynkevitch wrote: > On 07/28/2015 00:52, Dibyendu Majumdar wrote: > > > >> 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). > >> > > Yes understand that - I think that libgccjit needs to be at least as > > efficient as LLVM - that should be good enough. > > > Given that today Clang/LLVM is significantly quicker to compile C code > than GCC is for -O1, that won't happen very soon. GCCJIT is GCC based, > so will continue to keep the heavy weight of GCC. I don't know that -O1 in gcc vs -O1 in llvm is an "apples-to-apples" comparison; different compilers may have a different idea of what optimizations should be enabled at each numbered level. > Some people within GCC are trying to make it work faster (as a C or C++ > compiler). When that would happen (and it might take years) GCCJIT will > also work faster. But don't hope much of that for this 2015 year (and > probably not even for 2016). > > GCCJIT is GCC based, so cannot be faster than GCC is! That said, we could tweak GCC for specific workloads. For example, each -O level expresses a particular combination of passes. libgccjit could potentially build an alternate pass_manager for a particular gcc_jit_context, and build a specifically-tuned tree of passes, eliminating passes that aren't wanted, and perhaps even having custom passes. I'm not sure how to express any of that in the API though. > Between GCCJIT & LLVM, I guess that GCCJIT -when used with -O3- will > produce slightly faster machine code than what LLVM can give, at the > expense of a significantly slower JIT time. > > Look at GCCJIT as something GCC based, without the inconvenience of > having to generate by yourself some C code. BTW, in my MELT experience, > generating C code and compiling and dlopen-ing it, can be fast enough > for some interactive usage. > > Regards. >