Re: [Haskell-cafe] Real-time garbage collection for Haskell

John, I suspect speed is more important than timing. In practice I don't mind a pause for a gc when nothing is happening in the market. It's when the market is moving fast that we particularly want to keep our response time low. Busy times may continue for long periods though and I'm not sure if being able to defer gc (if that's what you're suggesting) would be possible for that long. We are still studying how the gc times are interacting with our response times and so hopefully I will have a better answer to this later on. Simon On Tue, Mar 2, 2010 at 2:06 PM, John Van Enk wrote:

Simon,

Would a more predictable GC or a faster GC be better in your case? (Of course, both would be nice.)

/jve

On Mon, Mar 1, 2010 at 9:33 PM, Simon Cranshaw wrote:

...

On Sun, Feb 28, 2010 at 6:06 PM, Pavel Perikov wrote:

...

Did you really seen 100ms pauses?! I never did extensive research on this but my numbers are rather in microseconds range (below 1ms). What causes such a long garbage collection? Lots of allocated and long-living objects?

I am using an automated options trading system written in Haskell. I'm more on the business side than the technical side of the issues so I'm not clear on all the details. I can confirm that without tweaking the RTS settings we were seeing over 100ms GC pauses. I've mainly been trying to minimise our overall response time and we were able to improve this by increasing the allocation area with -A. I think this brought GC well under 100ms. We are still working on analysis of this.

I can also confirm, as others seem to have found, that under 6.12 the parallel GC seemed to make things much worse. I am always turning it off with -qg. If there is a project to improve performance of the GC I could be interested to contribute.

Simon Cranshaw

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe