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



--- Comment #110 from bearophile_hugs@eml.cc 2011-04-14 17:36:47 PDT ---
(In reply to comment #109)
> (In reply to comment #108)
> > That's why heap allocations in real-time code are a bad idea.  This patch won't change that.
> 
> Um, no, the GC is currently fast enough to scan a small heap within the timeframe of a video frame.

Do you have a proof of this? Because currently the GC gets called when you allocate heap memory. And allocating heap memory (for objects, structs, dynamic arrays, closures, array concatenations, etc) between two frames of a fast video game is probably not a wise thing to do (today) in D.

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

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



--- Comment #111 from Vladimir <thecybershadow@gmail.com> 2011-04-14 17:44:29 PDT ---
(In reply to comment #110)
> Because currently the GC gets called when you allocate heap memory.

Thanks for teaching me how garbage collectors work. I had no idea: http://thecybershadow.net/d/Memory_Management_in_the_D_Programming_Language.pdf

> probably not a wise thing to do

Empty words.

Yes, I ran tests and benchmarks. The D GC is okay as it is now. There are efforts to make it faster, and I welcome them by all means. However, precise heap scanning will not solve any of my problems.

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

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



--- Comment #112 from Walter Bright <bugzilla@digitalmars.com> 2011-04-14 17:48:22 PDT ---
(In reply to comment #110)
> And allocating heap memory (for objects, structs, dynamic
> arrays, closures, array concatenations, etc) between two frames of a fast video
> game is probably not a wise thing to do (today) in D.

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.

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

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



--- Comment #113 from Vladimir <thecybershadow@gmail.com> 2011-04-14 18:00:14 PDT ---
(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.

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

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



--- Comment #114 from David Simcha <dsimcha@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: -------

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



--- Comment #115 from Vladimir <thecybershadow@gmail.com> 2011-04-14 18:29:21 PDT ---
(In reply to comment #114)
> 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 .

Yes, I saw that (I believe I even complimented you on your work on one occasion). Frankly I'm skeptical regarding that guarantee until I'll be able to run some benchmarks, especially in my use cases (I store large objects outside the heap, see https://github.com/CyberShadow/data.d). But even if it holds, I would like to ask to make it easy to turn off the generation of any additional information these GC changes require in the compiler (such as a #define option), so I can easily switch to a custom GC optimized for speed and nothing else.

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

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



--- Comment #116 from Rob Jacques <sandford@jhu.edu> 2011-04-14 19:00:38 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.

Yes, they do. It's called the frame rate. (Though I'd guess to be technical, this a soft-realtime requirement.)

> 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.

Why do you think the GC will get slower? One of the major points of a precise GC is that it does less total work than a conservative GC. Why? Because following a pointer, even if it goes nowhere, is an expensive operation (I'd guess O(log Heap_Size)) to say nothing of the cost of keeping around and tracing the excess garbage. And the more precision the GC has, the less pointers it has to trace per unit memory and the total memory traced is reduced as well. So it's win-win.

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

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



--- Comment #117 from Vladimir <thecybershadow@gmail.com> 2011-04-14 19:06:29 PDT ---
(In reply to comment #116)
> Yes, they do. It's called the frame rate. (Though I'd guess to be technical, this a soft-realtime requirement.)

That's exactly what I meant. Hard realtime means that missing a deadline is equivalent to a complete system failure. Heap allocation is indeed not an option in that case.

> Why do you think the GC will get slower? One of the major points of a precise GC is that it does less total work than a conservative GC. Why? Because following a pointer, even if it goes nowhere, is an expensive operation (I'd guess O(log Heap_Size)) to say nothing of the cost of keeping around and tracing the excess garbage. And the more precision the GC has, the less pointers it has to trace per unit memory and the total memory traced is reduced as well. So it's win-win.

I hope it is as you say it is, but without benchmarks it's hard to say anything, and this talk of state machines etc. is disconcerting. Note that the current GC does a quick check for each possible pointer if it's between the low and high address range of all GC pages - for small heaps, this weeds out most false pointers.

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

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



--- Comment #118 from Walter Bright <bugzilla@digitalmars.com> 2011-04-14 19:34:40 PDT ---
(In reply to comment #117)
> I hope it is as you say it is, but without benchmarks it's hard to say anything, and this talk of state machines etc. is disconcerting.

Why?

Also, even if the compiler emits the tables necessary for more precise gc, the gc implementation can ignore them and do it the old way. Emitting the tables makes it possible for people to experiment with various kinds of gc strategies.

> Note that the
> current GC does a quick check for each possible pointer if it's between the low
> and high address range of all GC pages - for small heaps, this weeds out most
> false pointers.

True, and it works tolerably well. To do a moving gc, however, you need more precise information.

BTW, I just want to reiterate that a "hard" realtime constraint means your program fails if it doesn't meet it. A "soft" constraint means the program degrades in some way, but keeps functioning.

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

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



--- Comment #119 from David Simcha <dsimcha@yahoo.com> 2011-04-14 19:47:44 PDT ---
(In reply to comment #118)
> Also, even if the compiler emits the tables necessary for more precise gc, the gc implementation can ignore them and do it the old way. Emitting the tables makes it possible for people to experiment with various kinds of gc strategies.

I still think that, instead of hard coding this logic into the compiler, we should make TypeInfo templated.  (See DIP 8 from ages ago, http://www.wikiservice.at/d/wiki.cgi?LanguageDevel/DIPs/DIP8).  This would allow different runtime implementations to customize how the pointer offset info works without modifying the compiler.  It would also make typeinfo extensible, which is generally a good thing.

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