Re: [web-caml] Re: [Caml-list] Web Development with OCaml

[Vitaly Lugovsky <vsl@ontil.ihep.su>]

On Fri, 13 Jul 2001, Xavier Leroy wrote:

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

 Is there any benchmarks for Caml? I tryed to modify an i386 compiler
backend to produce a PIC, but I failed. For Alpha we don't need a PIC,
so it will work as fast as statically linked native (but without
inlining...)

> but surely JIT-produced code
> is much worse.  If you don't believe me, compare performance between
> gcc -fpic -O and any Java implementation :-)

 JVM is not the best architecture for a JIT compilation. When I'm talking
about JIT for Caml, I really mean a late compilation and linking, using
the same intermediate formats as in a current native compiler. You only
have to serialize it into object file, and include some parts of compiler
into runtime. I understood, that OCaml bytecode is not well suited for
JVM-like JIT. Even much more worse then JVM itself.

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

 Btw., Java permits a traditional compilation: take a look at GCJ, it
produces a very nice code, except the stupid GC...

> Second, you (and others) seem to take for granted that a "servlet
> container" must load servlets dynamically into its own memory image.

 No. I only don't want to recompile the whole server when I add some new
functions. I don't even think about dynamic RELOADING of objects. It's a
big problem even for a Java (just restarted again this stupid Tomcat...).

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

 But what if we have only one big servlet, which operates with a lot of
different templates/"... server pages", and using a lot of external
libraries?

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

 Sure, there could be some other ways. But this one seems to me as the
most easy and historically proven. If we want to beat the Java, we have to
show a very close, but better alternative to those java programmers who
was bored with all that disgusting JSPs, Servlets, Oracle Business Objects
and so on. I'm the one of them - I'm using Java, I hate Java, but I can't
prove to my collegues that even Kawa-based solutions will be much
better...


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