[MLton] Multicore CPU's and MLton

[John Skaller]

--=-i8fXI6mg7EZkiY5SS40F
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Tue, 2005-07-05 at 13:48 -0700, Brent Fulgham wrote:
> --- Stephen Weeks <sweeks@sweeks.com> wrote:
> >=20
> > I think that multi-core is a logical (even
> > necessary) direction for chips to go.  But I think=20
> > that process-level parallelism is usually
> > the way to take advantage of it.
>=20
> I believe this is true as well.  What would be very
> interesting to me would movement towards more of an
> Erlang-style "cheap process" idea.

It is highly application dependent whether processes
or threads are better, in fact complex applications
may need BOTH. Furthermore, 'shared memory' between
processes may be viable or not (depending on if they're
on the same box or not, or even in the same city)

The telco application which inspired the Felix design
is characterised by a huge number of basically dormant
and independent threads of control and where shared
data was not only rare, but one actually desired a=20
strong guarantee of non-interference (privacy etc).

This application easily split into a worker thread
per CPU plus microthreading within that. However,
whilst the 'business logic' constituted separate
processes, the underlying message passing framework
(ACE, TCAP, Basic call handling  logic, etc )=20
would be significantly compromised by actually using=20
processes: they were used as well, but the entry
point in the communication stack for process level
dispatch required extra support up the line,
for example, even the business logic 'threads'
had to be made fully mobile to handle conference
calls, since the call merging required both
calls to be handled on the same box by merging
the call data using application level logic.

Sorry if that isn't fully comprehensible, but the
bottom line is that with a complex application,
there is often a need to use both processes and
threads in a way that seems transparent at the
highest levels, but underneath efficiency
makes it impossible to consider using processes
for everything.

In the telco environment there are representations
of data which are portable -- eg ACN1.1 was used=20
as the encoding, and data can be wrapped in TCP/IP
via TCAP .. but actually moving the data along
a TCP/IP wire is a really bad idea when not
necessary because of the multiple level of encoding/decoding
required -- an unpacked representation in shared memory
is a heck of a lot more efficient.

Just as an indicator, the actual system only managed
to achieve 30 calls/second instead of 300 -- an order
of magnitude too slow: the biggest bottleneck
appeared to be use of C++ string class for just about
every piece of information.

Copying about 100 strings per call when you have
100K+ active calls is not smart when you can used
shared memory.

What I am trying to say here is that 'abstract'
considerations of whether 'threads' or 'processes'
are the way to go miss the point -- many real world
applications have to use BOTH: it isn't a 'this way
or that way' issue: performance demands threads,
and scalability demands processes.

Similarly, garbage collection just isn't viable
for all data in this kind of application, and it isn't
necessary -- strings and numeric data can't contain
pointers, and trees can't contain cycles. So very often,
user level locking and management of some of the memory
can relieve a garbage collector of a lot of work,
which might well mean a collector that *can* cope with
multiple threads could still be viable -- getting
a non-stop process to work reliably is important.

If I had to generalise I'd say that mutable data bases
present an example where processes are useless:
there's no choice but to use threads with shared
memory to obtain cache coherence, and clearly
performance dictates using hardware threads that
can be distributed between multiple CPUs in the
same box.. as well as microthreads to service the
actual user requests within each hardware thread:
you really HAVE to do both.

--=20
John Skaller <skaller at users dot sourceforge dot net>
Download Felix: http://felix.sf.net

--=-i8fXI6mg7EZkiY5SS40F
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQBCy1/Lw7vY25tjqN4RAqWEAKCGIKlXyv9vkRuf4AC+pVWwmfM5BQCfTNcq
w/0p6l1gRrMCi+pw6HbNnx0=
=3U+F
-----END PGP SIGNATURE-----

--=-i8fXI6mg7EZkiY5SS40F--