Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Web Development with OCaml
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Xavier Leroy <Xavier.Leroy@i...>
Subject: Re: [Caml-list] Web Development with OCaml
>  As I already mentioned here, we need a possibility to load a modules in
> runtime. Bytecode is fast, but not enough for a killer web architecture.
> So, we need a JIT, or, which will be much better, an object format
> including intermediate lambda-trees to compile it and link at runtime.
> Even a PIC code for native will not be enough, 'cause of a great overhead.

I fail to see the logic in this argument.

First, position-independent native code is indeed a bit slower than
statically-linked code on some platforms, but surely JIT-produced code
is much worse.  If you don't believe me, compare performance between
gcc -fpic -O and any Java implementation :-)

In other terms: those who can, compile ahead of time; those who can't,
compile just in time.  A prime example of those who can't is Java:
they screwed the definition of their language so well that it makes
traditional compilation impossible; hence their propaganda about JITs.
We (Caml) can...

Second, you (and others) seem to take for granted that a "servlet
container" must load servlets dynamically into its own memory image.
That's the Java way, but again that's not the only way.  Using
separate processes for the HTTP server/servlet container and for the
servlets (but not starting a new servlet process on each request like
CGI does) might very well work better: I'll bet the performance hit
would be insignificant, and you get a clean, well-specified
communication protocol between server and servlets.

That's just one idea, but my general point is that the Java (or .NET)
approach is not necessarily the right approach.

- Xavier Leroy
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr