Glynn Clements <[EMAIL PROTECTED]> writes:
> Stefan Reich wrote:
>> I'd like to ask a general question about unsafePerformIO: What exactly
>> does unsafe mean? Just "impure" or rather "may lead to all kinds of
>> problems, you better don't use this"?
> Essentially both. Haskell assumes purity
Stefan Reich wrote:
> > DiffArray is an example of a good use for unsafePerformIO: it uses
> > imperative operations to implement a pure API. The DiffArray is made of
> > mutable objects under the hood, but as far as the programmer is
> > concerned it behaves just like a pure Array.
>
> I'd lik
Simon Marlow wrote:
DiffArray is an example of a good use for unsafePerformIO: it uses
imperative operations to implement a pure API. The DiffArray is made of
mutable objects under the hood, but as far as the programmer is
concerned it behaves just like a pure Array.
I'd like to ask a general que
> >This is one good reason they have to be protected by MVars
>
> Forgive my stupidity, but arn't the MVar operations
> (takeMVar, putMVar)
> IO operation, therefore the locks must be in the IO monad, therefore
> the code acting on the DiffArray should be in the IO monad...
> otherwise they ca
>This is one good reason they have to be protected by MVars
Forgive my stupidity, but arn't the MVar operations (takeMVar, putMVar)
IO operation, therefore the locks must be in the IO monad, therefore
the code acting on the DiffArray should be in the IO monad... otherwise
they can't use the MVar c
> Could you not provide MVar free calls for use inside a
> withMVar function,
> minimising locking overhead?
Are you suggesting something like
withDiffArray
:: DiffArray ix e
-> (UnlockedDiffArray ix e -> IO a) -> IO a
and then a bunch of fast operations on UnlockedDiffArray? The
Could you not provide MVar free calls for use inside a withMVar function,
minimising locking overhead?
Keean Schupke.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> > The problem was whether DiffArrays should be thread-safe in the
> > Concurrent Haskell sense, which means protecting access to
> the DiffArray
> > with an MVar.
>
> Can you give some estimate of the cost of using an MVar in this way?
It depends a lot on whether the cost of using the MVar i
> The problem was whether DiffArrays should be thread-safe in the
> Concurrent Haskell sense, which means protecting access to the DiffArray
> with an MVar.
Can you give some estimate of the cost of using an MVar in this way?
Could some cheaper mechanism be provided for the special case of a mut
> >GHC only runs code on a single CPU at the moment
>
> Is this true even if compiled with --threaded-rts ?
Yes, except that Haskell code may run concurrently with one or more OS
threads running C code. The restriction is that there can only be one
OS thread running Haskell code at any one tim
>GHC only runs code on a single CPU at the moment
Is this true even if compiled with --threaded-rts ?
regards,
Keean Schupke.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskel
> >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 ev
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 co
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 re
>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
> I haven't checked the DiffArray implementation, though (it would be nice
> if someone could investigate DiffArray and fix any perf problems they
> find).
The most obvious one is that all accesses are protected by an MVar. Of
course, this is necessary in some code but I'm guessing that it's al
> Hello again,
>
> Another thought..
>
> Could it be that sTree0 is cyclic that accounts for this
> dramatic slow down? I'm not to sure how DiffArray are
> implemented, but if it's how I would do it it seems you
> would end up with a massive chain of indirections.
Possible. It is possible to
Hello again,
Another thought..
Could it be that sTree0 is cyclic that accounts for this
dramatic slow down? I'm not to sure how DiffArray are
implemented, but if it's how I would do it it seems you
would end up with a massive chain of indirections.
Actually, it's probably not a good idea to have
On Monday 27 Oct 2003 3:17 pm, Alastair Reid wrote:
> You don't mention _how_ you use diffarrays so I'll guess you're keeping the
> array in ascending order, finding the insertion point by binary search and
> inserting by copying bigger elements one place to the right.
> Using binary trees (the co
> [Binary tree] seems to be taking about 4.8 seconds (of 5.1 seconds total
> program execution time) for the input I'm using. I thought using
> DiffArrays might be faster, but no such luck. Execution time rose
> to 9.5 *minutes*.
>
> Is this what I should expect to see?
You don't mention _how_ yo
Hello,
I've been trying to optimise the following code..
-- Search Tree data type
newtype STree = STree (Array Int (STree,[Match]))
-- Initial value for Search Tree
sTree0 :: STree
sTree0 = STree (array (0,9) [(n,(sTree0,[]))| n <- [0..9]])
-- Make the search tree from a list of words
makeSTree
21 matches
Mail list logo
