[MLton] Multicore CPU's and MLton

[Wesley W. Terpstra]

On Sun, Jul 03, 2005 at 03:57:32PM -0400, Ray Racine wrote:
> Try any number of websites.  This future is very much now.  For example,
> in the Java/J2EE world I have a fleet of ex-VBers banging away on
> servlets and JSP's.  Funny thing is they are so used to the basic
> patterns and because of the very nature of the REST based web
> (stateless) they (mostly) write concurrent code without knowing that
> that is what they are doing.  Scary but all too true.

The best way to implement scalable web services is not with threads.
What you will find much more scaleable is to use an EDSM inside
process-level concurrency. I know Java doesn't do this, but threaded
servers are slapped down by well implemented process-level concurrency.

See http://state-threads.sf.net for more information.
Prior to apache2, state threads was hacked into apache for a 10* boost.
Apache2 uses a bastardized version of state-threads today, but it is
actually not as fast as the original.

> It is typical to have 100's of users submitting web requests with a 1-1
> correspondence between thread <-> request (even this is changing) where
> dozens of those threads are all zipping concurrently through the same
> action handler.

Yeah, and each of those threads has lock-contention with the others.
What's the point, unless you actually have multiple CPUs, and in that case
you don't need the shared resources, since you have perfect parallelism.

> The tragedy of it all is of course the whole web thing is REST based and
> is therefore PERFECTLY aligned for functional languages.  I can't tell
> you how many times I've thought, "if only we were doing this in a ML /
> Haskell like language with a CML like model."

True, but there's nothing that makes event-based systems (like
publish-subscribe) unsuited to functional languages. Indeed, you might
argue that this is better done in a functional language because there
is less concern about side-effects.

-- 
Wesley W. Terpstra