The thread library is type-safe, is relatively simple to implement,
and has good performance. Application-level threads are extremely
lightweight (scaling to 10,000,000 threads!) and our scheduler, which
is implemented as a modular and extensible event-driven system,
outperforms NPTL in I/O benchmarks.
http://www.seas.upenn.edu/~lipeng/homepage/unify.html
holy crap!
anything like that in lisp?
On Sep 22, 7:05 am, gavino <·········@gmail.com> wrote:
> The thread library is type-safe, is relatively simple to implement,
> and has good performance. Application-level threads are extremely
> lightweight (scaling to 10,000,000 threads!) and our scheduler, which
> is implemented as a modular and extensible event-driven system,
> outperforms NPTL in I/O benchmarks.
>
> http://www.seas.upenn.edu/~lipeng/homepage/unify.html
>
> holy crap!
>
> anything like that in lisp?
Did you hear? Threads and shared concurrency are a thing of the
past. Process forking and copy-on-write are all the rage again,
thanks to Google and, yes, functional programming itself... share
nothing, mutate your local copies...
On 2008-09-22, gavino <·········@gmail.com> wrote:
> The thread library is type-safe, is relatively simple to implement,
> and has good performance. Application-level threads are extremely
> lightweight (scaling to 10,000,000 threads!) and our scheduler, which
> is implemented as a modular and extensible event-driven system,
> outperforms NPTL in I/O benchmarks.
Anyone who thinks that it's a good idea to be able to make ten million threads,
or even anything within several orders of magnitude within that quantity, is a
confused nutcase.
You need only enough threads to avoid idling your processors when there is
potential to perform computational work, and to properly prioritize response to
all pending events.
If the application has compute work to do, you don't want to multiplex that
work onto just a subset of the available processors (at least, not as a matter
of a limitation inherent to the application's design---of course it's
nice to have the flexibility to be able to do that as a matter of policy).
If there is an outstanding event waiting to be serviced, you don't want to
delay responding to that event simply because all your existing threads are
busy dealing with other events. The event may have a higher priority than
some, or all, of the events being serviced.
(Events include completions of I/O, and completion of I/O includes code and
data page faults in a VM system).
There is no system in existence where satisfying these rules of thumb requires
ten million threads.
From the website:
``Our implementation demonstrates how to use these techniques by building an
application-level thread library with support for multiprocessing and
asynchronous I/O mechanisms in Linux. The thread library is type-safe, is
relatively simple to implement, and has good performance. Application-level
threads are extremely lightweight (scaling to 10,000,000 threads!) and our
scheduler, which is implemented as a modular and extensible event-driven
system, outperforms NPTL in I/O benchmarks.''
It's severely misleading to be comparing NPTL to an application threading
library. Basically you're comparing a software-module which dispatches based
on asynchronous I/O to the use of threads. This is apples and oranges, because
you can use the same I/O technique in conjunction with threads.
Application threading (scheduler in user space) has serious disadvantages,
which is why the M:N design was rejected from the NPTL project. It cannot meet
various difficult requirements. If you can simply reject those requirements
(or worse, you're too clueless to even be aware of their existence), then
application threading may look attractive.
Asynchronous I/O allows a single thread to overlap I/O operations. This is a
viable alternative to using additional threads only if, in the given situation,
the only important requirement is that I/O proceed in parallel with a single
instruction stream.
There are limitations. Note that under virtual memory, that instruction stream
may hit a page fault, in which case it blocks. Asynchronous I/O cannot dispatch
computational work in to overlap with the handling of a page fault, because
that would be equivalent to threading.
On Sep 22, 12:37 pm, Kaz Kylheku <········@gmail.com> wrote:
> On 2008-09-22, gavino <·········@gmail.com> wrote:
>
> > The thread library is type-safe, is relatively simple to implement,
> > and has good performance. Application-level threads are extremely
> > lightweight (scaling to 10,000,000 threads!) and our scheduler, which
> > is implemented as a modular and extensible event-driven system,
> > outperforms NPTL in I/O benchmarks.
>
> Anyone who thinks that it's a good idea to be able to make ten million threads,
> or even anything within several orders of magnitude within that quantity, is a
> confused nutcase.
>
> You need only enough threads to avoid idling your processors when there is
> potential to perform computational work, and to properly prioritize response to
> all pending events.
>
> If the application has compute work to do, you don't want to multiplex that
> work onto just a subset of the available processors (at least, not as a matter
> of a limitation inherent to the application's design---of course it's
> nice to have the flexibility to be able to do that as a matter of policy).
>
> If there is an outstanding event waiting to be serviced, you don't want to
> delay responding to that event simply because all your existing threads are
> busy dealing with other events. The event may have a higher priority than
> some, or all, of the events being serviced.
>
> (Events include completions of I/O, and completion of I/O includes code and
> data page faults in a VM system).
>
> There is no system in existence where satisfying these rules of thumb requires
> ten million threads.
>
> From the website:
>
> ``Our implementation demonstrates how to use these techniques by building an
> application-level thread library with support for multiprocessing and
> asynchronous I/O mechanisms in Linux. The thread library is type-safe, is
> relatively simple to implement, and has good performance. Application-level
> threads are extremely lightweight (scaling to 10,000,000 threads!) and our
> scheduler, which is implemented as a modular and extensible event-driven
> system, outperforms NPTL in I/O benchmarks.''
>
> It's severely misleading to be comparing NPTL to an application threading
> library. Basically you're comparing a software-module which dispatches based
> on asynchronous I/O to the use of threads. This is apples and oranges, because
> you can use the same I/O technique in conjunction with threads.
>
> Application threading (scheduler in user space) has serious disadvantages,
> which is why the M:N design was rejected from the NPTL project. It cannot meet
> various difficult requirements. If you can simply reject those requirements
> (or worse, you're too clueless to even be aware of their existence), then
> application threading may look attractive.
>
> Asynchronous I/O allows a single thread to overlap I/O operations. This is a
> viable alternative to using additional threads only if, in the given situation,
> the only important requirement is that I/O proceed in parallel with a single
> instruction stream.
>
> There are limitations. Note that under virtual memory, that instruction stream
> may hit a page fault, in which case it blocks. Asynchronous I/O cannot dispatch
> computational work in to overlap with the handling of a page fault, because
> that would be equivalent to threading.
woa
so how many threads are good or bad for a given piece of hardware?
P� Mon, 22 Sep 2008 21:37:31 +0200, skrev Kaz Kylheku <········@gmail.com>:
>
> Anyone who thinks that it's a good idea to be able to make ten million
> threads,
> or even anything within several orders of magnitude within that
> quantity, is a
> confused nutcase.
For a regular language perhaps. But consider lightweight threads like the
ones in Oz.
On such a system it is perfectly acceptable to have 10000 concurrent
threads.
(been playing with that lately..)
http://www.mozart-oz.org
--------------
John Thingstad