dsimcha:
I'm at my traditional passtime of trying to speed up D's garbage
collector again,
Are you going to create a pull request soon? So people will be able to try it
with their D programs and spot potential troubles...
Bye,
bearophile
On Dec 4, 2011, at 5:46 PM, dsimcha wrote:
I'm at my traditional passtime of trying to speed up D's garbage collector
again, and I've stumbled on the fact that rt_finalize is taking up a
ridiculous share of the time (~30% of total runtime) on a benchmark where
huge numbers of classes
I have an updated and win32-compilable version of CDGC in a branch. It's
missing some features from the current GC though (it's based on the Tango GC
which has remained relatively static for the past years while druntime's GC has
improved).
Sent from my iPhone
On Dec 5, 2011, at 3:39 PM,
Last time I looked at it, the try/catch/finally block was rather
expensive because it always invokes the exception handler unwinding
mechanism, even if no exception occurs.
Try moving the try/catch block out of the loops that call rt_finalize.
(maybe just remove it, onFinalizeError just
On Mon, 05 Dec 2011 10:14:00 +0200, Rainer Schuetze r.sagita...@gmx.de
wrote:
Try moving the try/catch block out of the loops that call rt_finalize.
This sounds like a good idea. Just make sure that all code paths that lead
to rt_finalize (e.g. delete) can recover from an exception.
On Sun, 04 Dec 2011 20:46:27 -0500, dsimcha dsim...@yahoo.com wrote:
I'm at my traditional passtime of trying to speed up D's garbage
collector again, and I've stumbled on the fact that rt_finalize is
taking up a ridiculous share of the time (~30% of total runtime) on a
benchmark where
On Mon, 05 Dec 2011 09:14:00 +0100, Rainer Schuetze r.sagita...@gmx.de
wrote:
Last time I looked at it, the try/catch/finally block was rather
expensive because it always invokes the exception handler unwinding
mechanism, even if no exception occurs.
Try moving the try/catch block out of
== Quote from Martin Nowak (d...@dawgfoto.de)'s article
I appreciate the recursion during mark, wanted to do this myself
sometime ago but expected a little more gain.
The reason the gain wasn't huge is because on the benchmark I have that
involves a
deep heap graph, sweeping time dominates
On 05/12/2011 01:46, dsimcha wrote:
I'm at my traditional passtime of trying to speed up D's garbage
collector again
Have you thought about pushing for the inclusion of CDGC at all/working
on the tweaks needed to make it the main GC?
--
Robert
http://octarineparrot.com/
On Mon, 05 Dec 2011 22:07:09 +0100, dsimcha dsim...@yahoo.com wrote:
== Quote from Martin Nowak (d...@dawgfoto.de)'s article
I appreciate the recursion during mark, wanted to do this myself
sometime ago but expected a little more gain.
The reason the gain wasn't huge is because on the
On Mon, 05 Dec 2011 23:07:09 +0200, dsimcha dsim...@yahoo.com wrote:
I understand the problem, but please elaborate on the proposed
solution. You've
basically got a bunch of pools, each of which represents a range of
memory
addresses, not a single address (so a basic hashtable is out). You
On 5 December 2011 22:34, Martin Nowak d...@dawgfoto.de wrote:
We currently add something from etext to _end (rt.memory) as static root.
This probably contains read-only sections, data from other languages
and (unlikely) other unrelated sections.
I think some help from the compiler will be
More promising is to put pool addresses ranges in a trie.
addr[7] [... . ...]
/ |\
addr[6] [... . ...][... . ...]
/ |\ / | \
addr[5] pool:8 [... . ...]
== Quote from Martin Nowak (d...@dawgfoto.de)'s article
More promising is to put pool addresses ranges in a trie.
addr[7] [... . ...]
/ |\
addr[6] [... . ...][... . ...]
/ |\ / | \
On 05/12/2011 01:46, dsimcha wrote:
I'm at my traditional passtime of trying to speed up D's garbage
collector again
Have you thought about pushing for the inclusion of CDGC at all/working
on the tweaks needed to make it the main GC?
So true, it's been rotting in that branch.
On 12/5/2011 6:39 PM, Trass3r wrote:
On 05/12/2011 01:46, dsimcha wrote:
I'm at my traditional passtime of trying to speed up D's garbage
collector again
Have you thought about pushing for the inclusion of CDGC at
all/working on the tweaks needed to make it the main GC?
So true, it's been
On Tue, 06 Dec 2011 00:16:01 +0100, dsimcha dsim...@yahoo.com wrote:
== Quote from Martin Nowak (d...@dawgfoto.de)'s article
More promising is to put pool addresses ranges in a trie.
addr[7] [... . ...]
/ |\
addr[6] [... . ...]
IIRC CDGC includes two major enhancements:
1. The snapshot GC for Linux. (Does this work on OSX/FreeBSD/anything
Posix, or just Linux? I'm a bit skeptical about whether a snapshot GC
is really that great an idea given its propensity to waste memory on
long collect cycles with a lot of
On 2011-12-05 23:45, Iain Buclaw wrote:
On 5 December 2011 22:34, Martin Nowakd...@dawgfoto.de wrote:
We currently add something from etext to _end (rt.memory) as static root.
This probably contains read-only sections, data from other languages
and (unlikely) other unrelated sections.
I think
I'm at my traditional passtime of trying to speed up D's garbage
collector again, and I've stumbled on the fact that rt_finalize is
taking up a ridiculous share of the time (~30% of total runtime) on a
benchmark where huge numbers of classes **that don't have destructors**
are being created
On Mon, 05 Dec 2011 02:46:27 +0100, dsimcha dsim...@yahoo.com wrote:
I'm at my traditional passtime of trying to speed up D's garbage
collector again, and I've stumbled on the fact that rt_finalize is
taking up a ridiculous share of the time (~30% of total runtime) on a
benchmark where
dsimcha:
I've stumbled on the fact that rt_finalize is
taking up a ridiculous share of the time (~30% of total runtime) on a
benchmark where huge numbers of classes **that don't have destructors**
are being created and collected.
DMD or LDC/GDC compiler?
extern (C) void
Thanks for the benchmark. I ended up deciding to just create a second
function, rt_finalize_gc, that gets rid of a whole bunch of cruft that
isn't necessary in the GC case. I think it's worth the small amount of
code duplication it creates. Here are the results of my efforts so far:
23 matches
Mail list logo
