Re: [Caml-list] OCamlJit 2.0

From: Yoann Padioleau <padator@wanadoo.fr>
To: Benedikt Meurer <benedikt.meurer@googlemail.com>
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] OCamlJit 2.0
Date: Sat, 20 Nov 2010 07:59:03 -0800	[thread overview]
Message-ID: <4E5CD9AC-C0D7-4BBB-BDCA-5E54353F041C@wanadoo.fr> (raw)
In-Reply-To: <87247923-BF98-49A2-9334-2A4081DD07FD@googlemail.com>

[-- Attachment #1: Type: text/plain, Size: 2045 bytes --]

On Nov 19, 2010, at 11:10 AM, Benedikt Meurer wrote:

> 
> 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,

I think you are. As said by someone previously facebook got a 2x speedup on CPU by optimizing PHP. Websites are not just
getting something from a database and echoing it.

> 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.

I think it may actually be more effort to do an efficient compiler than a JIT on languages like PHP
For instance the team behind the Druby project ( http://www.cs.umd.edu/projects/PL/druby/publications.html )
first tried to do some static type inference on ruby code but then switched to a dynamic approach
because it was too hard to infer statically.

> 
> Anyway, this seems to be off-topic here...

Sure

> 
> Benedikt
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

[-- Attachment #2: Type: text/html, Size: 2740 bytes --]