On Wednesday, 2 January 2013 at 12:32:01 UTC, deadalnix wrote:
> On Wednesday, 2 January 2013 at 11:41:33 UTC, DythroposTheImposter wrote:
>> I'm interested in how the new LuaJIT GC ends up performing. But overall I can't say I have much hope for GC right now.
>>
>> GC/D = Generally Faster allocation. Has a cost associated with every living object.
>>
>
> True, however, GC + immutability allow new idoms that are plain impossible in a non GC world, and that are really efficients at reducing copies and allocations (and used in many high perf D libs).
>

And the problem is that D uses GC as a sledgehammer. A GC
shouldn't be used for everything. If it is used for stuff it
works well at and not for anything and everything, then it
becomes useful.

Because the GC is used for everything in D it gets clogged up
with stuff like simple object allocation(which, of course, there
is a way to get around, but not easily) which effects it's
performance.

For example, suppose the GC was used only for closures and
nothing else. In this case, since closures are not used that much
compared to other things, the GC would have minimal impact on
performance. It could probably be ran once a month and not have
memory issues.

But since the GC does everything, you have to run it much more
often, which means the amortization is much higher regardless if
we even use closures.

Ultimately the best option is control. If we were not "forced" to
use the GC for everything but could enable it for different
things, then we could tweak it for best performance.

And why does Phobos/runtime require the GC in so many cases when
it could just use an internal buffer? So much effort has been put
in to make the GC work that it simply has neglected all those
that can't use it as it is.

Basically doing the exact opposite by making the GC more
ubiquitous in D. Makes people that have no problem with the GC
happy but those that do have problems just get more and more
frustrated.

What has happened is the GC has made the library writers lazy. It
doesn't belong in 99% of Phobos.

On Saturday, 1 February 2014 at 05:36:44 UTC, Manu wrote:
> I write realtime and memory-constrained software (console games), and for
> me, I think the biggest issue that can never be solved is the
> non-deterministic nature of the collect cycles, and the unknowable memory
> footprint of the application. You can't make any guarantees or predictions
> about the GC, which is fundamentally incompatible with realtime software.
(tried to manually fix ugly linebreaks here, so apologies if it turns out even worse.)

(Maybe this would be better posted in D.learn; if so I'll crosspost.)

In your opinion, of how much value would deadlining be? As in, "okay handyman, you may sweep the floor now BUT ONLY FOR 6 MILLISECONDS; whatever's left after that you'll have to take care of next time, your pride as a professional Sweeper be damned"?

It obviously doesn't address memory footprint, but you would get the illusion of determinism in cases similar to where race-to-idle approaches work. Inarguably, this wouldn't apply if the goal is to render as many frames per second as possible, such as for non-console shooters where tearing is not a concern but latency is very much so.

I'm very much a layman in this field, but I'm trying to soak up as much knowledge as possible, and most of it from threads like these. To my uneducated eyes, an ARC collector does seem like the near-ideal solution -- assuming, as always, the code is written with the GC in mind. But am I right in gathering that it solves two-thirds of the problem? You don't need to scan the managed heap, but when memory is actually freed is still non-deterministic and may incur pauses, though not necessarily a program-wide stop. Aye?

At the same time, Lucarella's dconf slides were very, very attractive. I gather that allocations themselves may become slower with a concurrent collector, but collection times in essence become non-issues. Technically parallelism doesn't equate to free CPU time; but that it more or less *is* assuming there is a cores/thread to spare. Wrong?

Lastly, am I right in understanding precise collectors as identical to the stop-the-world collector we currently have, but with a smarter allocation scheme resulting in a smaller managed heap to scan? With the additional bonus of less false pointers. If so, this would seem like a good improvement to the current implementation, with the next increment in the same direction being a generational gc.

I would *dearly* love to have concurrency in whatever we end up with, though. For a multi-core personal computer threads are free lunches, or close enough so. Concurrentgate and all that jazz.

On Saturday, 1 February 2014 at 12:04:56 UTC, JR wrote:
> In your opinion, of how much value would deadlining be? As in, "okay handyman, you may sweep the floor now BUT ONLY FOR 6 MILLISECONDS;

Unrelated to the whole post note: 6ms is too high, I would allow max 1ms a frame for a game I'm developing and even that is somewhat painful.

If I turn on GC on the game I'm making, it takes 80ms every frame when memory usage is 800mb (shown on task manager). This was actually surprising, previously it was 6ms, good that I made my engine GC independent.

On 2/1/2014 3:20 AM, Paulo Pinto wrote:
>
> Meanwhile Unity and similar engines are becoming widespread, with C++
> being pushed all the way to the bottom on the stack.
>
> At least from what I hear in the gaming communities I hop around.
>
> What is your experience there?
>

It's not uncommon for Unity-engine games to drop down to C++ to optimize bottlenecks. Somewhat of a pain since you have to deal with the CLR <-> unmanaged marshalling mess. (I do really wish Unity would expose an optional C/C++ API so you wouldn't need a pointless CLR layer sandwiched between the C++-based engine and any non-CLR game code...)

Keep in mind too that while Unity is certainly powerful, the games written with it aren't usually the ultra-AAA titles (like Battlefield, Crysis or Last of Us, for example) where a major part of the business is "wow everyone with never-before-seen technical achievements or risk failing to recoup the gigantic development costs".

