RE: Interpreter vs hardware threads

From: Simon Peyton-Jones (simonpj@microsoft.com)
Date: Tue Mar 07 2000 - 09:30:29 MET

  • Next message: Simon Peyton-Jones: "RE: Interpreter vs hardware threads"

    | The sad fact is that there doesn't exist any implementation technique
    | for threads that satisfy both viewpoints at once. Very lightweight
    | threads do exist, see e.g. the call/cc-based threads of SML/NJ, but
    | entail significant performance penalties not only on I/O, but also on
    | the actual running speed of the sequential code. "Heavyweight"
    | threads such as LinuxThreads or Win32 threads are very efficient
    | w.r.t. I/O, but are expensive to start and to context-switch.

    Is that really so, Xavier? What percentage performance penalty do
    you think is involved? 1%? 10%? Factor of 2?

    Very-lightweight threads typically have to do
    a stack-overflow check at the start of each function, but apart from the
    I don't see that they are necessarily less efficient than heavyweight
    threads.
    For potentially-blocking I/O operations it is true that there is
    some extra work to do, much like a context switch. The pointers need
    to be saved in a safe place in case GC strikes, and a global lock should
    be released so that a new heavyweight thread can take over the business
    of running the lightweight threads if the I/O blocks. But none of
    this seems really expensive in terms of % of computation time, does it?

    Concurrent Haskell takes the very-lightweight approach. Stacks are
    allocated in the heap and can grow arbitrarily. A thread that is
    blocked on a channel that is not reachable is garbage collected
    (something that came up earlier in this conversation).

    But I agree that there are compromises. Notably, a call to a
    C procedure that cannot block nor cause GC can be done more
    efficiently, so there's some incentive to have two kinds of
    call, which is really a pain. But the biggest compromise is that
    it's hard to do preemption on very lightweight threads, esp if you
    want to support accurate GC too.

    Beyond Concurrent Haskell, I'm working on a specification for
    very-lightweight
    style concurrency in C--. The idea is this: what is the primitive
    support required from the C-- runtime that lets you implement lightweight
    concurrency. You provide the scheduler, synchronisation, etc etc; C-- only
    provides the stuff that lets you run and suspend a computation.
    If anyone is interested, a working draft is at
            http://research.microsoft.com/~simonpj/tmp/c--concurrency.ps.gz
    I'd be delighted to get feedback.

    Simon



    This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 09:36:26 MET