[Caml-list] OCamlJit 2.0
Benedikt Meurer
OCamlJit 2.0 is a new Just-In-Time engine for Objective Caml 3.12.0 on desktop processors (x86/x86-64). It translates the OCaml byte-code used by the interpreter (ocamlrun and ocaml) to x86/x86-64 native code on-demand and runs the generated native code instead of interpreting the byte-code. It is designed to run with minimal compilation overhead (translating only what is being executed, avoiding costly code generation and optimization techniques), while being 100% compatible with the byte-code runtime (including serialization and hashing of closures, etc.).
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 (which is unlikely to happen on anything else but x86/x86-64). The implementation currently requires a system that adheres to the SysV ABI, which includes Linux, BSD, OS X, but excludes Win32/Win64 (patches/ideas are welcome). It was tested on Linux/x86 (Debian), Linux/amd64 (CentOS) and Mac OS X 10.6 (64bit). The x86 implementation requires SSE2 capable processors (otherwise it falls back to the byte-code interpreter), so it won't speedup your OCaml programs running on 486 CPUs. :-)
OCamlJit 2.0 runs most benchmarks at 2-6 times faster than the byte-code interpreter. The interactive top-level benefits twice when used with the JIT engine: (a) the compiler stages are JIT compiled and (b) the generated byte-code is JIT compiled. A tech report describing a slightly earlier prototype and including performance measures of OCamlJit 2.0 on Mac OS X (64bit) is available at:
http://arxiv.org/abs/1011.1783
The source code is available from the Git repository (master branch) at:
http://gitorious.org/ocamljit2/ocamljit2
Installation is similar to installation of Objective Caml, just run
./configure -prefix /path/to/ocamljit2 [options]
followed by
make world opt
make install
This will install a fully working Objective Caml 3.12.0 to /path/to/ocamlji2, where /path/to/ocamljit2/bin/ocamlrun and /path/to/ocamljit2/lib/libcamlrun_shared.so include the JIT engine in addition to the byte-code interpreter (fallback to the byte-code interpreter is necessary for debugging with ocamldebug). The configure script prints a line indicating whether the JIT engine is enabled or not (if not, it'll be just a regular OCaml 3.12 installation).
Comments are welcome.
Enjoy!
Benedikt Meurer
_______________________________________________
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
bluestorm
here are the answers to the question I had:
1. Is that project related to Basile Starynkevitch's venerable OCamlJIT ?
Yes, OcamlJIT was apparently a major inspiration for this work. The overall
design is similar, and in particular the objective of absolute compatibility
with the existing bytecode (even when it may hurts performances) was
retained. Unfortunately, due to bitrotting and different architectures
(OcamlJIT x86 vs. OcamlJIT2 x86_64), there is no direct performance
comparison, though the reports seems to indicate similar to better
performances. Several points were also improved (better (but still
suboptimal) register usage, clever hacks to speed up mapping between
bytecode and native code adresses...).
2. Does it use LLVM ?
No, it doesn't, but it's justified. Apparently, an early prototype showed
than LLVM compilation/generation overhead was too high. A (debatable) design
goal of OcamlJIT2.0 is to be absolutely faster than ocamlrun, even on *very*
short-running programs (`ocamlc -help`). Here is a direct quote from the
report :
> In a simple OCamlJit2 prototype based on LLVM, we have measured significant
compilation overhead; short running programs (like ocamlc applied to a small
> to medium
sized *.ml file) were three to four times slower than running the same
> program with the
byte-code interpreter. Similar results were observed by other projects using
> LLVM for
Just-In-Time compilation. For example, the Mono project10 reported
> impressive speedups
for long running, computationally intensive applications, but at the cost of
> increased com-
pilation time and memory usage.
OCamlJIT2.0 uses its own macro to generate x86_64 assembly directly
(apparently using a dedicated library wasn't worth it). A drawback of this
strategy is its inherent non-portability.
3. Does it perform well ?
As explained in the original post, the speedups against bytecode are around
2-6x. It's quite honourable, and the results are very consistent: all
benchmarked programs running for more than 1 second have speedups between
2.59 and 5.34.
The authors seems to think other optimizations are possible, and expect
significant performance improvements in the future. The goal of being "on
par with the ocaml native compiler" is (prudently) mentioned. On the
benchmark, ocamlopt was itself 2 to 6 times faster than OcamlJIT2.0.
4. Various remarks:
Various clever hacks are described in the report, which bring noticeable
performance improvements but probably make the implementation more complex.
I was also interested by the following remark --- maybe a bit provocative:
Both JVM and CLR depend on profile guided optimizations for good
> performance,
because their byte-code is slower than the OCaml byte-code. This is mostly
> because of
the additional overhead that comes with exception handling, multi-threading,
> class loading
and object synchronization. But it is also due to the fact that both the JVM
> byte-code [27]
and the Common Intermediate Language (CIL) [10] instruction sets are not as
> optimized
as the OCaml byte-code.
Benedikt Meurer
On Nov 16, 2010, at 18:07 , bluestorm wrote:
> To those of you who are lazy but still curious, I just read the report, and here are the answers to the question I had:
Thanks for posting these points, should have done this in my original post...
> 1. Is that project related to Basile Starynkevitch's venerable OCamlJIT ?
>
> Yes, OcamlJIT was apparently a major inspiration for this work. The overall design is similar, and in particular the objective of absolute compatibility with the existing bytecode (even when it may hurts performances) was retained. Unfortunately, due to bitrotting and different architectures (OcamlJIT x86 vs. OcamlJIT2 x86_64), there is no direct performance comparison, though the reports seems to indicate similar to better performances. Several points were also improved (better (but still suboptimal) register usage, clever hacks to speed up mapping between bytecode and native code adresses...).
With the x86 port being close to complete, direct comparison with OcamlJIT will be possible (dunno if OcamlJIT will work with 3.12 tho). I'll do appropriate comparisons once everything is in place.
> 2. Does it use LLVM ?
>
> No, it doesn't, but it's justified. Apparently, an early prototype showed than LLVM compilation/generation overhead was too high. A (debatable) design goal of OcamlJIT2.0 is to be absolutely faster than ocamlrun, even on *very* short-running programs (`ocamlc -help`).
This is indeed debatable, atleast for "ocamlc -help". But this was not the main concern with LLVM. LLVM overhead is acceptable for long running computations, but everything else is slowed down noticably. It should also be noted that my LLVM prototype was rather quick&dirty, so it may indeed be possible to get a LLVM based JIT which is on par with the byte-code interpreter for common applications. But why would one want to do this? Long running computations can be speed up very well using ocamlopt (no need to perform them using the interactive top-level).
> OCamlJIT2.0 uses its own macro to generate x86_64 assembly directly (apparently using a dedicated library wasn't worth it). A drawback of this strategy is its inherent non-portability.
It used AsmJit before, which is also limited to x86/x86-64; the non-portability is actually a design decision (as explained in my original post, portability to non-desktop machines was not a goal for the current implementation).
HTH,
Alain Frisch
> 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
This looks like a very interesting project!
Does performance really matter that much for rapid
prototyping/development? I can imagine other uses of the toplevel where
performance matters more, like theorem provers embedded in the OCaml
toplevel.
Anyway, another option to get a more efficient interactive top-level is
to turn to native code.
There is actually already a native top-level in the distribution, even
though it is undocumented and unmaintained. You can build it with the
"make ocamlnat" target. The implementation is based on the same
approach as native dynlink. The toplevel embeds the native compiler;
for each phrase, the toplevel produces assembly code, calls the
assembler and the linker to produce a dynamic/shared library, and then
dynamically load and execute the resulting code. This gives some
latency, but it's not so bad in practice, and you get the full speed of
native code.
A further step to improve this native toplevel is to avoid the call to
the external assembler and linker. To do that, one basically needs to
replace the assembly code emitters (emit.mlp/emit_nt.mlp) with native
code emitters and do the relocation/dynamic loading by hand, which is
quite easy.
As it turns out, LexiFi uses on a daily basis such direct binary code
emitters for x86/amd64 on Windows, and that would be easy to port to
other x86/amd64 platforms. The x86 version was developed internally,
and the amd64 version was done by Fabrice Le Fessant. There is also
some code to wrap the binary code into COFF objects (and flexdll has a
stand-alone mode to produce .cmxs files without an external linker), but
that would be useless for a native toplevel. The goal was to have a
compiler which can be more easily embedded in our applications and
deployed to our customers, without depending on any external tool.
If you Benedikt, or someone else, is willing to work on a native
top-level without the need to call an external assembler/linker, we are
ready to extract the binary code emitters from our code base and share
them with the community (with an open-source license to be determined).
This requires some packaging work on our side, so we're going to do it
only if there is interest in the project.
(Another nice side project, for having a good native toplevel, would be
to extend ocamlopt with some control over the trade-off between speed of
code generation, and the performance of the generated code. One way to
do it is to force the interference graph to remain not too big, by
spilling early, in order to avoid quadratic behavior in the register
allocator.)
-- Alain
Satoshi Ogasawara
Hash: SHA1
On 2010/11/17, at 17:44, Alain Frisch wrote:
> Does performance really matter that much for rapid prototyping/development? I can imagine other uses of the toplevel where performance matters more, like theorem provers embedded in the OCaml toplevel.
ocamltter( https://github.com/yoshihiro503/ocamltter ) is a twitter client in the toplevel.
I believe the toplevel is useful user interface to make a tiny application.
- --
ogasawara
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (Darwin)
iEYEARECAAYFAkzjsmoACgkQzTChtNfYLwb1JACgl0kC9y6e1q7fyH4r+GOZYLvu
V6kAoMHIPg2KPuUazqsVctc5l0ad3iGZ
=LZno
-----END PGP SIGNATURE-----
Sylvain Le Gall
> On 11/16/2010 03:52 PM, Benedikt Meurer 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
>
> This looks like a very interesting project!
>
> Does performance really matter that much for rapid
> prototyping/development? I can imagine other uses of the toplevel where
> performance matters more, like theorem provers embedded in the OCaml
> toplevel.
>
OASIS generates a setup.ml that is interpreted using the toplevel.
Maybe, a native toplevel can enhance the speed of this process (it takes
less than 1 second to run).
http://oasis.forge.ocamlcore.org
Regards,
Sylvain Le Gall
Wojciech Daniel Meyer
> On 11/16/2010 03:52 PM, Benedikt Meurer wrote:
> A further step to improve this native toplevel is to avoid the call to
> the external assembler and linker. To do that, one basically needs to
> replace the assembly code emitters (emit.mlp/emit_nt.mlp) with native
> code emitters and do the relocation/dynamic loading by hand, which is
> quite easy.
Maybe this could possibly help with the emission part (at least for X86)
(regarding OCamlJIT as well):
https://github.com/danmey/ocaml-inline-x86/
The project is `not yet there', however I am currently putting some
effort to make it more usable. If anybody is interested please shout.
> -- Alain
Wojciech
Ashish Agarwal
> Does performance really matter that much for rapid prototyping/development?
Rapid prototyping for me often involves a couple of lines of code that read
in a very large file and do something with it. I have to keep compiling
these small programs to native code because the performance of the toplevel
is too slow. Then, I have to recompile and re-read the whole file for every
little additional thing I want to compute. A high-performance toplevel would
help in this kind of work.
Benedikt Meurer
On Nov 17, 2010, at 09:44 , Alain Frisch wrote:
> There is actually already a native top-level in the distribution, even though it is undocumented and unmaintained. You can build it with the "make ocamlnat" target. The implementation is based on the same approach as native dynlink. The toplevel embeds the native compiler; for each phrase, the toplevel produces assembly code, calls the assembler and the linker to produce a dynamic/shared library, and then dynamically load and execute the resulting code. This gives some latency, but it's not so bad in practice, and you get the full speed of native code.
>
> A further step to improve this native toplevel is to avoid the call to the external assembler and linker. To do that, one basically needs to replace the assembly code emitters (emit.mlp/emit_nt.mlp) with native code emitters and do the relocation/dynamic loading by hand, which is quite easy.
>
> As it turns out, LexiFi uses on a daily basis such direct binary code emitters for x86/amd64 on Windows, and that would be easy to port to other x86/amd64 platforms. The x86 version was developed internally, and the amd64 version was done by Fabrice Le Fessant. There is also some code to wrap the binary code into COFF objects (and flexdll has a stand-alone mode to produce .cmxs files without an external linker), but that would be useless for a native toplevel. The goal was to have a compiler which can be more easily embedded in our applications and deployed to our customers, without depending on any external tool.
>
> If you Benedikt, or someone else, is willing to work on a native top-level without the need to call an external assembler/linker, we are ready to extract the binary code emitters from our code base and share them with the community (with an open-source license to be determined). This requires some packaging work on our side, so we're going to do it only if there is interest in the project.
This is indeed very interesting. I haven't thought of the native top-level. I haven't done any measurements yet, but from my experience with ocamlopt, I know that the optimizing native compiler is somewhat slower than the byte-code compiler. I doubt that this is related solely to the external as/ld invocations, so there's certainly more work to do than just replacing the calls to as/ld with an in-process assembler/linker.
> -- Alain
Benedikt
Fabrice Le Fessant
> This is indeed very interesting. I haven't thought of the native top-level. I haven't done any measurements yet, but from my experience with ocamlopt, I know that the optimizing native compiler is somewhat slower than the byte-code compiler. I doubt that this is related solely to the external as/ld invocations, so there's certainly more work to do than just replacing the calls to as/ld with an in-process assembler/linker.
Indeed, there are some more passes in ocamlopt than in ocamlc, but I
think that most of the time is spent in allocating registers and
generating the assembler file and calling the assembler. As Alain said,
we already have the inline assembler, so the next step would be to
improve register allocation, either by spilling more variables to avoid
the quadratic behavior of graph coloring, either by using some linear
scan algorithm (for example, the one of HotSpot).
--Fabrice
Hezekiah M. Carty
> Hello,
>
> 2010/11/18 Ashish Agarwal <agarw...@gmail.com>:
>> Rapid prototyping for me often involves a couple of lines of code that read
>> in a very large file and do something with it. I have to keep compiling
>> these small programs to native code because the performance of the toplevel
>> is too slow. Then, I have to recompile and re-read the whole file for every
>> little additional thing I want to compute. A high-performance toplevel would
>> help in this kind of work.
>
>
ocamlscript is certainly a wonderful tool, for prototyping and
otherwise. It unfortunately doesn't help specifically with the "load
a large file and do something with it" case. A native-code toplevel
allows you to keep the native code speed benefits and load the file
only once. Interactive experimentation on the file's data then
doesn't require waiting for the data to be read in each time.
Hez
Ashish Agarwal
>
> ocamlscript is certainly a wonderful tool, for prototyping and
> otherwise. It unfortunately doesn't help specifically with the "load
> a large file and do something with it" case.
Right.
Also, I should mention that a high-performance toplevel, combined with new
libraries like OCaml-R, would essentially make OCaml a competitor to Matlab
and R. This would really expand OCaml's scope to an important area.
Benedikt Meurer
This was actually the main motivation for OCamlJit, tho we did not specifically need a competitor to Matlab (we use tuareg mode most of the time, to prototype term rewriting/typing stuff, but also for some complex LaTeX generation tasks). After thinking about it for a few days now, I think a native toplevel would indeed solve the problem, in a better way than a byte-code JITter. I'll try to look into the remaining issues with the native toplevel, but I have some other stuff to finish first.
Benedikt
Yoann Padioleau
On Nov 16, 2010, at 6:52 AM, Benedikt Meurer wrote:
>
> Hello everybody,
Hi,
>
> OCamlJit 2.0 is a new Just-In-Time engine for Objective Caml 3.12.0 on desktop processors (x86/x86-64). It translates the OCaml byte-code used by the interpreter (ocamlrun and ocaml) to x86/x86-64 native code on-demand and runs the generated native code instead of interpreting the byte-code. It is designed to run with minimal compilation overhead (translating only what is being executed, avoiding costly code generation and optimization techniques), while being 100% compatible with the byte-code runtime (including serialization and hashing of closures, etc.).
>
> 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
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.
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.
Benedikt Meurer
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
>
> 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.
>
> 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
Benedikt Meurer
On Nov 19, 2010, at 11:02 , Fabrice Le Fessant wrote:
> Benedikt Meurer wrote, On 11/19/2010 06:29 AM:
>> This is indeed very interesting. I haven't thought of the native top-level. I haven't done any measurements yet, but from my experience with ocamlopt, I know that the optimizing native compiler is somewhat slower than the byte-code compiler. I doubt that this is related solely to the external as/ld invocations, so there's certainly more work to do than just replacing the calls to as/ld with an in-process assembler/linker.
>
> Indeed, there are some more passes in ocamlopt than in ocamlc, but I
> think that most of the time is spent in allocating registers and
> generating the assembler file and calling the assembler. As Alain said,
> we already have the inline assembler, so the next step would be to
> improve register allocation, either by spilling more variables to avoid
> the quadratic behavior of graph coloring, either by using some linear
> scan algorithm (for example, the one of HotSpot).
Using the linear scan algorithm with ocamlopt might be a good idea, due to the structure of the generated code, linear scan should give results close to that of the graph coloring algorithm for the generated native code. I'll see if I can hire some students to evaluate an implementation of linear scan for ocamlopt.
> --Fabrice
Benedikt
Dario Teixeira
> 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.
Actually, Facebook has a compiler that transforms PHP source code into C++ [1],
and they claim a 50% reduction in CPU usage. It's an interesting approach,
though I suspect that even as we speak a new circle of hell is being warmed
up especially for those who are enabling PHP's continued existence thanks
to gimmicks such as this one...
Cheers,
Dario Teixeira
[1] https://github.com/facebook/hiphop-php/wiki/
Yoann Padioleau
On Nov 19, 2010, at 11:46 AM, Dario Teixeira wrote:
> Hi,
>
>> 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.
>
> Actually, Facebook has a compiler that transforms PHP source code into C++ [1],
> and they claim a 50% reduction in CPU usage.
Yes, which is good. But if you think about it is "only" a x2 speedup vs a
really slow bytecode interpreter (the Zend PHP interpreter). PHP is known
for being more than 30 times slower than C.
It's even slower than Ruby on http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php
There are lots of opportunities to do better IMHO.
> It's an interesting approach,
> though I suspect that even as we speak a new circle of hell is being warmed
> up
Oh yeah.
Jon Harrop
Benedikt Meurer
On Nov 20, 2010, at 16:19 , Vincent Balat wrote:
> On Nov 19, 2010 21:20:01, Yoann Padioleau wrote:
>> On Nov 19, 2010, at 11:46 AM, Dario Teixeira wrote:
> ...
>>> Actually, Facebook has a compiler that transforms PHP source code into
>>> C++ [1], and they claim a 50% reduction in CPU usage.
>>
>> Yes, which is good. But if you think about it is "only" a x2 speedup vs a
>> really slow bytecode interpreter (the Zend PHP interpreter). PHP is known
>> for being more than 30 times slower than C.
>> It's even slower than Ruby on
>> http://shootout.alioth.debian.org/u32/which-programming-languages-are-fast
>> est.php There are lots of opportunities to do better IMHO.
>
> Would it be completely inconceivable for a company like facebook to
> reimplement everything using a fast well designed typed language
> instead of "spending hundreds of millions of dollars on machines that run PHP
> bytecode interpreters"? (quoting Yoann)
It's probably not a technical decision, but more likely a marketing decision. If you tell Joe that your webservices run on Java, PHP or .NET, he'll say "great", "sure" or "wow" (not because Joe's familiar with the technology or the theory, but because he's familiar with the terms). Tell Joe your webservices run on OCaml or Haskell and the best answer you can get will be "what?".
> Vincent [not completely joking]
Benedikt
Yoann Padioleau
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
Yoann Padioleau
On Nov 20, 2010, at 7:42 AM, Benedikt Meurer wrote:
>
> On Nov 20, 2010, at 16:19 , Vincent Balat wrote:
>
>> On Nov 19, 2010 21:20:01, Yoann Padioleau wrote:
>>> On Nov 19, 2010, at 11:46 AM, Dario Teixeira wrote:
>> ...
>>>> Actually, Facebook has a compiler that transforms PHP source code into
>>>> C++ [1], and they claim a 50% reduction in CPU usage.
>>>
>>> Yes, which is good. But if you think about it is "only" a x2 speedup vs a
>>> really slow bytecode interpreter (the Zend PHP interpreter). PHP is known
>>> for being more than 30 times slower than C.
>>> It's even slower than Ruby on
>>> http://shootout.alioth.debian.org/u32/which-programming-languages-are-fast
>>> est.php There are lots of opportunities to do better IMHO.
>>
>> Would it be completely inconceivable for a company like facebook to
>> reimplement everything using a fast well designed typed language
I think it is inconceivable. I doubt facebook will switch to ocaml and ocsigen tomorrow :)
The problem is how to migrate code to another language smoothly ? You can not
stop all development for a month and say "Hey everybody, we are porting
our 10 millions lines of code of PHP to X.". The reason C++ succeeded was
because there was a smooth migration path. C code is valid C++ code. You
can incrementally add objects to an existing codebase.
Do we have example of big companies porting their whole codebase to another language ?
>> instead of "spending hundreds of millions of dollars on machines that run PHP
>> bytecode interpreters"? (quoting Yoann)
Apparently they decided to keep PHP and switch from a slow bytecode interpreter
to a 2x-faster compiler.
>
> It's probably not a technical decision, but more likely a marketing decision. If you tell Joe
Who is Joe ? A developer ? A user ? A venture capitalist ?
> that your webservices run on Java, PHP or .NET, he'll say "great", "sure" or "wow" (not because Joe's familiar with the technology or the theory, but because he's familiar with the terms). Tell Joe your webservices run on OCaml or Haskell and the best answer you can get will be "what?".
I doubt any user care about how facebook is implemented. Twitter and Foursquare run on Scala and
this is not a very popular language.
Benedikt Meurer
On Nov 20, 2010, at 17:10 , Yoann Padioleau wrote:
>> It's probably not a technical decision, but more likely a marketing decision. If you tell Joe
>
> Who is Joe ? A developer ? A user ? A venture capitalist ?
Joe is 99.9% of world's population, excluding experts in this special area.
>> that your webservices run on Java, PHP or .NET, he'll say "great", "sure" or "wow" (not because Joe's familiar with the technology or the theory, but because he's familiar with the terms). Tell Joe your webservices run on OCaml or Haskell and the best answer you can get will be "what?".
>
> I doubt any user care about how facebook is implemented. Twitter and Foursquare run on Scala and
> this is not a very popular language.
You can develop web services using probably any programming language available in the world. That's what I was about to say, it doesn't matter from a technological point of view. So if the programming language is irrelevant, but you have to pick one, you'll start looking for arguments to prefer one over the other (based on available libraries, marketing, etc.). Some argument made Facebook pick PHP (instead of Perl, Java, Ruby, C/C++, OCaml, Haskell, Standard ML, whatever), probably something trivial like availability of PHP developers, or simply because PHP was popular at that time (i.e. there were people who knew the term "PHP").
Now the world looks different of course, there are hundreds of millions lines of existing code, and really porting all that code to a new language would involve a lot of effort, money and time.
Jon Harrop
> another language ?
Yes, of course. Companies modernise all the time. We have a client who just
started porting 1MLOC of C++ to F#. Flying Frog have ported hundreds of
thousands of lines of OCaml to F#. It happens all the time but it is even
more likely to happen as a consequence of multicore.
Cheers,
Jon.
Gerd Stolpmann
> On Nov 20, 2010, at 7:42 AM, Benedikt Meurer wrote:
>
> >
> > On Nov 20, 2010, at 16:19 , Vincent Balat wrote:
> >
> >> On Nov 19, 2010 21:20:01, Yoann Padioleau wrote:
> >>> On Nov 19, 2010, at 11:46 AM, Dario Teixeira wrote:
> >> ...
> >>>> Actually, Facebook has a compiler that transforms PHP source code into
> >>>> C++ [1], and they claim a 50% reduction in CPU usage.
> >>>
> >>> Yes, which is good. But if you think about it is "only" a x2 speedup vs a
> >>> really slow bytecode interpreter (the Zend PHP interpreter). PHP is known
> >>> for being more than 30 times slower than C.
> >>> It's even slower than Ruby on
> >>> http://shootout.alioth.debian.org/u32/which-programming-languages-are-fast
> >>> est.php There are lots of opportunities to do better IMHO.
> >>
> >> Would it be completely inconceivable for a company like facebook to
> >> reimplement everything using a fast well designed typed language
>
> I think it is inconceivable. I doubt facebook will switch to ocaml and ocsigen tomorrow :)
> The problem is how to migrate code to another language smoothly ? You can not
> stop all development for a month and say "Hey everybody, we are porting
> our 10 millions lines of code of PHP to X.". The reason C++ succeeded was
> because there was a smooth migration path. C code is valid C++ code. You
> can incrementally add objects to an existing codebase.
It's not a matter of the technical migration. You simply wouldn't find
enough engineers that can master a "fast well designed typed
language" (assuming here you have the more advanced ones in mind :-) ).
Also, there is the question whether it is the best approach to let the
most talented developers in the company program the user interface, with
day-to-day tasks like "hey Joe, can you please fix this broken link".
(Not that there are also complicated UI's but these are rare.)
At Mylife.com (where I'm currently consulting for) large parts of the
backend are now running in Ocaml, but the web frontend is done by
another team, and there is PHP involved. IMHO, it would be a
misallocation of human resources if we (the Ocaml team) also did the
frontend.
> Do we have example of big companies porting their whole codebase to another language ?
Usually languages are only switched when a completely new project is
started.
Gerd
> >> instead of "spending hundreds of millions of dollars on machines that run PHP
> >> bytecode interpreters"? (quoting Yoann)
>
> Apparently they decided to keep PHP and switch from a slow bytecode interpreter
> to a 2x-faster compiler.
>
> >
> > It's probably not a technical decision, but more likely a marketing decision. If you tell Joe
>
> Who is Joe ? A developer ? A user ? A venture capitalist ?
>
> > that your webservices run on Java, PHP or .NET, he'll say "great", "sure" or "wow" (not because Joe's familiar with the technology or the theory, but because he's familiar with the terms). Tell Joe your webservices run on OCaml or Haskell and the best answer you can get will be "what?".
>
> I doubt any user care about how facebook is implemented. Twitter and Foursquare run on Scala and
> this is not a very popular language.
>
>
> >
> >> Vincent [not completely joking]
> >
> > 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
>
>
>
> _______________________________________________
> 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
>
--
------------------------------------------------------------
Gerd Stolpmann, Bad Nauheimer Str.3, 64289 Darmstadt,Germany
ge...@gerd-stolpmann.de http://www.gerd-stolpmann.de
Phone: +49-6151-153855 Fax: +49-6151-997714
------------------------------------------------------------
Yoann Padioleau
On Nov 20, 2010, at 8:25 AM, Benedikt Meurer wrote:
> You can develop web services using probably any programming language available in the world. That's what I was about to say, it doesn't matter from a technological point of view. So if the programming language is irrelevant, but you have to pick one, you'll start looking for arguments to prefer one over the other (based on available libraries,
I think this is the key, available libraries and tools around the language.
> marketing, etc.). Some argument made Facebook pick PHP (instead of Perl, Java, Ruby, C/C++, OCaml, Haskell, Standard ML, whatever), probably something trivial like availability of PHP developers
You think smart people in startups make big decisions based on such trivial things ?
I guess they've chosen PHP in 2005 because it made sense to choose PHP in the context of what they were doing: prototyping
a social website as soon as possible by reusing as much as possible (Apache, Mysql, etc).
I know OCaml, I know PHP, I know Java, and in 2005 I've written my homepage in PHP, not OCaml, not Java.
Yoann Padioleau
On Nov 20, 2010, at 9:08 AM, Jon Harrop wrote:
>> Do we have example of big companies porting their whole codebase to
>> another language ?
>
> Yes, of course. Companies modernise all the time. We have a client who just
> started porting 1MLOC of C++ to F#.
How they do that ? Are they using compiler frontends to assist them
in automatically translating part of the code to F# ?
> Flying Frog have ported hundreds of
> thousands of lines of OCaml to F#.
OCaml and F# are very similar language, so such porting does not look that hard.
Translating from C++ to F#, or from PHP to Java seems more complicated.
I wonder what kind of techniques people have developed to help such language-to-language
translation.
Sylvain Le Gall
>
> On Nov 20, 2010, at 9:08 AM, Jon Harrop wrote:
>
>>> Do we have example of big companies porting their whole codebase to
>>> another language ?
>>
>> Yes, of course. Companies modernise all the time. We have a client who just
>> started porting 1MLOC of C++ to F#.
>
> How they do that ? Are they using compiler frontends to assist them
> in automatically translating part of the code to F# ?
>
I worked for Metaware (http://www.metaware.fr). This company does source
to source migration of COBOL code. We also tried once to do COBOL to
Java translation using internal tools... It works, but probably not the
way you expect... Or maybe the same way obrowser works in fact: you
create a VM that interpret something in between COBOL and Java. You
loose comments and meanings in between. The result is 100%
unmaintainable/unreadable and at least 2x bigger.
We stopped this kind of migration, because the result was not exactly
great (but it works).
>> It happens all the time but it is even
>> more likely to happen as a consequence of multicore.
I doubt an old code, not written with multicore in mind is easily
portable to multicore. So basically, the migration you are talking about
is starting a new project that will replace one software/library by
another.
Regards,
Sylvain Le Gall
Jon Harrop
> On Nov 20, 2010, at 9:08 AM, Jon Harrop wrote:
> >> Do we have example of big companies porting their whole codebase to
> >> another language ?
> >
> > Yes, of course. Companies modernise all the time. We have a client
> > who just
> > started porting 1MLOC of C++ to F#.
>
> How they do that ? Are they using compiler frontends to assist them
> in automatically translating part of the code to F# ?
We do it for them for a fee, using magic. We tried automated translation
(from Fortran) but it is usually easier just to knuckle down by hand. Old
code bases are usually 90% cruft anyway. That 1MLOC of C++ could have been
100kLOC of C++ but now it will be 10kLOC of F# instead.
> > Flying Frog have ported hundreds of thousands of lines of OCaml to F#.
>
> OCaml and F# are very similar language, so such porting does not look
> that hard.
Yes. The main thing is that OCaml source is nice and readable so it is easy
to translate even if it makes heavy use of features that don't port
(polymorphic variants, macros). C++ source can be a nightmare so you really
need to pin down a precise specification for what it does using advanced
techniques like poking it with a stick.
> Translating from C++ to F#, or from PHP to Java seems more
> complicated.
> I wonder what kind of techniques people have developed to help such
> language-to-language translation.
The only viable option seems to be to do it by hand. You can churn through
an enormous amount of code when you put your mind to it...
Jon Harrop
> I doubt an old code, not written with multicore in mind is easily
> portable to multicore. So basically, the migration you are talking
> about
> is starting a new project that will replace one software/library by
> another.
Yes, the systems are kept loosely coupled during the transition so it is
more like a new project to supercede the old one than a gradual transition
between code bases. However, only the developers need be aware of this
distinction. From the point of view of everyone else in the company, the
implementation of a product is being modernized. Management get improved
productivity/maintainability. Sales get shiny new things. HR get to fire any
developers who resist (but most are assimilated ;-).
The avalanche happens when the cost of rewriting falls below the cost of
adding essential features to a legacy code base.
Cheers,
Jon.
Elias Gabriel Amaral da Silva
> Do we have example of big companies porting their whole codebase to another language ?
Linspire? The distro ERS went to work, formely Lindows. They had
everything in OCaml and then rewrote to Haskell. It seems to me that
OCaml wasn't functional enough.
It seems to me that they broke, too.
Alain Frisch
> Actually, Facebook has a compiler that transforms PHP source code into C++ [1],
> and they claim a 50% reduction in CPU usage.
I haven't looked into this project, but I've a hard time believing this
is a better approach than compiling PHP to Javascript. The translation
would probably produce quite idiomatic Javascript code on which modern
interpreters do an amazing job (and they keep improving). These
interpreters focus on optimizing what made naive Javascript interpreters
so slow and I assume the typical PHP interpreter has poor performance
for the same reasons.
-- Alain
Jerome Vouillon
> On 11/19/2010 8:46 PM, Dario Teixeira wrote:
> >Actually, Facebook has a compiler that transforms PHP source code into C++ [1],
> >and they claim a 50% reduction in CPU usage.
>
> I haven't looked into this project, but I've a hard time believing
> this is a better approach than compiling PHP to Javascript. The
> translation would probably produce quite idiomatic Javascript code
> on which modern
> interpreters do an amazing job (and they keep improving).
I'm not so sure about that. For instance, PHP has complex implicit
conversion rules which are not the same as Javascript rules. These
would have to be made explicit, at a high cost. The calling
convention is likely to be different too.
On the other hand, OCaml compiles well to Javascript. We experience
performances comparable to those of the bytecode interpreter with
Js_of_ocaml, our compiler ( http://ocsigen.org/js_of_ocaml/ ).
(I should really make an official release soon...)
-- Jerome