From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id QAA08067; Fri, 13 Jul 2001 16:13:01 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id QAA09995 for ; Fri, 13 Jul 2001 16:13:00 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f6DE4TT17153; Fri, 13 Jul 2001 16:04:29 +0200 (MET DST) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id QAA09900; Fri, 13 Jul 2001 16:04:28 +0200 (MET DST) Date: Fri, 13 Jul 2001 16:04:28 +0200 From: Xavier Leroy To: Vitaly Lugovsky Cc: Alain Frisch , William Chesters , Caml list , web-caml@quatramaran.ens.fr Subject: Re: [Caml-list] Web Development with OCaml Message-ID: <20010713160428.A9419@pauillac.inria.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from vsl@ontil.ihep.su on Fri, Jul 13, 2001 at 03:16:13PM +0400 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > 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