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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id B0C82BC57 for ; Fri, 19 Nov 2010 20:10:43 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al8CAM5a5kzRVaE0kGdsb2JhbACUX416CBUBAQEBCQkMBxEDH6M0i3oBBY4mAQSFSw X-IronPort-AV: E=Sophos;i="4.59,224,1288566000"; d="scan'208";a="79682637" Received: from mail-fx0-f52.google.com ([209.85.161.52]) by mail4-smtp-sop.national.inria.fr with ESMTP; 19 Nov 2010 20:10:35 +0100 Received: by fxm15 with SMTP id 15so2983150fxm.39 for ; Fri, 19 Nov 2010 11:10:35 -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=OF7EL6jKIQRbc4Stlbjad/bWuceuS0F0kynbPwXOFQw=; b=GiU/6cUI7bI5iqV50Sepx2+OGaUrEr/CPV5I0j0Rt1/lZUPLBU+1MQrQUZazcvvoom 40ydI9auSYgsVBA09n4iP6P8sBv3EYIqUnGN+DHZ/pPIuzd+WqJh+z83lm1gjuu/m35m WU7OH/OrusT4wXrvXopaLJVPlL8JxEFizfaxc= 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=sR+n5dJpbWFfSFpSDSy20Db+8au6pRwybPYmkCGyi17NaeRLEMuCi1Ka4ogNUpHgMS kas65Q6qy+GhjK1m5ugLmYtWDlQeXcT9P5qmA7FR6MevexHJgR2kzGEcYpAKwTIABBex 6JaD/Dfdi9U7grK2GGatNzoGpSHvTcZaogGg8= Received: by 10.223.122.146 with SMTP id l18mr1282425far.102.1290193835185; Fri, 19 Nov 2010 11:10:35 -0800 (PST) Received: from bespin.kosmos.all (ip-95-223-170-32.unitymediagroup.de [95.223.170.32]) by mx.google.com with ESMTPS id y13sm638187fah.2.2010.11.19.11.10.33 (version=SSLv3 cipher=RC4-MD5); Fri, 19 Nov 2010 11:10:34 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) Subject: Re: [Caml-list] OCamlJit 2.0 From: Benedikt Meurer In-Reply-To: Date: Fri, 19 Nov 2010 20:10:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <87247923-BF98-49A2-9334-2A4081DD07FD@googlemail.com> References: To: caml-list@yquem.inria.fr X-Mailer: Apple Mail (2.1081) X-Spam: no; 0.00; byte-code:01 prototyping:01 ocaml:01 ocaml:01 ocamlc:01 ocamlopt:01 bytecode:01 trivial:01 statically:01 compiler:01 pfff:01 wikipedia:01 computations:01 speedups:01 runtime:01 On Nov 19, 2010, at 19:43 , Yoann Padioleau wrote: >> OCamlJit 2.0 was specifically designed for desktop processors and is = not really portable to anything else in its current shape, because the = target audience are people using the interactive top-level and the = byte-code interpreter for rapid prototyping/development >=20 > The target audience seems quite small to me. I think this project is = very interesting from an educational point of view (to understand more > the internals of OCaml) but I doubt we really need a JIT for OCaml. = ocamlc + ocamlopt are very hard to beat. >=20 > What would be really nice is to make a JIT for a language that really = need one, like PHP! There are lots of companies out there (Yahoo, = Facebook, > wikimedia) that spend hundreds of millions of dollars on machines that = run PHP bytecode interpreters implemented by people who are not Xavier = Leroy. > It's not trivial to statically determine types in PHP which prevent to = write really efficient compilers for PHP. JIT are perfect in such = situation. > I started to develop some basic compiler infrastructure around PHP at = https://github.com/facebook/pfff if you are interested. > Improving the current PHP implementation by 5% can save millions of = dollars to Wikimedia. Think about it next time you see > Jimmy Wales asking for money to fund Wikipedia; there are many ways = computer scientists can help him. Well, it is a research project, and it was driven by actual demand. A = JIT engine for PHP is something less interesting from a university point = of view, unless there are companies willing to sponsor/help the = development. But from my personal experience, there is not really a lot to gain = w.r.t. PHP. Delivering website content does not involve complex = computations or processing, it is mostly I/O bound, depending on a fast = database engine, a fast webserver, decent text processing throughput, = etc. I may be wrong here, but I doubt that you'd see relevant speedups = on large websites by simply JITting the PHP code. Also PHP code is less likely to change at runtime, so there's no real = need to acutally JIT compile it. You could use a lot simpler techniques = here to improve performance. For example, just write a simple PHP to C = compiler, compiling your PHP code to native code via C, and let the = webserver run the native code instead. With some clever compilation = scheme, this should outperform any JIT engine, with a lot less effort. Anyway, this seems to be off-topic here... Benedikt=