Re: Interpreter vs hardware threads

[William Chesters <williamc@paneris.org>]

Stefan Monnier writes:
 > >>>>> "Max" == Max Skaller <maxs@in.ot.com.au> writes:
 > > Asume LOTS of threads (thousands).
 > 
 > (insert-file "many-threads-bad-design")
 > 
 > > [Hardware threads are not fast enough]
 > 
 > [ I assume you mean OS threads, since hardware-supported threads
 >   are not very common. ]
 > 
 > I guess it depends on the OS and the pthreads implementation, but
 > it seems that they are usually pretty fast (i.e. fast enough that
 > people more or less stopped trying to make them faster).

I think you are being patronising from a position of innocent
ignorance.  Judging by Max's .sig he's doing embedded telecoms boxes,
something like a GSM HLR which juggles many thousands of concurrent
transactions in some ghastly protocol or other.

   Typically the logic of each transaction is encoded in an
unstructured FSM---the same way as the wretched committees "specify"
them---rendered literally in C/C++. That's very fiddly and leads to
bugs, hence loss of revenue on a telephone-number scale, and a
well-founded reluctance to add features.  The convenience of using
threads and a more sensible language would pay for some loss of
performance, but obviously a massive hit for using lots of threads is
unacceptable.

   IIRC, Linux native pthreads, for one, aren't at the moment meant to
be used in huge numbers---the flood-test performance of those Linux
Java VMs which map Java threads onto them supposedly suffers compared
with those that don't.  But Xavier would be able to tell us more about
that :).

   (Of course, one could always ask the ocaml team that won the ICFP
competition in such spectacular fashion to knock off an
ocaml-to-event-driven-FSM compiler ...)

   Max---if you end up using ocaml for embedded work I'd be very
interested to hear about it.