[
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: | 2006-03-08 (00:43) |
From: | skaller <skaller@u...> |
Subject: | Re: [Caml-list] STM support in OCaml |
On Tue, 2006-03-07 at 19:05 +0000, Asfand Yar Qazi wrote: > You make several claims: > > STM is not lock free. > STM is not useful on a small number of processors > > As for claim 1. "Lock-free" doesn't mean what you think it does. I know what STM does, thank you: I intend to implement it myself in my own programming language. Maybe you should read more carefully. I said "protected by a mutex under the hood." which means sure, the programmer is not writing locks, but they're used in the implementation and the associated costs are still paid. I really hate it when people try to throw papers against simple logic. I said what the tradeoffs where: "It simply limits the locking period to a bounded time, at the expense of the whole transaction taking unbounded time." and then elaborated the conditions under which this made sense. Long locking period on a Uniprocessor not only do not cause problems they can actually IMPROVE performance by preventing expensive context switches. A paper is cached here on my website, probably one of the ones you cited. http://felix.sourceforge.net/papers/ea8-composablememory_stm.pdf It's quite interesting and I've bought a dual core CPU specifically to test it out. The only numbers I can give you are based on a simple lock test on a dual core G5 incrementing an integer: 15x SLOWER on a dual processor than a uniprocessor with two threads. No doubt because of the weak support provided by Linux. Windows may do better, haven't tried yet, but I doubt anything older than Vista has suitable API support. In the end, fast concurrency is going to depend on both CPU and board design and OS support. The point of the above paper is not performance: the point is as I said, Sebastian said, AND the paper emphasises: it provides a model which supports composition. I point out that in fact, under the right conditions -- lots of processors and lots of variables -- it will probably provide better performance too. However this is hard to test -- not many of us have access to >2 cores on the same board. There certainly no way POSIX can deliver good performance: mutexes have to be synchronisation points and that requires ALL the CPUs to flush their caches -- it doesn't scale. Message passing does, since sender and receiver only need to sync the message. Explicit coupling, and both the subset of processor and memory are limited. Oh, and Ocaml supports message passing between processes .. :) -- John Skaller <skaller at users dot sourceforge dot net> Async PL, Realtime software consultants Checkout Felix: http://felix.sourceforge.net