Browse thread
[Caml-list] Why systhreads?
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Xavier Leroy <xavier.leroy@i...> |
| Subject: | Re: [Caml-list] Why systhreads? |
Blair Zajac wrote: > To summarize, for (2) system threads are required and and you can't > prevent blocking with user level threads easily or at all. For (3), > making the Ocaml system support SMP is "Too complex; too hard to > debug" and SMP boxes aren't all that popular. > Aren't these contradictory statements? > > For Ocaml to support a Ocaml program to have one thread to block on a > system call and to allow other threads to continue, doesn't this support > SMP? Does Ocaml support this? No to the first question. Yes to the second. By "supporting SMP", I mean having several threads executing Caml code in parallel, thus using the Caml runtime system in a concurrent fashion. This is the hard part. In the current implementation of systhreads, the Caml executor and runtime system is one big critical section: at most one thread can execute Caml code at a given time, but arbitrarily many other threads can be blocked on I/O (and thus isn't calling the Caml runtime system). Each thread leaves the critical section before calling a potentially blocking I/O operation, and re-enters it when the I/O completes. > I need the functionality to have multiple threads where one thread can > block and not stop the others, either due to the OS or to the Ocaml > runtime system. You have that functionality. What you don't have is the ability to keep several processors busy running Caml code. (As Markus said, you can still have C code running concurrently with Caml code, provided that the C code doesn't call the Caml runtime system.) Chris Hecker wrote: > Xavier saying 1.5x is not worth it is really strange to me; most > performance sensitive programmers I know would kill their mother to get > 1.5x. I wonder what factor would be worth it for Xavier? Factors of 10 are always nice :-) Just kidding. What I meant is the following: assume making the Caml runtime system thread-safe entails a 25% slowdown on program execution. (This can easily happen if e.g. we have to lock a mutex at each heap allocation.) Further assume that by doing so, you get a 1.5 speedup from hyperthreading. In the end, your program will run 1.5 * 0.75 = 1.12 times faster than its equivalent running on the standard, single-processor Caml runtime. It's not worth the effort. - Xavier Leroy ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners