From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id A20D9BC57 for ; Tue, 30 Nov 2010 11:55:41 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlYBAA9n9EzRVdY0k2dsb2JhbACVAI4DCBUBAQEBCQkKCREDH6dzi3wBBY5AAQSCE4M0 X-IronPort-AV: E=Sophos;i="4.59,279,1288566000"; d="scan'208";a="90393565" Received: from mail-bw0-f52.google.com ([209.85.214.52]) by mail1-smtp-roc.national.inria.fr with ESMTP; 30 Nov 2010 11:55:41 +0100 Received: by bwz4 with SMTP id 4so4770852bwz.39 for ; Tue, 30 Nov 2010 02:55:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:content-type:mime-version :subject:from:in-reply-to:date:content-transfer-encoding:message-id :references:to:x-mailer; bh=CCtdIEwcfI5tcSXm5YJQnwH6Xceh+AiOrPmGby5BkdI=; b=XmahNhcSgOwZiNv0VJpgta9hjXO2d95VnI1QTJ8d5kcLD1eRHReUj4KX1gEsPxbjC1 wWWpfkewJ5xMX88kwDomoy7pvgdKmxt0CFQro/SJF8zifnXb73k+64tE3rnGRByCOuFj QQeJdWImlXtKkKVTR9skdURVNCWESkhRsG1Pw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=c3v/ZgVfePCBLpQRO30nX84GcioMmLLYMVkHApHNmzbOGjUJhB31kFLSMbDtBywpq5 T3jgvIYxks4xKskFbPnI1so2cCprAJlWklk9CxvdHHrMGsikS0+2Qfb3J9/DqELW9kz2 MlH5Vl7hhzFHi8ARFB0f48oslwBESTPMCkSIk= Received: by 10.204.76.137 with SMTP id c9mr3390239bkk.182.1291114541106; Tue, 30 Nov 2010 02:55:41 -0800 (PST) Received: from bespin.informatik.uni-siegen.de (bespin.informatik.uni-siegen.de [141.99.131.92]) by mx.google.com with ESMTPS id t10sm2601543bkj.16.2010.11.30.02.55.39 (version=SSLv3 cipher=RC4-MD5); Tue, 30 Nov 2010 02:55:40 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1081) Subject: Re: [Caml-list] OCamlJIT2 vs. OCamlJIT From: Benedikt Meurer In-Reply-To: <20101130124803.7952fca1@deb0> Date: Tue, 30 Nov 2010 11:55:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3DCEA910-1382-47E5-876B-059178F8F82E@googlemail.com> <20101130124803.7952fca1@deb0> To: caml-list@yquem.inria.fr X-Mailer: Apple Mail (2.1081) X-Spam: no; 0.00; ocamlopt:01 ocamlopt:01 byte-code:01 stack-based:01 translating:01 byte-code:01 compilation:01 compilation:01 ulambda:01 edwin:98 2.0:98 wrote:01 compile:01 caml-list:01 unsafe:01 On Nov 30, 2010, at 11:48 , T=F6r=F6k Edwin wrote: >> In short: Performance measured on a P4 "Northwood" (no long mode, >> plain x86) 2.4GHz. OCamlJIT2 beats OCamlJIT by a factor of 1.1 to 2.0 >> in every benchmark, and - rather surprising - was even able to beat >> ocamlopt in the number crunching benchmark (probably an issue with >> the x86 backend of ocamlopt). >=20 > Looks like this happens only on Pentium4: on Core2 and Xeon ocamlopt > is still faster on almabench.unsafe, or did I miss something? Core 2 and Xeon are x86-64, P4 is x86, so completely different = architecture (with different code generator backends). >>=20 >> As mentioned by Xavier Leroy and others previously, we probably went >> as far as we could go in the direction of JITting the byte-code >> virtual machine, while preserving its general stack-based nature and >> instruction set. Moving even further means translating the byte-code >> to some intermediate form suitable for use with standard compilation >> techniques; but as we saw earlier, in an LLVM-based prototype, the >> compilation overhead increases dramatically and the benefit of JIT >> compilation vanishes. >=20 > An LLVM-based backend would still be interesting for static > compilation, where compile times don't matter much. > Did you try comparing an LLVM-based backend with ocamlopt? > If it is faster could some of the LLVM passes be ported to ocamlopt's > backend? LLVM backend for ocamlopt is a totally different story. You'd have to = start with the Ulambda or the Cmm intermediate representation, while a = JIT approach starts with the byte-code representation (not necessarily, = but that was the case for our approach). However, I'm not sure there would be any immediate benefit from using = LLVM as code generator backend for ocamlopt, since ocamlopt already does = a quite good (and fast) job. So besides probably educational or research = interests, what would be the practical benefit of LLVM inside ocamlopt? > Best regards, > --Edwin regards, Benedikt=