Idea #1 on integrating RC with GC

[Manu]

On 10 February 2014 17:58, francesco cattoglio <
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140210/733ef7ec/attachment.html>