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: | Gerd Stolpmann <info@g...> |
| Subject: | Re: [Caml-list] Why systhreads? |
Am 2002.11.27 19:04 schrieb(en) Chris Hecker: > Now, as you point out, threads are complicated to design, program, and > debug. I agree with this completely. As I said, I never use threaded > designs if I can avoid it. However, if it becomes very easy to spawn very > small scale parallel threads in C on an HT processor, then it could make a > big performance difference for some algorithms. People are working on C > compilers that have these extensions built in. Intel's got one > now. They'll be first, everyone will ignore it until the installed base is > big enough, and then it'll go into msvc. MMX, SSE, and 3dnow followed the > exact same path. If it is really easy to spawn a second thread (or wake an existing thread up), this could be useful for OCaml's runtime system internally. I can imagine that it is not that difficult to rewrite the GC such that it runs in two threads. I don't mean that it runs in parallel with the rest of the program (expensive locking problems), but that the runtime system wakes two GC threads up when it is necessary, and waits until both threads have done their job. That would reduce the time spent with GC, maybe from 30% to 20% for a typical program. Of course, this is only possible when there are good ideas to parallelize the GC such that the extra coordination time does not eat up the extra CPU power. Just an idea, I really do not know whether it is doable (or worth doing it). Gerd ------------------------------------------------------------ Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de ------------------------------------------------------------ ------------------- 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