Re: [Caml-list] Will Ocaml use a 4-way SMP box without splitting the program into separate processes?

[William Chesters <williamc@paneris.org>]

Xavier Leroy writes:
 > > Doesn't this mean that a process can never use more than one processor?
 > 
 > Yes, if the process is entirely composed of Caml code.

Oh.  I didn't realise that.

 > Long-running C primitives release the lock, meaning that your
 > 4-processor machine can have 1 processor running Caml code and 3
 > executing C primitives, e.g. database queries.

In practice there are always compelling reasons to one of the standard
SQL DB servers, so the actual query processing isn't done in the
servlet process anyway.  (The reasons are things like: customers want
their data stored in a "proper" database which they trust; they want
to be able to use Excel with it; etc.)

 > Perhaps.  I don't know how important shared-memory multiprocessing is
 > important for large Web applications.  Centralized databases can
 > certainly benefit from large SMP machines, but it was my impression
 > that everything else is equally well done on multiple, inexpensive
 > single-processor PCs.  (Cf. Google vs. Altavista.)

Yes. The one point I would make is that marshalling data to and from
an SQL backend, and getting it into a form which is malleable enough
to support complex application logic in a clean way (e.g. an object DB
like Melati's), is expensive.  Cacheing data within the servlet
process is an effective way of amortising these costs.  And it's much
easier to implement cacheing inside one multithreaded process than
between several processes, potentially on different machines.

Also for a small-scale operation, TCO of a single SMP machine is lower
than that of multiple cheap PCs.

 > At any rate, I believe a single-processor PC can handle a fairly high
 > Web traffic, if well programmed.  Of course, if you're amazon.com or
 > google.com that will not suffice, but it should be enough for
 > joesbusiness.com :-)

Very true.  It is really astonishing what you can get away with.
-------------------
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