2009/12/16 Matt Morrow moonpa...@gmail.com:
What are peoples' thoughts on this?
http://hackage.haskell.org/trac/ghc/ticket/650#comment:16
I think it won't get any better.
Either we have O(log(N)) updates because we have to update
hierarchical structure to speed up GC scanning (to get it to
On Dec 16, 2009, at 5:50 AM, Serguey Zefirov wrote:
2009/12/16 Matt Morrow moonpa...@gmail.com:
What are peoples' thoughts on this?
http://hackage.haskell.org/trac/ghc/ticket/650#comment:16
I think it won't get any better.
Either we have O(log(N)) updates because we have to update
brad.larsen:
On Tue, Dec 15, 2009 at 11:33 AM, Serguey Zefirov sergu...@gmail.com wrote:
If the number of buckets was fixed, one could use an array of STRefs
to lists. I believe this would avoid the bug from Ticket #650?
now i see what you mean. no, i mean trivial transformation. #650 says
Hello Don,
Wednesday, December 16, 2009, 7:27:29 PM, you wrote:
The bug described in Ticket #650, AFAICS, prevents implementation of a
reasonable, generic hash table in Haskell. :-(
You can certainly implement it, it just requires that you increase the
heap size to a bit bigger than your
On Wed, Dec 16, 2009 at 11:27 AM, Don Stewart d...@galois.com wrote:
[...]
The bug described in Ticket #650, AFAICS, prevents implementation of a
reasonable, generic hash table in Haskell. :-(
You can certainly implement it, it just requires that you increase the
heap size to a bit bigger
On Tue, Dec 15, 2009 at 12:00 PM, Gregory Collins
g...@gregorycollins.netwrote:
Bulat Ziganshin bulat.zigans...@gmail.com writes:
now i see what you mean. no, i mean trivial transformation. #650 says
about slow GC. why it's slow? because once you made any update to the
array, the entire
Brad Larsen wrote:
I have considered using Data.IntMap to implement a sort of faux hash
table, e.g., introduce a Hashable class, and then use an IntMap to
lists of Hashable. The result would be a pure, persistent ``hash
table''. In such a case, however, lookup/insert/delete operations
would
On Wed, Dec 16, 2009 at 2:42 PM, Richard Kelsall
r.kels...@millstream.comwrote:
Brad Larsen wrote:
I have considered using Data.IntMap to implement a sort of faux hash
table, e.g., introduce a Hashable class, and then use an IntMap to
lists of Hashable. The result would be a pure,
Hello Don,
Tuesday, December 15, 2009, 10:42:01 AM, you wrote:
How about a fast STHashTable?
you can use array of arrays instead of large array
Note to minmize the issue, but we get many of the same benefits via the
associated type transformation (e.g. for arrays of
AFAIK, ST Arrays are pure data structures. They are not really mutable. They
are destroyed and recreated on every update. The mutation is just simulated
thanks to the hidden state in the state monad. Sure, the garbage collector
must have a hard work in recycling all the backbones of the discarded
No, they are actually being mutated. ST is basically IO with a
universal state thread (IO uses RealWorld) to prevent you from letting
any of the mutable structures out (or any in) of the block. The whole
point of ST is to have real mutable references/arrays that have a
referentially transparent if
-- Forwarded message --
From: Alberto G. Corona agocor...@gmail.com
Date: 2009/12/15
Subject: Re: [Haskell-cafe] Boxed Mutable Arrays
To: Daniel Peebles pumpkin...@gmail.com
Ok, so the state content is not accessible. Nice.
2009/12/15 Daniel Peebles pumpkin...@gmail.com
Bulat,
On Tue, Dec 15, 2009 at 1:51 AM, Bulat Ziganshin
bulat.zigans...@gmail.com wrote:
Hello Brad,
Tuesday, December 15, 2009, 1:55:41 AM, you wrote:
How about a fast STHashTable?
you can use array of arrays instead of large array
--
Best regards,
Bulat
Hello Brad,
Tuesday, December 15, 2009, 6:53:14 PM, you wrote:
How about a fast STHashTable?
you can use array of arrays instead of large array
Can you elaborate?
what exactly? how to implement this or why it will be faster?
--
Best regards,
Bulat
On Tue, Dec 15, 2009 at 11:00 AM, Bulat Ziganshin
bulat.zigans...@gmail.com wrote:
Hello Brad,
Tuesday, December 15, 2009, 6:53:14 PM, you wrote:
How about a fast STHashTable?
you can use array of arrays instead of large array
Can you elaborate?
what exactly? how to implement this or
Hello Brad,
Tuesday, December 15, 2009, 7:16:18 PM, you wrote:
You said to use an array of arrays instead of a large array, in the
context of a fast hash table in ST. Do you mean I should use an array
for hash buckets, rather than a list?
Is that what you meant? And why would it be
If the number of buckets was fixed, one could use an array of STRefs
to lists. I believe this would avoid the bug from Ticket #650?
now i see what you mean. no, i mean trivial transformation. #650 says
about slow GC. why it's slow? because once you made any update to the
array, the entire
Hello Alberto,
Tuesday, December 15, 2009, 5:23:41 PM, you wrote:
ST monad is the same as IO monad modulo type trickery. tris trickery
allows to limit imperative operations available inside ST monad to
STRef/STArray manipulations which is guaranteed to be
referential-transparent as part of this
Bulat Ziganshin bulat.zigans...@gmail.com writes:
now i see what you mean. no, i mean trivial transformation. #650 says
about slow GC. why it's slow? because once you made any update to the
array, the entire array is marked as updated and scanned on next minor
GC (which occurs after every 512
On Tue, Dec 15, 2009 at 11:33 AM, Serguey Zefirov sergu...@gmail.com wrote:
If the number of buckets was fixed, one could use an array of STRefs
to lists. I believe this would avoid the bug from Ticket #650?
now i see what you mean. no, i mean trivial transformation. #650 says
about slow GC.
On Tue, Dec 15, 2009 at 12:00 PM, Gregory Collins
g...@gregorycollins.net wrote:
Bulat Ziganshin bulat.zigans...@gmail.com writes:
now i see what you mean. no, i mean trivial transformation. #650 says
about slow GC. why it's slow? because once you made any update to the
array, the entire
now i see what you mean. no, i mean trivial transformation. #650 says
about slow GC. why it's slow? because once you made any update to the
array, the entire array is marked as updated and scanned on next minor GC
(which occurs after every 512 kbytes allocated, afaik). let's replace
big array
Serguey,
On Tue, Dec 15, 2009 at 1:07 PM, Serguey Zefirov sergu...@gmail.com wrote:
now i see what you mean. no, i mean trivial transformation. #650 says
about slow GC. why it's slow? because once you made any update to the
array, the entire array is marked as updated and scanned on next minor
What are peoples' thoughts on this?
http://hackage.haskell.org/trac/ghc/ticket/650#comment:16
Matt
On 12/14/09, Brad Larsen brad.lar...@gmail.com wrote:
Is anyone working on fixing ticket #650
http://hackage.haskell.org/trac/ghc/ticket/650? In short, STArray
and the garbage collector don't
Is anyone working on fixing ticket #650
http://hackage.haskell.org/trac/ghc/ticket/650? In short, STArray
and the garbage collector don't play well together, resulting in array
updates being non-constant time operations. This bug makes it very
difficult/impossible to write efficient array
brad.larsen:
Is anyone working on fixing ticket #650
http://hackage.haskell.org/trac/ghc/ticket/650? In short, STArray
and the garbage collector don't play well together, resulting in array
updates being non-constant time operations. This bug makes it very
difficult/impossible to write
Don,
On Mon, Dec 14, 2009 at 4:16 PM, Don Stewart d...@galois.com wrote:
brad.larsen:
Is anyone working on fixing ticket #650
http://hackage.haskell.org/trac/ghc/ticket/650? In short, STArray
and the garbage collector don't play well together, resulting in array
updates being non-constant
brad.larsen:
The vector package on haskell has boxed arrays. Is DPH *really* only
for primitive, unboxed types? If so, that's unfortunate.
No, it's not only, but all the uses I've seen have been related to
numerics, represented with unboxed types.
I'm just curious if you have a current use
On Mon, Dec 14, 2009 at 4:34 PM, Don Stewart d...@galois.com wrote:
brad.larsen:
The vector package on haskell has boxed arrays. Is DPH *really* only
for primitive, unboxed types? If so, that's unfortunate.
No, it's not only, but all the uses I've seen have been related to
numerics,
On 15/12/2009, at 06:53, Brad Larsen wrote:
On another note, does this (or perhaps better phrased, will this) bug
also affect Data Parallel Haskell?
Luckily, no. DPH represents arrays of user-defined types by unboxed arrays
(that's essentially what the vectoriser does). It does use boxed
Hello Brad,
Tuesday, December 15, 2009, 1:55:41 AM, you wrote:
How about a fast STHashTable?
you can use array of arrays instead of large array
--
Best regards,
Bulatmailto:bulat.zigans...@gmail.com
___
Haskell-Cafe
bulat.ziganshin:
Hello Brad,
Tuesday, December 15, 2009, 1:55:41 AM, you wrote:
How about a fast STHashTable?
you can use array of arrays instead of large array
Note to minmize the issue, but we get many of the same benefits via the
associated type transformation (e.g. for arrays of
32 matches
Mail list logo
