Re: [Caml-list] Web Development with OCaml

[Ari Heitner <aheitner@andrew.cmu.edu>]

[apologies to all, i should let sleepng dogs lie. but hey, i go to cmu,
where John Harper gives 15-312 exam questions about java braindamage]

On Fri, Jul 13, 2001 at 04:04:28PM +0200, 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, 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...

I fail to follow this. Isn't Java really no different than C++ except
 - Method calls are dynamic (my tests show this is maybe a 10%
   slowdown. question to java gurus: does "final" make the call static?)
 - Can't use primitive types in containers (big hit)
 - No type parameterization, so containers throw away all type info (yuck!).
   So you have to keep doing expensive rtti (array typing is also broken, so
   you have to typecheck all array access at runtime)
 - of course we all know the java gc's suck

I've definitely seen Java behave slowly. But today I did a dead-simple test
(designed to avoid all the Java weaknesses): a recursive fib, and got
interesting results:
 - Java was a touch faster than gcc (~10% penalty for not making the call 
   "static")
 - gcc (2.95.4) was ~20% slower for pic. I seem to recall gcc 3.0 being
   maybe 10% faster, tho it may be quite a bit faster on less moronic code
   (i've heard up to 40%). but this is a moronic measure that only leans
   on function-call cost -- in real code it should be much less noticeable.
   no one seems to complain about either using shared libraries, or (to 
   be like the java servlet arch below) explicitly loading code via dlopen.
 - ocaml is about 40% faster than java/gcc
 
...

As was mentioned elsewhere, you *can* compile java to native.

And of course I've seen more signficant java stuff just crawl. But my
(decidedly unscientific) guess would be the real penalty is in data
management -- a combination of the weight of the class primitives
(capital-I-Integer and friends) and all the bloody expense of of runtime
typechecking everything (might as well use Python).

It certainly doesn't seem to me that except for braindamaged oo decisions,
the basic language is any harder to optimize than C or C++.

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

Aha! the real point.

CGIs roll over when people keep hitting the system, and apache (not fast in
the first place) croaks as it spawns a new process for every request -- the
system rapidly has too many processes, and swaps itself to death.

The sane thing to do seems to be to have only a few more processes than
CPUs, and drive those processes has hard as possible with async io. There's
no strong reason to make either your httpd or your database process even
multithreaded...

that aside, using java just to get around switching to a new version of the
servlet without downing the server is even worse -- just bloody use
dlopen...



cheers,

ari

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