[
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 (23:01) |
From: | Asfand Yar Qazi <email@a...> |
Subject: | Re: [Caml-list] STM support in OCaml |
skaller wrote: > On Wed, 2006-03-08 at 10:41 +0000, Asfand Yar Qazi wrote: > > >>Also, from what I remember, STM is "optimistic", while conventional lock-based >>design is "pessimistic" - thereby allowing STM based code to spend less time >>checking for locks or something, which apparently makes it quicker. > > >>But, I'll lets the experts explain it :-) > > > It isn't explanation that is needed but experience > actually using it. The performance tradeoffs -- including > developer time -- won't be evident until significant > applications are developed using it. > > For example I wonder if the technique is worthwhile > *without* the Haskell type system to enforce correctness? > > And given GHC is currently not generating very good code, > will it matter anyhow? > To tell the truth, I just want to be on the bleeding edge - hence my desire to get away from this horrid imperative programming I've been indoctrinated with, and to learn how to get the most out of tomorrows processors, which will all be multi-core. The answer to these problems is obvious - functional programming and concurrent programming. I intend to get experience in as many functional languages as possible so that whatever comes up in the future, I'll be able to get to grips with it. And (according to Tim Sweeny anyway) STM allows writing multithreaded apps "almost as easily as single threaded ones", so would be the solution to the headaches one normally associates with concurrent programming. But, we'll just have to wait and see.