Le 10/02/2014 09:58, Manu a écrit :
On 10 February 2014 17:58, francesco cattoglio
<francesco.cattog...@gmail.com <mailto:francesco.cattog...@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.
