Browse thread
[Caml-list] Web Development with OCaml
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2001-07-13 (14:13) |
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