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