On 2010-03-06 12:42 + (Sat), Simon Marlow wrote:
Usually I find keeping the nursery size (-A) close to the L2 cache size
works best, although sometimes making it really big can be even better.
Interesting to know. I got the impression that I was being encouraged to
keep -A closer to the
On 06/03/10 06:56, Simon Cranshaw wrote:
For settings we are using -N7 -A8m -qg.
I'm surprised if turning off parallel GC improves things, unless you
really aren't using all the cores (ThreadScope will tell you that).
Do these flags give you an improvement in throughput, or just pause
On 04/03/2010 09:14, Curt Sampson wrote:
However: now that Simon's spent a bunch of time experimenting with the
runtime's GC settings and found a set that's mitigated much of our
problem, other things are pushing their way up my priority list. Between
that and an upcoming holiday, I'm probably
On 05/03/2010 05:03, wren ng thornton wrote:
Simon Marlow wrote:
So it would be pretty easy to provide something like
disableMajorGC, enableMajorGC :: IO ()
Of course leaving it disabled too long could be bad, but that's your
responsibility.
It seems like it'd be preferable to have an
For settings we are using -N7 -A8m -qg.
I don't know if they are really the optimal values but I haven't found a
significant improvement on these yet. I tried -qb but that was slow. I
tried larger values of A but that didn't seem to make a big difference. Also
-N6 didn't make much difference.
On 2010-03-02 14:17 + (Tue), Simon Marlow wrote:
System.Mem.performGC is your friend, but if you're unlucky it might do a
major GC and then you'll get more pause than you bargained for.
Anybody calling that is a really poor unlucky sod, because, as far as I
can tell from reading the
A fully concurrent GC running on multiple threads/cores might be
great, but I guess this is difficult to implement and introduces a lot
of overhead.
For simple video games, it might work to always do a full GC per
frame, but don't allow it to take more than T milliseconds. In a sense
the GC
Simon Marlow wrote:
So it would be pretty easy to provide something like
disableMajorGC, enableMajorGC :: IO ()
Of course leaving it disabled too long could be bad, but that's your
responsibility.
It seems like it'd be preferable to have an interface like:
withMajorGCDisabled :: IO()
On 2 Mar 2010, at 21:38, Simon Marlow wrote:
On 02/03/10 20:37, Luke Palmer wrote:
On Tue, Mar 2, 2010 at 7:17 AM, Simon Marlowmarlo...@gmail.com
wrote:
For games,
though, we have a very good point that occurs regularly where we
know
that all/most short-lived objects will no longer be
On 03/03/2010 08:43, Neil Davies wrote:
On 2 Mar 2010, at 21:38, Simon Marlow wrote:
On 02/03/10 20:37, Luke Palmer wrote:
On Tue, Mar 2, 2010 at 7:17 AM, Simon Marlowmarlo...@gmail.com wrote:
For games,
though, we have a very good point that occurs regularly where we know
that all/most
On 01/03/2010 00:04, Luke Palmer wrote:
On Sun, Feb 28, 2010 at 2:06 AM, Pavel Perikovperi...@gmail.com 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?
On 01/03/2010 14:16, Sönke Hahn wrote:
On Monday 01 March 2010 01:04:37 am Luke Palmer wrote:
On Sun, Feb 28, 2010 at 2:06 AM, Pavel Perikovperi...@gmail.com wrote:
Did you really seen 100ms pauses?! I never did extensive research on this
but my numbers are rather in microseconds range (below
On 01/03/2010 14:53, Thomas Schilling wrote:
On 28 February 2010 05:20, Luke Palmerlrpal...@gmail.com wrote:
I have seen some proposals around here for SoC projects and other
things to try to improve the latency of GHC's garbage collector. I'm
currently developing a game in Haskell, and even
Both concurrent GC and incremental GC tend to add overheads to the
mutator, because they need a read barrier. There was an incremental
GC for GHC once [1], taking advantage of the built-in read barrier
that we have whereby most closures are entered
Was there a specific reason why that GC
On 01/03/2010 17:16, Sebastian Sylvan wrote:
On Sun, Feb 28, 2010 at 5:20 AM, Luke Palmer lrpal...@gmail.com
mailto:lrpal...@gmail.com wrote:
I have seen some proposals around here for SoC projects and other
things to try to improve the latency of GHC's garbage collector. I'm
On 02/03/2010 14:11, Malcolm Wallace wrote:
Both concurrent GC and incremental GC tend to add overheads to the
mutator, because they need a read barrier. There was an incremental GC
for GHC once [1], taking advantage of the built-in read barrier that
we have whereby most closures are entered
On Tue, Mar 2, 2010 at 7:17 AM, Simon Marlow marlo...@gmail.com wrote:
For games,
though, we have a very good point that occurs regularly where we know
that all/most short-lived objects will no longer be referenced - at the
start of a fresh frame.
System.Mem.performGC is your friend, but if
On 02/03/10 20:37, Luke Palmer wrote:
On Tue, Mar 2, 2010 at 7:17 AM, Simon Marlowmarlo...@gmail.com wrote:
For games,
though, we have a very good point that occurs regularly where we know
that all/most short-lived objects will no longer be referenced - at the
start of a fresh frame.
Luke Palmer wrote:
I have seen some proposals around here for SoC projects and other
things to try to improve the latency of GHC's garbage collector. I'm
currently developing a game in Haskell, and even 100ms pauses are
unacceptable for a real-time game. I'm calling out to people who have
On Sun, Feb 28, 2010 at 10:03 AM, Heinrich Apfelmus
apfel...@quantentunnel.de wrote:
Luke Palmer wrote:
I have seen some proposals around here for SoC projects and other
things to try to improve the latency of GHC's garbage collector. I'm
currently developing a game in Haskell, and even 100ms
20 matches
Mail list logo
