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 TAA13454; Fri, 13 Jul 2001 19:18:32 +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 TAA13433 for ; Fri, 13 Jul 2001 19:18:31 +0200 (MET DST) Received: from ontil.ihep.su (ontil.ihep.su [194.190.161.63]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f6DHIGT23708; Fri, 13 Jul 2001 19:18:20 +0200 (MET DST) Received: from localhost (vsl@localhost) by ontil.ihep.su (8.11.0/8.11.0) with ESMTP id f6DH8Nm23398; Fri, 13 Jul 2001 21:08:23 +0400 Date: Fri, 13 Jul 2001 21:08:23 +0400 (MSD) From: Vitaly Lugovsky To: Xavier Leroy cc: Caml list , Subject: Re: [web-caml] Re: [Caml-list] Web Development with OCaml In-Reply-To: <20010713160428.A9419@pauillac.inria.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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