On Friday, 24 May 2013 at 15:17:00 UTC, Manu wrote:
> Errr, well, 1ms is about 7% of the frame, that's quite a long time.
> I'd be feeling pretty uneasy about any library that claimed to want 7% of
> the whole game time, and didn't offer any visual/gameplay benefits...
> Maybe if the GC happened to render some sweet water effects, or perform
> some awesome cloth physics or something while it was at it ;)
> I'd say 7% is too much for many developers.
>
> I think 2% sacrifice for simplifying memory management would probably get
> through without much argument.
> That's ~300µs... a few hundred microseconds seems reasonable. Maybe a
> little more if targeting 30fps.
> If it stuck to that strictly, I'd possibly even grant it permission to stop
> the world...
>

That is kind of biased, as you'll generally win on other aspects. You don't free anymore, you don't need to count reference (which can become qui te costly in multithreaded code), etc . . .

Generally, I think what is needed for games is a concurrent GC. This incurs a memory usage overhead (floating garbage), and a tax on pointers write, but eliminate pause.

That is a easy way to export a part of the load in another thread, improving concurrency in the application with little effort.

With real time constraint, a memory overhead is better than a pause.

> One important detail to consider for realtime usage, is that it's very
> unconventional to allocate at runtime at all...
> Perhaps a couple of short lived temp buffers each frame, and the occasional
> change in resources as you progress through a world (which are probably not
> allocated in GC memory anyway).
> Surely the relatively high temporal consistency of the heap across cycles
> can be leveraged here somehow to help?

That is good because it means not a lot of floating garbage.

Am 23.05.2013 20:13, schrieb Brad Anderson:
> While there hasn't been anything official, I think it's a safe bet to
> say that D is being used for a major title, Remedy's Quantum Break,
> featured prominently during the announcement of Xbox One. Quantum Break
> doesn't come out until 2014 so the timeline seems about right (Remedy
> doesn't appear to work on more than one game at a time from what I can
> tell).
>
>
> That's pretty huge news.
>
>
> Now I'm wondering what can be done to foster this newly acquired
> credibility in games.  By far the biggest issue I hear about when it
> comes to people working on games in D is the garbage collector.  You can
> work around the GC without too much difficulty as Manu's experience
> shared in his DConf talk shows but a lot of people new to D don't know
> how to do that.  We could also use some tools and guides to help people
> identify and avoid GC use when necessary.
>
> @nogc comes to mind (I believe Andrei mentioned it during one of the
> talks released). [1][2]
>
> Johannes Pfau's work in progress -vgc command line option [3] would be
> another great tool that would help people identify GC allocations.  This
> or something similar could also be used to document throughout phobos
> when GC allocations can happen (and help eliminate it where it makes
> sense to).
>
> There was a lot of interesting stuff in Benjamin Thaut's article about
> GC versus manual memory management in a game [4] and the discussion
> about it on the forums [5].  A lot of this collective knowledge built up
> on manual memory management techniques specific to D should probably be
> formalized and added to the official documentation.  There is a Memory
> Management [6] page in the documentation but it appears to be rather
> dated at this point and not particularly applicable to modern D2 (no
> mention of emplace or scoped and it talks about using delete and scope
> classes).
>
> Game development is one place D can really get a foothold but all too
> often the GC is held over D's head because people taking their first
> look at D don't know how to avoid using it and often don't realize you
> can avoid using it entirely. This is easily the most common issue raised
> by newcomers to D with a C or C++ background that I see in the #d IRC
> channel (many of which are interested in game dev but concerned the GC
> will kill their game's performance).
>
>
> 1: http://d.puremagic.com/issues/show_bug.cgi?id=5219
> 2: http://wiki.dlang.org/DIP18
> 3: https://github.com/D-Programming-Language/dmd/pull/1886
> 4: http://3d.benjamin-thaut.de/?p=20#more-20
> 5: http://forum.dlang.org/post/k27bh7$t7f$1@digitalmars.com
> 6: http://dlang.org/memory.html

Besides my studies I'm working at havok and the biggest problems most likely would be (in order of importance)

- Compiler / druntime for all 9 plattforms we have to support simply do not exist
- Full Visual Studio integration needed. Inclusive a really good code completion and a very nice debugging experience for all plattforms. VisualD is quite nice and debugging using the visual studio debugger works quite well but its a real pita that you have to patch dmd and compile it from source so you can debug in x64 on windows.
- SIMD: core.simd is just not there yet. The last time I looked really basic stuff like unaligned loads where missing.
- The GC. A no go, a GC free version of the runtime (non leaking) should be provided.
- Better windows support. All of the developement we do happens on windows and most of D's community does not care about windows support. I'm curious how long it will take until D will get propper DLL support.

Kind Regards
Benjamin Thaut

Am 24.05.2013 17:02, schrieb Manu:
> I might just add that there are some other important targets as well in
> the vein of this discussion.
>
> DLL's *still* don't work properly. druntime/phobos still don't really
> work as dll's.
> They are getting some attention, but it's been a really long standing
> and seriously major issue. Shared libraries are like, important!
>

Fully agree there. See
http://d.puremagic.com/issues/show_bug.cgi?id=9816

Kind Regards
Benjamin Thaut

On Fri, May 24, 2013 at 07:55:44PM +0200, deadalnix wrote:
> On Friday, 24 May 2013 at 15:17:00 UTC, Manu wrote:
> >Errr, well, 1ms is about 7% of the frame, that's quite a long time. I'd be feeling pretty uneasy about any library that claimed to want 7% of the whole game time, and didn't offer any visual/gameplay benefits...  Maybe if the GC happened to render some sweet water effects, or perform some awesome cloth physics or something while it was at it ;) I'd say 7% is too much for many developers.

OK.


> >I think 2% sacrifice for simplifying memory management would probably get through without much argument.  That's ~300µs... a few hundred microseconds seems reasonable.  Maybe a little more if targeting 30fps.  If it stuck to that strictly, I'd possibly even grant it permission to stop the world...

Makes sense. So basically some kind of incremental algorithm is in order.


> That is kind of biased, as you'll generally win on other aspects. You don't free anymore, you don't need to count reference (which can become qui te costly in multithreaded code), etc . . .
> 
> Generally, I think what is needed for games is a concurrent GC. This incurs a memory usage overhead (floating garbage), and a tax on pointers write, but eliminate pause.
> 
> That is a easy way to export a part of the load in another thread, improving concurrency in the application with little effort.

Wouldn't that require compiler support? Unless you're willing to forego nice slicing syntax and use custom types for all references / pointers.


> With real time constraint, a memory overhead is better than a pause.
> 
> >One important detail to consider for realtime usage, is that it's very unconventional to allocate at runtime at all...  Perhaps a couple of short lived temp buffers each frame, and the occasional change in resources as you progress through a world (which are probably not allocated in GC memory anyway).  Surely the relatively high temporal consistency of the heap across cycles can be leveraged here somehow to help?
> 
> That is good because it means not a lot of floating garbage.

Isn't the usual solution here to use a memory pool that gets deallocated in one shot at the end of the cycle? So during a frame, you'd create a pool, allocate all short-lived objects on it, and at the end free the entire pool in one shot (which could just be a no-op if you recycle the pool memory for the temp objects in the next frame). Long-lived objects, of course, will have to live in the heap, and since they usually aren't in GC memory anyway, it wouldn't matter.

A naïve, hackish implementation might be a function to reset all GC memory to a clean slate. So basically, you treat the entire GC memory as your pool, and you allocate at will during a single frame; then at the end of the frame, you reset the GC, which is equivalent to collecting every object from GC memory except it can probably be done much faster than a real collection cycle. Anything that needs to live past a single frame will have to be allocated via malloc/free. So this way, you don't need any collection cycle at all.

Of course, this may interact badly with certain language constructs: if any reference to GC objects lingers past a frame, you may break language guarantees (e.g. immutable array gets reused, violating immutability when you dereference the stale array pointer in the next frame). But if the per-frame code has no escaping GC references, this problem won't occur. Maybe if the per-frame code is marked pure? It doesn't work if you need to malloc/free, though (as those are inherently impure -- the pointers need to survive past the current frame). Can UDAs be used somehow to enforce no escaping GC references but allow non-GC references to persist past the frame?


T

-- 
People say I'm indecisive, but I'm not sure about that. -- YHL, CONLANG

On Sat, 25 May 2013 01:16:47 +1000
Manu <turkeyman@gmail.com> wrote:
> 
> Errr, well, 1ms is about 7% of the frame, that's quite a long time. I'd be feeling pretty uneasy about any library that claimed to want 7% of the whole game time, and didn't offer any visual/gameplay benefits... Maybe if the GC happened to render some sweet water effects, or perform some awesome cloth physics or something while it was at it ;)

Heh, I think that'd be nobel-prize territory. "Side Effect Oriented Developement" It'd be like old-school optimization, but maintains safety and developer sanity. :)

> 
> I think 2% sacrifice for simplifying memory management would probably
> get through without much argument.
> That's ~300µs... a few hundred microseconds seems reasonable. Maybe a
> little more if targeting 30fps.
> If it stuck to that strictly, I'd possibly even grant it permission
> to stop the world...
> 

Perhaps a naive idea, but Would running the GC in a fiber be a feasible approach? Every time the GC fiber is activated, it checks the time, and then has various points where it yields if the elapsed time passes a threshold value.

I see two problems though:

1. The state of GC-controlled heaps can change while the GC fiber is yieled. Don't know how much that could screw things up, or if the issue is even solvable.

2. Does a fiber context-switch take too long? If so, what about a stackless fiber? Ex: http://dunkels.com/adam/pt/

On Saturday, May 25, 2013 00:33:10 Manu wrote:
> Yeah, I've often wanted API's in that fashion too.
> I wonder if it would be worth creating overloads of allocating functions
> that receive an output buffer argument, rather than return an allocated
> buffer...
> Too messy?

We already have stuff like format vs formattedWrite where one allocates and the other takes an output range. We should adopt that practice in general. Where possible, it should probably be done with an overload of the function, but where that's not possible, we can simply create a new function with a similar name. Then any function which could allocate has the option of writing to an output range instead (which could be a delegate or an array or whatever) and avoid the allocation - though I'm not sure that arrays as output ranges currently handle running out of space very well, so we might need to figure something out there to properly deal with the case where there isn't enough room in the output range (arguably, output ranges need a bit of work in general though).

Regardless, the main question with regards to messiness is whether we can get away with creating overloads for existing functions which allocate or whether we'd be forced to create new ones (possibly using a naming scheme similar to how we have InPlace, only which indicates that it takes an output range or doesn't allocate or whatever).

- Jonathan M Davis

On 05/23/2013 03:21 PM, H. S. Teoh wrote:
> On Thu, May 23, 2013 at 10:15:50PM +0200, QAston wrote:
>> On Thursday, 23 May 2013 at 20:07:08 UTC, Steven Schveighoffer wrote:
>>> While I'm not specifically addressing the ability or not to disable the GC (I agree D has problems tehre), deprecating the delete operator does NOT preclude manual memory management.
>>>
>>> The problem with delete is it conflates destruction with deallocation.  Yes, when you deallocate, you want to destroy, but manual deallocation is a very dangerous operation.  Most of the time, you want to destroy WITHOUT deallocating (this is for cases where you are relying on the GC).
>>>
>>> Then I think Andrei also had a gripe that D had a whole keyword dedicated to an unsafe operation.
>>>
>>> You can still destroy and deallocate with destroy() and GC.free().
>>>
>>> -Steve
>>
>> Yes, I know the rationale behind deprecating delete and i agree with it. But from newcomer's point of view this looks misleading - not everyone has enough patience (or hatered towards c++) to lurk inside mailing lists and official website shows the deprecated way of doing things: http://dlang.org/memory.html . IMO manual memory management howto should be in a visible place - to dispell the myths language suffers from. Maybe even place in to the malloc-howto in Efficency paragraph of main website.
> 
> Please file a bug on the bugtracker to update memory.html to reflect current usage. Misleading (or outdated) documentation is often worse than no documentation.
> 
> 
> T
> 

Agreed, even if it's just a Warning Deprecated
it would be much better.

On Thursday, 23 May 2013 at 18:13:17 UTC, Brad Anderson wrote:
>
> @nogc comes to mind (I believe Andrei mentioned it during one of the talks released). [1][2]
>

I would love to have something like @nogc to guarantee there's no hidden or misplaced allocations in a section of code or optionally throughout the entire application.

Not only is the GC a cause of concern for game devs, it is also a concern for general systems development. For example I have a simple virtual network device driver that I'd like to re-write from C++ to D. It does not need a GC at all, all memory is preallocated in advance of use during initialization and it does not need anything from Phobos. If I could easily cut out the GC even from the executable binary that would be great, provided that I was certain that no allocations were going on by mistake. Yes I know I can get rid of the GC, but there should be an elegant solution for doing it that guarantees I am not using features of the language that require the GC.

Keep in mind that even if the GC was improved, there will still be plenty of systems applications that will not require the GC, so while improving the GC is a huge deal in itself, it is still not a general solution for those who do not need a GC at all and want to be certain they are not allocating by mistake.

--rt

On 25 May 2013 03:55, deadalnix <deadalnix@gmail.com> wrote:

> On Friday, 24 May 2013 at 15:17:00 UTC, Manu wrote:
>
>> Errr, well, 1ms is about 7% of the frame, that's quite a long time.
>> I'd be feeling pretty uneasy about any library that claimed to want 7% of
>> the whole game time, and didn't offer any visual/gameplay benefits...
>> Maybe if the GC happened to render some sweet water effects, or perform
>> some awesome cloth physics or something while it was at it ;)
>> I'd say 7% is too much for many developers.
>>
>> I think 2% sacrifice for simplifying memory management would probably get
>> through without much argument.
>> That's ~300µs... a few hundred microseconds seems reasonable. Maybe a
>> little more if targeting 30fps.
>> If it stuck to that strictly, I'd possibly even grant it permission to
>> stop
>> the world...
>>
>>
> That is kind of biased, as you'll generally win on other aspects. You don't free anymore, you don't need to count reference (which can become qui te costly in multithreaded code), etc . . .
>

Freeing is a no-realtime-cost operation, since memory management is usually
scheduled for between-scenes, or passed to other threads.
And I've never heard of a major title that uses smart pointers, and assigns
them around the place at runtime.
I'm accustomed to memory management having a virtually zero cost at runtime.
So I don't think it's biased at all (in the sense you say), I think I'm
being quite reasonable.

Generally, I think what is needed for games is a concurrent GC. This incurs
> a memory usage overhead (floating garbage), and a tax on pointers write,
> but eliminate pause.
>

How much floating garbage? This might be acceptable... I don't know enough about it.

That is a easy way to export a part of the load in another thread,
> improving concurrency in the application with little effort.
>

Are you saying a concurrent GC would operate exclusively in another thread? How does it scan the stack of all other threads?

With real time constraint, a memory overhead is better than a pause.


I wouldn't necessarily agree. Depends on the magnitude of each.
What sort of magnitude are we talking?
If you had 64mb of ram, and no virtual memory, would you be happy to
sacrifice 20% of it? 5% of it?

 One important detail to consider for realtime usage, is that it's very
>> unconventional to allocate at runtime at all...
>> Perhaps a couple of short lived temp buffers each frame, and the
>> occasional
>> change in resources as you progress through a world (which are probably
>> not
>> allocated in GC memory anyway).
>> Surely the relatively high temporal consistency of the heap across cycles
>> can be leveraged here somehow to help?
>>
>
> That is good because it means not a lot of floating garbage.
>

Right. But what's the overhead of a scan process (that's almost entirely
redundant work)?

On 25 May 2013 04:20, Benjamin Thaut <code@benjamin-thaut.de> wrote:

> Am 23.05.2013 20:13, schrieb Brad Anderson:
>
>> While there hasn't been anything official, I think it's a safe bet to
>>
>> say that D is being used for a major title, Remedy's Quantum Break, featured prominently during the announcement of Xbox One. Quantum Break doesn't come out until 2014 so the timeline seems about right (Remedy doesn't appear to work on more than one game at a time from what I can tell).
>>
>>
>> That's pretty huge news.
>>
>>
>> Now I'm wondering what can be done to foster this newly acquired credibility in games.  By far the biggest issue I hear about when it comes to people working on games in D is the garbage collector.  You can work around the GC without too much difficulty as Manu's experience shared in his DConf talk shows but a lot of people new to D don't know how to do that.  We could also use some tools and guides to help people identify and avoid GC use when necessary.
>>
>> @nogc comes to mind (I believe Andrei mentioned it during one of the
>> talks released). [1][2]
>>
>> Johannes Pfau's work in progress -vgc command line option [3] would be another great tool that would help people identify GC allocations.  This or something similar could also be used to document throughout phobos when GC allocations can happen (and help eliminate it where it makes sense to).
>>
>> There was a lot of interesting stuff in Benjamin Thaut's article about GC versus manual memory management in a game [4] and the discussion about it on the forums [5].  A lot of this collective knowledge built up on manual memory management techniques specific to D should probably be formalized and added to the official documentation.  There is a Memory Management [6] page in the documentation but it appears to be rather dated at this point and not particularly applicable to modern D2 (no mention of emplace or scoped and it talks about using delete and scope classes).
>>
>> Game development is one place D can really get a foothold but all too often the GC is held over D's head because people taking their first look at D don't know how to avoid using it and often don't realize you can avoid using it entirely. This is easily the most common issue raised by newcomers to D with a C or C++ background that I see in the #d IRC channel (many of which are interested in game dev but concerned the GC will kill their game's performance).
>>
>>
>> 1: http://d.puremagic.com/issues/**show_bug.cgi?id=5219<http://d.puremagic.com/issues/show_bug.cgi?id=5219>
>> 2: http://wiki.dlang.org/DIP18
>> 3: https://github.com/D-**Programming-Language/dmd/pull/**1886<https://github.com/D-Programming-Language/dmd/pull/1886>
>> 4: http://3d.benjamin-thaut.de/?**p=20#more-20<http://3d.benjamin-thaut.de/?p=20#more-20>
>> 5: http://forum.dlang.org/post/**k27bh7$t7f$1@digitalmars.com<http://forum.dlang.org/post/k27bh7$t7f$1@digitalmars.com>
>> 6: http://dlang.org/memory.html
>>
>
> Besides my studies I'm working at havok and the biggest problems most likely would be (in order of importance)
>
> - Compiler / druntime for all 9 plattforms we have to support simply do not exist
>

Yup.


> - Full Visual Studio integration needed. Inclusive a really good code completion and a very nice debugging experience for all plattforms. VisualD is quite nice and debugging using the visual studio debugger works quite well but its a real pita that you have to patch dmd and compile it from source so you can debug in x64 on windows.
>

Win64 works for me out of the box... ?


> - SIMD: core.simd is just not there yet. The last time I looked really basic stuff like unaligned loads where missing.
>

I'm working on std.simd (slowly >_<) .. It'll get there.


> - The GC. A no go, a GC free version of the runtime (non leaking) should
> be provided.
>

See, I have spend a decade on core tech/engine code meticulously worrying
about memory allocation. I don't think a GC is an outright no-go.
But we certainly don't have a GC that fits the bill.


> - Better windows support. All of the developement we do happens on windows and most of D's community does not care about windows support. I'm curious how long it will take until D will get propper DLL support.
>

As with everyone in games!
We need DLL's urgently.