Am 30.09.2014 16:28, schrieb Szymon Gatner:
> On Tuesday, 30 September 2014 at 14:19:51 UTC, Araq wrote:
>>> It doesn't mention anything about moving C++ into C#.
>>> Even with IL2CPP, C# has fundamental design trade offs that make it
>>> slower than C++(GC is just one of them), so it wouldn't make much
>>> sense to port engine code to C# unless they wanted it to run slower.
>>
>> What are these fundamental design trade offs?
>
> Guys I beg you, is there any chance I will get my answers? ;)


Sorry got carried away. Ola and others know better.

On Tuesday, 30 September 2014 at 08:48:19 UTC, Szymon Gatner wrote:
> Considered how many games (and I don't mean indie anymore, but for example Blizzard's Heartstone) are now created in Unity which uses not only GC but runs in Mono I am very skeptical of anybody claiming GC is a no-go for games. - Especially- that native executable is being built in case of D.
>
> I realize AAA's have have their reasons against GC i but in that case one should probably just get UE4 license anyway.

Hello. AAA developer (Remedy) here using D. Custom tech, with a custom binding solution written originally by Manu and continued by myself.

A GC itself is not a bad thing. The implementation, however, is.

With a codebase like ours (mostly C++, some D), there's a few things we need. Deterministic garbage collection is a big one - when our C++ object is being destroyed, we need the D object to be destroyed at the same time in most cases. This can be handled by calling GC.collect() often, but that's where the next thing comes in - the time the GC needs. If the time isn't being scheduled at object destruction, then it all gets lumped together in the GC collect. It automatically moves the time cost to a place where we may not want it.

ARC garbage collection would certainly be beneficial there. I looked in to adding support at a language level and at a library level for it, but the time it would have taken for me to learn both of those well enough to not muck it up is not feasible. Writing a garbage collector that we have greater control over will also take up too much time. The simpler solution is to enforce coding standards that avoid triggering the GC.

It's something I will look at again in the future, to be sure. And also to be sure, nothing is being done in Unity to the scale we do stuff in our engine (at least, nothing in Unity that also doesn't use a ton of native code to bypass Unity's limitations).

On Tuesday, 30 September 2014 at 21:19:44 UTC, Ethan wrote:
>
> With a codebase like ours (mostly C++, some D), there's a few things we need. Deterministic garbage collection is a big one - when our C++ object is being destroyed, we need the D object to be destroyed at the same time in most cases. This can be handled by calling GC.collect() often, but that's where the next thing comes in - the time the GC needs. If the time isn't being scheduled at object destruction, then it all gets lumped together in the GC collect. It automatically moves the time cost to a place where we may not want it.

Would delete on the D side work here?  Or the more current
destroy()?  ie. is release of the memory a crucial part of the
equation, or merely finalization?

On Tuesday, 30 September 2014 at 21:19:44 UTC, Ethan wrote:
>
> Hello. AAA developer (Remedy) here using D. Custom tech, with a custom binding solution written originally by Manu and continued by myself.
>
> A GC itself is not a bad thing. The implementation, however, is.
>
> With a codebase like ours (mostly C++, some D), there's a few things we need. Deterministic garbage collection is a big one - when our C++ object is being destroyed, we need the D object to be destroyed at the same time in most cases. This can be handled by calling GC.collect() often, but that's where the next thing comes in - the time the GC needs. If the time isn't being scheduled at object destruction, then it all gets lumped together in the GC collect. It automatically moves the time cost to a place where we may not want it.

Not a GC specialist here, so maybe the thought arises - why not
turn off automatic GC until such times in the code where you can
afford the cost of it, then call GC.collect explicitly -
essentially eliminating the opportunity for the GC to run at
random times and force running at deterministic times?  Is memory
usage so constrained that failing to execute runs in-between
those deterministic blocks could lead to OOM?  Does such a
strategy have other nasty side-effects which make it impractical?

On Tuesday, 30 September 2014 at 21:19:44 UTC, Ethan wrote:
> On Tuesday, 30 September 2014 at 08:48:19 UTC, Szymon Gatner wrote:
>> Considered how many games (and I don't mean indie anymore, but for example Blizzard's Heartstone) are now created in Unity which uses not only GC but runs in Mono I am very skeptical of anybody claiming GC is a no-go for games. - Especially- that native executable is being built in case of D.
>>
>> I realize AAA's have have their reasons against GC i but in that case one should probably just get UE4 license anyway.
>
> Hello. AAA developer (Remedy) here using D. Custom tech, with a custom binding solution written originally by Manu and continued by myself.
>
> A GC itself is not a bad thing. The implementation, however, is.
>
> With a codebase like ours (mostly C++, some D), there's a few things we need. Deterministic garbage collection is a big one - when our C++ object is being destroyed, we need the D object to be destroyed at the same time in most cases. This can be handled by calling GC.collect() often, but that's where the next thing comes in - the time the GC needs. If the time isn't being scheduled at object destruction, then it all gets lumped together in the GC collect. It automatically moves the time cost to a place where we may not want it.
>
> ARC garbage collection would certainly be beneficial there. I looked in to adding support at a language level and at a library level for it, but the time it would have taken for me to learn both of those well enough to not muck it up is not feasible. Writing a garbage collector that we have greater control over will also take up too much time. The simpler solution is to enforce coding standards that avoid triggering the GC.
>
> It's something I will look at again in the future, to be sure. And also to be sure, nothing is being done in Unity to the scale we do stuff in our engine (at least, nothing in Unity that also doesn't use a ton of native code to bypass Unity's limitations).

GC.free() can be used to manually delete GC-allocated data. (destroy() must be called first to call te destructor, though) - delete does both but is deprecated. You could write a simple RAII pointer wrapper if you don't want to always call destroy()+GC.free() manually.

Or do you need something else?

On Tuesday, 30 September 2014 at 21:19:44 UTC, Ethan wrote:
> On Tuesday, 30 September 2014 at 08:48:19 UTC, Szymon Gatner wrote:
>> Considered how many games (and I don't mean indie anymore, but for example Blizzard's Heartstone) are now created in Unity which uses not only GC but runs in Mono I am very skeptical of anybody claiming GC is a no-go for games. - Especially- that native executable is being built in case of D.
>>
>> I realize AAA's have have their reasons against GC i but in that case one should probably just get UE4 license anyway.
>
> Hello. AAA developer (Remedy) here using D. Custom tech, with a custom binding solution written originally by Manu and continued by myself.
>
> A GC itself is not a bad thing. The implementation, however, is.
>
> With a codebase like ours (mostly C++, some D), there's a few things we need. Deterministic garbage collection is a big one - when our C++ object is being destroyed, we need the D object to be destroyed at the same time in most cases. This can be handled by calling GC.collect() often, but that's where the next thing comes in - the time the GC needs. If the time isn't being scheduled at object destruction, then it all gets lumped together in the GC collect. It automatically moves the time cost to a place where we may not want it.
>
> ARC garbage collection would certainly be beneficial there. I looked in to adding support at a language level and at a library level for it, but the time it would have taken for me to learn both of those well enough to not muck it up is not feasible. Writing a garbage collector that we have greater control over will also take up too much time. The simpler solution is to enforce coding standards that avoid triggering the GC.
>
> It's something I will look at again in the future, to be sure. And also to be sure, nothing is being done in Unity to the scale we do stuff in our engine (at least, nothing in Unity that also doesn't use a ton of native code to bypass Unity's limitations).

Thanks for the feedback, quite interesting.

On Tuesday, 30 September 2014 at 23:31:36 UTC, Cliff wrote:
> Not a GC specialist here, so maybe the thought arises - why not
> turn off automatic GC until such times in the code where you can
> afford the cost of it, then call GC.collect explicitly -
> essentially eliminating the opportunity for the GC to run at
> random times and force running at deterministic times?  Is memory
> usage so constrained that failing to execute runs in-between
> those deterministic blocks could lead to OOM?  Does such a
> strategy have other nasty side-effects which make it impractical?

The latter. If you want a game to run at 60 fps, you have about 16 ms for each frame, during which time you need to make all the necessary game and graphics updates. There's no upper to limit to the amount of time a GC run can take, so it can easily exceed the few ms you have left for it.

There are however GC algorithms that support incremental collection, meaning that you can give the GC a deadline. If it can't finish before this deadline, it will have to interrupt its work and continue on the next run. Unfortunately, these GCs usually require special compiler support (barriers, and distinguishing GC from non-GC pointers), which we don't have. But there is CDGC writte by Leandro Lucarella for D1, which uses a forking to achieve the same effect, and which Dicebot is currently porting to D2:
http://forum.dlang.org/thread/exfrifcfczgjwkudqdgx@forum.dlang.org

On Tuesday, 30 September 2014 at 22:32:26 UTC, Sean Kelly wrote:
>
> Would delete on the D side work here?  Or the more current
> destroy()?  ie. is release of the memory a crucial part of the
> equation, or merely finalization?

Destruction of an object is *far* more important than releasing
memory. Our D code's memory usage is drops in an ocean, but it
can potentially hold on to resources that need to be destroyed in
special ways depending on middleware/threading usage.

Object.destroy() would do the job, but there's also a
fragmentation problem that creeps in to a GC solution like the
default D implementation the longer you have your application
running. We already encounter plenty of cache-incoherent code in
other areas of the codebase, and since one of my roles is to
evangelise D (so to speak) I'm aiming to keep it running fast and
avoiding as many stalls as possible. If I avoid the current
implementation's garbage collection, then memory allocated stays
in roughly the same region (some work that I did manage to do and
intend on submitting a pull request for allows a user to specify
a custom set of allocation functions, so all memory from core and
phobos goes through our supplied memory allocator).

Either way, it still comes down to a function call to free your
object which means you're stepping outside of the way the GC
natively does things.

"Chris" <wendlec@tcd.ie> writes:
>
> iOS/ARM are very important. What's the latest state of affairs? I know some progress has been made but it has been off my radar for a month or two now.

The iOS project with LDC has been idle during the windsurfing season :-).  Days are geting shorter so I plan to  resume work on it.

For a start, it needs to be updated to latest LDC version.  About 10 phobos unit tests were not passing back in April and most of these were due to floating pointing differences between host (x64) and target (arm).
-- 
dano

On 09/30/2014 04:48 AM, Szymon Gatner wrote:
> On Monday, 29 September 2014 at 20:15:06 UTC, bachmeier wrote:
>> On Monday, 29 September 2014 at 10:00:27 UTC, Szymon Gatner wrote:
>>
>>
>> Is that all it would take? Do you also need a GC-free standard
>> library, which seems to be the need of all the others saying "do this
>> and I'll switch from C++"? Are the tools good enough?
>
> Considered how many games (and I don't mean indie anymore, but for
> example Blizzard's Heartstone) are now created in Unity which uses not
> only GC but runs in Mono I am very skeptical of anybody claiming GC is a
> no-go for games.

The whole "Unity3D == Mono" thing is a somewhat inaccurate misconception.

Unity3D's engine (ie, the real workhorse of any Unity3D game) is written in plain old native C++. So not *necessarily* GC (though they might still use one internally, I wouldn't know).

Only the game-specific scripts (and I *think* the Unity3D Editor) actually run on Mono. And even then, the game scripts *are* able to call into C-linkage stuff, which *is* occasionally done to work around performance issues within game scripts.

Also, I imagine Mono's GC is probably quite a bit better than D's currently is.