Re: DiffArray Performance
never used in multi-threaded situation.
Erm, nearly all my code in Haskell is multi-threaded. One of the main reasons why I am using haskell is the low-cost light weight multi-threading. Surely this is a big win for Haskell on SMP/Numa machines - which are surely the future - as even Intel have realised they can't just keep ramping up clock speeds and have gone multi-core for their next pentium iteration. Just look at the benchmarks for the multi-cpu opteron machines! I would hesitate to make any type unsafe for multi-threading by default - I think all the guards should be in as standard ... maybe a compile time (or run-time) flag to replace the guards with NO-OPS for single CPU machines might be a sensible option. Regards, Keean Schupke.
Alastair:
never used in multi-threaded situation.
MR K P SCHUPKE:
Erm, nearly all my code in Haskell is multi-threaded.
And do you use DiffArrays? MR K P SCHUPKE:
I would hesitate to make any type unsafe for multi-threading by default
Sorry to be unclear. I wasn't actually saying to remove the support. I was thinking that, if the current mutex implementation is killing performance (and it is an assumption - though one of the Simons could probably confirm or deny it), we should look to see if mutexes can be made cheaper or rewrite the code to avoid it or ... For example, the Java community has done a lot of work on how to make it cheap to take an uncontested lock but more expensive to take a contested lock. -- Alastair Reid
On Tue, 2003-11-04 at 13:41, Alastair Reid wrote:
I was thinking that, if the current mutex implementation is killing performance (and it is an assumption - though one of the Simons could probably confirm or deny it), we should look to see if mutexes can be made cheaper or rewrite the code to avoid it or ... For example, the Java community has done a lot of work on how to make it cheap to take an uncontested lock but more expensive to take a contested lock.
In the next Linux kernel (2.6.x) you can implement mutexes using 'futex'es which in the uncontested case cost 1 atomic memory increment/decrement operation plus 1 register to register comparison. In the contested case it still requires a kernel call. Of course this is for mutexes for OS threads/processes. An implementation for a pure user space thread implementation like ghc's might be even simpler / cheaper (although it'd be hard to find an implementation cheaper than 1 atomic memory operation!). Duncan
participants (3)
-
Alastair Reid -
Duncan Coutts -
MR K P SCHUPKE