Come to think of it, I wonder what language Frostbite 3 uses for game-level "scripting" code. From what I've heard about them, Frostbite 3 and Unreal Engine 4 both sound like they have some notable similarities with Unity3D (from the standpoint of the user-experience for game developers), although AIUI Unreal Engine 4 still uses C++ for game code (unless the engine user wants to to do lua or something on their own). I imagine Frostbite's probably the same, C++, but I haven't actually heard anything.

On Saturday, 1 February 2014 at 12:29:10 UTC, Nick Sabalausky wrote:
> Come to think of it, I wonder what language Frostbite 3 uses for game-level "scripting" code. From what I've heard about them, Frostbite 3 and Unreal Engine 4 both sound like they have some notable similarities with Unity3D (from the standpoint of the user-experience for game developers), although AIUI Unreal Engine 4 still uses C++ for game code (unless the engine user wants to to do lua or something on their own). I imagine Frostbite's probably the same, C++, but I haven't actually heard anything.

Frostbite has an option for both Lua and C++. C++ is the preferred one.

Unreal Engine went from Unrealscript to C++ and everyone applauded that.

On Saturday, 1 February 2014 at 12:20:33 UTC, develop32 wrote:
> If I turn on GC on the game I'm making, it takes 80ms every frame when memory usage is 800mb (shown on task manager). This was actually surprising, previously it was 6ms, good that I made my engine GC independent.

You wouldn't happen to have a blog post someplace with reflections on the steps you took to avoid the GC, by any chance? Hint hint! I'm genuinely curious.

Or is it merely a matter of manual allocation?

On Saturday, 1 February 2014 at 13:16:02 UTC, JR wrote:
> On Saturday, 1 February 2014 at 12:20:33 UTC, develop32 wrote:
>> If I turn on GC on the game I'm making, it takes 80ms every frame when memory usage is 800mb (shown on task manager). This was actually surprising, previously it was 6ms, good that I made my engine GC independent.
>
> You wouldn't happen to have a blog post someplace with reflections on the steps you took to avoid the GC, by any chance? Hint hint! I'm genuinely curious.
>
> Or is it merely a matter of manual allocation?

I don't have a blog...

It is mostly a matter of memory reuse (LOTS of it) and manual freeing when needed.

On Saturday, 1 February 2014 at 12:20:33 UTC, develop32 wrote:
> On Saturday, 1 February 2014 at 12:04:56 UTC, JR wrote:
>> In your opinion, of how much value would deadlining be? As in, "okay handyman, you may sweep the floor now BUT ONLY FOR 6 MILLISECONDS;
>
> Unrelated to the whole post note: 6ms is too high, I would allow max 1ms a frame for a game I'm developing and even that is somewhat painful.
>
> If I turn on GC on the game I'm making, it takes 80ms every frame when memory usage is 800mb (shown on task manager). This was actually surprising, previously it was 6ms, good that I made my engine GC independent.

Wow! That's interesting! What kind of game are you working on?

On Saturday, 1 February 2014 at 09:27:18 UTC, Adam Wilson wrote:
> For the vast majority of use cases, a GC is the right call and D has to cater to the majority if it wants to gain any significant mindshare at all. You don't grow by increasing specialization...

So catering to the C++ crowd who shun Java and C# not so much for JITing their code but precisely for their forced use of a GC is a "minority" issue then? Again, please take those of us more serious who don't like a GC to interfere with their business and if it's only for "programming hygiene" reasons. As you consider handling low latency requirements undue "specialisation" anyways.

On Saturday, 1 February 2014 at 12:04:56 UTC, JR wrote:
> To my uneducated eyes, an ARC collector does seem like the near-ideal solution

ARC would be a plus for heavily interdependent code. But it doesn't beat unique_ptr semantics in local use that free their memory immediately as they go out of scope or are reassigned.

> I would *dearly* love to have concurrency in whatever we end up with, though. For a multi-core personal computer threads are free lunches, or close enough so.

No they are not. I want to make good use of all the cores I have available and I don't want to share them a bit with the GC. It's myyy ... precious.

As you may have guessed, my criticism is harsh because I love the language :)

On Saturday, 1 February 2014 at 14:24:17 UTC, Francesco Cattoglio wrote:
> On Saturday, 1 February 2014 at 12:20:33 UTC, develop32 wrote:
>> On Saturday, 1 February 2014 at 12:04:56 UTC, JR wrote:
>>> In your opinion, of how much value would deadlining be? As in, "okay handyman, you may sweep the floor now BUT ONLY FOR 6 MILLISECONDS;
>>
>> Unrelated to the whole post note: 6ms is too high, I would allow max 1ms a frame for a game I'm developing and even that is somewhat painful.
>>
>> If I turn on GC on the game I'm making, it takes 80ms every frame when memory usage is 800mb (shown on task manager). This was actually surprising, previously it was 6ms, good that I made my engine GC independent.
>
> Wow! That's interesting! What kind of game are you working on?

Don't want to reveal too much now, its early in development, plan to have a proper trailer few months later.

Its an economical space sim, set in an asteroid field of 3000km radius, filled with 100k asteroids, hundred stations and few hundred AI ships. All of the characters/stations are simulated simultaneously.

http://imgur.com/QAKzJWb