Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Julian Assange <proff@iq.org>
To: Xavier Leroy <Xavier.Leroy@inria.fr>
Cc: William Chesters <williamc@paneris.org>, caml-list@inria.fr
Cc: proff@iq.org
Subject: Re: Interpreter vs hardware threads
Date: 08 Mar 2000 00:19:28 +1100	[thread overview]
Message-ID: <wxg0u26hpb.fsf@suburbia.net> (raw)
In-Reply-To: Xavier Leroy's message of "Mon, 6 Mar 2000 18:35:46 +0100"

Xavier Leroy <Xavier.Leroy@inria.fr> writes:

> >    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 :).
> 
> My pleasure :-)  It is true that threads in LinuxThreads are not as
> lightweight as some would like, mostly because they map 1-to-1 to
> kernel processes, and the Linux kernel limits the number of processes
> to 512 (for the super-user) or 256 (for normal users).  Also, kernel
> scheduling takes time linear in the number of processes (just like the
> OCaml bytecode-thread scheduler, which was strongly inspired by that
> of the Linux kernel), so context switching times increase as more
> threads are run.

I recently worked on a project in C that used a FSM to simulate
several thousand concurrent IO threads, as part of a concurrent
version of dig (able to recursively zone transfer all of *.au in under
three minutes). Due to the complicated, but inherently forward moving
nature of the operations involved (i.e do this. if there is no error
or timeout, do the next step, and so on for about 30 steps) together
with inter-state resources (i.e various queues, buffers and so on) this
ended up as an extremely large and unintuitive piece of code. A lot of
the added complexity was a result of having to explicity deallocate
data and maintain reference counts, and manually follow allocation
dependencies, which in the circumstances of multiple interdependent
event queues and states became extremely tedious.

What is the source of the linearity of thread context switches in
ocaml?  Are there ways to eliminate it? If so I'd be happy to have a
look at doing so.


Cheers,
Julian.

--
Stefan Kahrs in [Kah96] discusses the
   notion of completeness--programs which never go wrong can be
   type-checked--which complements Milner's notion of
   soundness--type-checked programs never go wrong [Mil78].



  parent reply	other threads:[~2000-03-08 18:27 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-02-25 13:37 mixing Ocaml with another GC-ed language STARYNKEVITCH Basile
2000-02-29 10:24 ` Xavier Leroy
2000-03-01  3:48 ` Nice feature Max Skaller
2000-03-01  3:52 ` Interpreter vs hardware threads Max Skaller
2000-03-01 18:55   ` Michael Hicks
2000-03-01 20:02   ` Stefan Monnier
2000-03-02 18:18     ` William Chesters
2000-03-03 16:59       ` John Max Skaller
2000-03-06 17:35       ` Xavier Leroy
2000-03-06 23:11         ` John Max Skaller
2000-03-07 13:19         ` Julian Assange [this message]
2000-03-08 20:12           ` Xavier Leroy
2000-03-19  6:10             ` Julian Assange
2000-03-08 23:30           ` Max Skaller
2000-03-02 17:25 David Gurr
2000-03-03  9:10 Edwin Young
2000-03-06 13:42 ` William Chesters
2000-03-03 12:12 Juergen Pfitzenmaier
2000-03-07  8:30 Simon Peyton-Jones
2000-03-08 20:02 ` Xavier Leroy
2000-03-12  1:45   ` Julian Assange
2000-03-07  9:06 Simon Peyton-Jones
2000-03-10 18:01 Manuel Fahndrich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=wxg0u26hpb.fsf@suburbia.net \
    --to=proff@iq.org \
    --cc=Xavier.Leroy@inria.fr \
    --cc=caml-list@inria.fr \
    --cc=williamc@paneris.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox