Idea #1 on integrating RC with GC

Xavier Bigand flamaros.xavier at gmail.com
Mon Feb 10 14:56:24 PST 2014


Le 10/02/2014 09:58, Manu a écrit :
> On 10 February 2014 17:58, francesco cattoglio
> <francesco.cattoglio at gmail.com <mailto:francesco.cattoglio at gmail.com>>
> wrote:
>
>     On Monday, 10 February 2014 at 04:26:10 UTC, Manu wrote:
>
>         Sorry, I obviously mean, "the only *games* company..."
>
>     That was a given. However I think AAA titles have the manpower to
>     avoid those pauses, since the amount of work toward optimization is
>     huge anyway, am I right? Ofc you still need minimal backend from the
>     compiler and runtime support. If you lack control on internals,
>     there's no way for you to optimize anything.
>
>
> If we wanted to spend that time+manpower (read, money & overtime/sanity)
> on bullshit like that, we have no reason to adopt D; we already have
> C/C++, and we already have decades of experience mitigating that nightmare.
> The point is, we are REALLY sick of it. Why would we sign up to replace
> it with more of the same thing.
>
>         And people seem to forget promptly after every single time I
>         repeat myself:
>           * The GC frequency of execution is directly proportional to
>         the amount of
>         _free memory_. In console games; NONE.
>           * The length of the associated pause is directly proportional
>         to the
>         amount of memory currently in use. In console games; all of it.
>
>     For "simple" games, it would be nice to have a better GC and cut
>     down allocations from the standard library. I guess that would
>     suffice, no need to move to ARC.
>
>
> For 'simple' games, might as well write then in Java or C#, the tooling
> is much better, and support is offered by major multinational corporations.
> Not to say that they shouldn't be supported in D too, but that's not a
> target of interest to me, and I don't think it's an area which makes a
> particularly compelling argument for adoption of D.
> I've said before, console games is an industry desperate for salvation,
> and D makes a very strong case here in lieu of any other realistic
> alternatives... as long as this memory stuff is addressed acceptably.
>
> If there were to be some killer potential markets identified for D, I
> think this is definitely one of them.

Like you I don't see the interest for D to compete against C# or Java. 
IMO there is a big hole that C/C++ developers dream to see filled.
We want :
  - a less error prone language : DONE
  - a better syntax : DONE
  - advanced meta-programming features : DONE
  - a fast build : DONE
  - a rich framework : Have some potential (miss a lot of QtCore 
equivalent, GUI libraries), progress really slowly
  - be multi-platform : almost DONE
  - be cross-platform (binary portable) : a potential way with LVM bytecode
  - no performance concessions : GC issues
  - better tools (IDE with refactor tools working, better debugger,...)
  - buildin tools (unittest, static analyser,...) : DONE

For the moment D GC was a real pain for me on DQuick, I am not able to 
control when releasing my OpenGL resources easily. I can't wait a GC 
collect, cause handles are fewer than the central memory. The 
destruction order is also a real issue. I certainly have to learn new 
patterns, but I try to add a release method on Resource objects and add 
a check in debug to see if it was correctly called. I wasn't able to use 
Throwable.TraceInfo cause it's a class which means can't be printed in 
the destructor. So if a user forgive to call release method on a 
resource (leak) I just can't warm him with a great message...

For me leaks aren't just unreferenced pointers, but also and mainly 
chunk of resources still retained when not necessary cause those are 
harder to track and are critical on small devices. A GC won't help you a 
lot here, because IMO it act like a pool on every objects. It seems a 
lot of developers aren't concern by memory usage when there is a GC.
I am also concern of having all applications using a GC, cause it force 
user of multi-task OS to buy more memory or close few applications.

I just buy 4Go more cause I can't let my smartgit,VS,Chrome,... when 
playing Battlefield 4???. Smartgit is in Java, VS in C# in a part and 
Chrome create a process per tab???
Please stop pushing us create applications memory consuming, it's not cheap.

---

Maybe D is too ambitious, what we really need is a language that can be 
updated more easily than C++ to be as soon as possible usable in industry.

Seriously I work for a little game company, we are few developers (about 
9 developers on 3 different projects), we don't have means to use 
IncrediBuild or such tools to save times. Reducing the compile time and 
having a great framework are critical points for us. We have relatively 
few memory issues by managing it ourselves.

We use C++ cause our targets are numerous :
  - Windows Pocket PC : not anymore
  - Symbian : not anymore
  - Nintendo DS : not anymore
  - Nintendo Wii : not anymore
  - iOS
  - Windows
  - MacOS X
  - Android
  - Xbox 360
  - PS 3

Our applications/games can have some critical performances aspect, but 
we don't have to optimize all our code, cash misses are accepted :-) Our 
optimization are essentially high level or only concern the OpenGL 
render, maybe some few algorithm like simple occlusion, tiling,...

Sadly for next games we didn't use our internal game engine but Unity 
3D. We made some test on doing a scene like those of RTMI 
(http://www.youtube.com/watch?v=fGtfhKrg3l0) on Unity without success, 
cause of specific optimizations required for animations done with a lot 
of textures updates.

Editors prefers Unity cause of C# that is synonymous of standard tools 
and easier to regain control by other developers.


More information about the Digitalmars-d mailing list