[Issue 3463] Integrate Precise Heap Scanning Into the GC

d-bugmail at puremagic.com d-bugmail at puremagic.com
Thu Apr 14 18:26:50 PDT 2011


http://d.puremagic.com/issues/show_bug.cgi?id=3463



--- Comment #114 from David Simcha <dsimcha at yahoo.com> 2011-04-14 18:23:13 PDT ---
(In reply to comment #113)
> (In reply to comment #112)
> > Anything with hard realtime requirements cannot do allocation - even in C/C++,
> > malloc() does not have an upper limit on its time.
> > 
> > What is done is to pre-allocate everything necessary before entering the hard
> > realtime section.
> 
> This does not apply to the discussion. Video games do not have hard-realtime
> requirements.
> 
> Garbage collection speed dictates how much work must the programmer do to
> offset the GC's slowness. If the GC is fast enough that it does not cause
> performance issues on systems satisfying the game's minimum system
> requirements, the programmer doesn't need to care about it at all. Otherwise,
> they must do some work (the slower the GC, the more work) to reduce the size of
> the heap, or the number of allocations, or ultimately abandon heap allocation
> entirely. This might be easy in simple video games, but becomes increasingly
> painful in very large projects, with non-trivial user interfaces etc.
> 
> So, by making the GC slower, you are creating more work for me. I am not happy
> about it.

How about this:  I can virtually guarantee that any slowness caused by precise
heap scanning is more than offset by my recent patches (in Git but not in any
DMD release yet).  See
https://github.com/dsimcha/druntime/wiki/Druntime-GC-Optimization-Fork .

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------


More information about the Digitalmars-d-bugs mailing list