Hi Ben,
My guess would be that you're running into some kind of memory
bottleneck. Three common ones are:
(1) total memory bandwidth
(2) cache ping-ponging
(3) NUMA overheads
You would run into (1) if you were using an allocation area size (-A or
-H) larger than the L2 cache. Your
Hi Ben,
I would bet on the same memory issues Simon mentioned. But... while you're
at it would you mind trying a little experiment to share your work items
through a lockfree queue rather than a TQueue?
http://hackage.haskell.org/package/lockfree-queue
Under some situations this can yield
Simon Marlow marlo...@gmail.com writes:
On 28/09/12 17:36, Ben Gamari wrote:
Unfortunately, after poking around I found a few obvious problems with
both the code and my testing configuration which explained the
performance drop. Things seem to be back to normal now. Sorry for the
noise!
On 26/09/2012 05:42, Ben Gamari wrote:
Simon Marlow marlo...@gmail.com writes:
On 21/09/2012 04:07, John Lato wrote:
Yes, that's my current understanding. I see this with ByteString and
Data.Vector.Storable, but not
Data.Vector/Data.Vector.Unboxed/Data.Text. As ByteStrings are pretty
widely
Simon Marlow marlo...@gmail.com writes:
On 21/09/2012 04:07, John Lato wrote:
Yes, that's my current understanding. I see this with ByteString and
Data.Vector.Storable, but not
Data.Vector/Data.Vector.Unboxed/Data.Text. As ByteStrings are pretty
widely used for IO, I expected that somebody
On 21/09/2012 04:07, John Lato wrote:
Yes, that's my current understanding. I see this with ByteString and
Data.Vector.Storable, but not
Data.Vector/Data.Vector.Unboxed/Data.Text. As ByteStrings are pretty
widely used for IO, I expected that somebody else would have
experienced this too.
I
Hello,
We've noticed that some applications exhibit significantly worse
memory usage when compiled with ghc-7.6.1 compared to ghc-7.4, leading
to out of memory errors in some cases. Running one app with +RTS -s,
I see this:
ghc-7.4
525,451,699,736 bytes allocated in the heap
53,404,833,048
So the problem is only with the data structures on the heap that are pinned
in place to play nice with C?
I'd be curious to understand the change too, though per se pinned memory (a
la storable or or bytestring) will by definition cause memory fragmentation
in a gc'd lang as a rule, (or at least
Yes, that's my current understanding. I see this with ByteString and
Data.Vector.Storable, but not
Data.Vector/Data.Vector.Unboxed/Data.Text. As ByteStrings are pretty
widely used for IO, I expected that somebody else would have
experienced this too.
I would expect some memory fragmentation
