On 7 January 2012 20:59, bearophile <bearophileHUGS@lycos.com> wrote:

> Manu:
>
> > The tendency to encourage use of dynamic arrays will be a major problem.
>
> I don't know how much big that problem will be, D dynamic arrays are quite handy, but I agree that static arrays need to be encouraged more in D (and currently most algorithms of Phobos don't work with static arrays (you need to slice them first)).
>

A slice doesn't produce a GC allocation does it?
I thought a slice was just a pointer-length pair. Should live on the
stack/in regs?

...so slicing static arrays shouldn't be a problem right?


> Currently even this code with a stack-allocated fixed size array causes a
> heap allocation (DMD):
>
> void main() {
>    int[2] a = [1, 2];
> }
>
> ASM, optimized build:
>
> __Dmain comdat
>    push EAX
>    push EAX
>    mov EAX,offset FLAT:_D12TypeInfo_xAi6__initZ
>    push EBX
>    push 8
>    push 2
>    push EAX
>    call near ptr __d_arrayliteralTX ; heap allocation
>    add ESP,8
>    mov EBX,EAX
>    mov dword ptr [EAX],1
>    mov ECX,EBX
>    push EBX
>    lea EDX,0Ch[ESP]
>    mov dword ptr 4[EBX],2
>    push EDX
>    call near ptr _memcpy
>    add ESP,0Ch
>    xor EAX,EAX
>    pop EBX
>    add ESP,8
>    ret
>

What the hell is it allocating?
Surely that's not necessary... that's gotta be fixable?


> I have suggested to add a safer version of VLAs to avoid some heap-allocated dynamic arrays: http://d.puremagic.com/issues/show_bug.cgi?id=5348


+1!!
I'm surprised this already isn't supported!

On 7 January 2012 21:00, Froglegs <lugtug@gmail.com> wrote:

>  Well games often already integrate scripting languages, generally Lua or
> Mono, which are both GC based. But this is for the game logic, not for the
> high performance parts of the code.
>

Indeed. And this is usually just to mitigate the fact that C++ is so crap at this sort of code. Maybe D will be tolerable, and this breaking out to script won't be necessary? (though I'm dubious)

 For a GC to be used at the C++/D layer it would need to be
>
> 1) optional always, D makes it optional but you loose a solid chunk of the
> language if you ditch GC, what remains is in some ways inferior to C++(no
> escaping lambda without GC, /cry)
> 2) no long pauses ever
>
>  I think most game engine stuff will continue to be written without GC, as
> it doesn't really add much if what you are after is raw performance. And
> C++ does have smart pointers which perform much of what a GC does, but
> without the long pauses or non deterministic destruction.
>

I must generally agree, I expect the GC would offer me basically nothing
but nuisance in engine level code. I'm generally shovelling large, strictly
controlled buffers which need proper placement/alignment, pool allocation,
or allocation from temporal ring buffers and that sort of thing.
I don't typically find C/C++ intolerable, or even particularly unpleasant
for engine level code as it is, it's the higher level code I'm keen to
escape.

On 7 January 2012 23:26, Walter Bright <newshound2@digitalmars.com> wrote:

> There are more options with D:
>
> 3) Disable GC from collecting during critical parts of the code, i.e. you can still new all you want, it just won't run collection cycles.
>

This may be nice, but there is never a 'non-critical' part of a game where I can spare 5...10...15ms (I hear 15ms quoted often, that's a *whole* frame) to let the GC do its thing.


> 4) Pre-allocate all necessary data before entering the critical sections.
> You have to do this anyway with C++ if you have hard realtime constraints,
> as C++ makes no guarantees about how long new or malloc() will take (and it
> cannot).
>

This will obviously happen anyway (and with strict allocation requirements... I'd like D allocators at some point, or this'll get messy with pointers), but that doesn't help, for instance, bearophile's example of a pointless allocation assigning a literal to a stack array, or various other trivial allocations that go on here and there like that...

I'm also dubious about string allocations. I'd quite like a way to have
strings allocate in their own little self contained heap. They can use GC,
but they need to be separated into their own little memory region, and not
pollute/fragment the rest of the heap.
Engine code tends to create large allocations, megabytes in size, and with
very course alignment rules, 4k for instance, and little allocations
fragmenting memory can cause major problems/gaps...

On 7/01/12 11:17 PM, Manu wrote:
> On 7 January 2012 21:00, Froglegs <lugtug@gmail.com
> <mailto:lugtug@gmail.com>> wrote:
>
>       Well games often already integrate scripting languages, generally
>     Lua or Mono, which are both GC based. But this is for the game
>     logic, not for the high performance parts of the code.
>
>
> Indeed. And this is usually just to mitigate the fact that C++ is so
> crap at this sort of code. Maybe D will be tolerable, and this breaking
> out to script won't be necessary? (though I'm dubious)

The main advantage of Lua for game code (in my opinion) is runtime reloading, and the ability to avoid recompiles just to test some new game logic. That's not so easy with C++.

> Indeed. And this is usually just to mitigate the fact that C++ is so crap
> at this sort of code. Maybe D will be tolerable, and this breaking out to
> script won't be necessary? (though I'm dubious)

Yeah C++ is a migraine for that type of code:(  I think D would be nicer than C++ for gameplay code, but another reason for scripts is the ability to modify the script while the game is running, and just the general lack of compilation time which is soo nice.

Perhaps if D gets ported to mono? Though even then I think I'd prefer Lua, since it is quite good at acting as both a language and data description.


> I don't typically find C/C++ intolerable, or even particularly unpleasant
> for engine level code as it is, it's the higher level code I'm keen to
> escape.

Yes I agree!

I tend to think of the code I work with as having three levels

1) low level - high performance, optimal memory layout/access, alignment concerns, intrinsic, not much abstraction(unfortunately..). C++ works pretty well here(though any improvements are welcome..), certainly I'm not aware of anything else that is better

2) mid level - good performance, fairly optimal memory, no intrinsics, fairly abstract. C++ works OK here, but I think D could be better at this

3) high level - moderate/low performance, GC memory, JIT'd if you are lucky, but possibly interpreted, can reload scripts while program is executing. Neither D nor C++ work here.


#1 isn't actually that much code, but the program probably spends the majority of its time executing it, so it is pretty important



Also in reply to Walter-- for me the problem with pausing the GC, and then running it at certain times, is that there is actual no time when it is alright for the GC to take any significant amount of time to collect( a couple milliseconds might be acceptable, but can that be guaranteed?).  Some games don't have load screens, or levels, but just an endless streaming world.

On Sun, Jan 8, 2012 at 10:12 AM, Froglegs <lugtug@gmail.com> wrote:

>
>  Indeed. And this is usually just to mitigate the fact that C++ is so crap
>> at this sort of code. Maybe D will be tolerable, and this breaking out to script won't be necessary? (though I'm dubious)
>>
>
> Yeah C++ is a migraine for that type of code:(  I think D would be nicer than C++ for gameplay code, but another reason for scripts is the ability to modify the script while the game is running, and just the general lack of compilation time which is soo nice.
>
> Perhaps if D gets ported to mono? Though even then I think I'd prefer Lua, since it is quite good at acting as both a language and data description.


D currently does several things that I would find useful doing game logic level code (my day job) and if it were simultaneously able to keep engine coders and people like me happy I can see a future for it. These are the things I see as important.

Fast vector/matrix maths. (thankyou Manu for getting the ball rolling on
this)
some form of realtime friendly (semi) automatic memory management.
Ability to write correct code easily.
Ability to drop down to the metal style coding if there is a serious
bottleneck and a deadline.

"Froglegs" <lugtug@gmail.com> wrote in message news:lwcqnrvamqlnjjlxzbqa@dfeed.kimsufi.thecybershadow.net...
>
> can reload scripts while program is executing. Neither D nor C++ work here.
>

Why not a dll? Those can be compiled/loaded/reloaded at runtime. And since it's just scripts, it wouldn't take long to compile at all, at least in D (maybe not so much in C++).

On 1/7/2012 3:30 PM, Manu wrote:
> On 7 January 2012 23:26, Walter Bright <newshound2@digitalmars.com
> <mailto:newshound2@digitalmars.com>> wrote:
>
>     There are more options with D:
>
>     3) Disable GC from collecting during critical parts of the code, i.e. you
>     can still new all you want, it just won't run collection cycles.
>
>
> This may be nice, but there is never a 'non-critical' part of a game where I can
> spare 5...10...15ms (I hear 15ms quoted often, that's a *whole* frame) to let
> the GC do its thing.

It should also be possible to do the gc in another thread running at low priority, if the only other running thread is doing the critical stuff and is not the sole holder of references to any GC allocated memory it is using.

On 8 January 2012 03:40, Nick Sabalausky <a@a.a> wrote:

> "Froglegs" <lugtug@gmail.com> wrote in message news:lwcqnrvamqlnjjlxzbqa@dfeed.kimsufi.thecybershadow.net...
> >
> > can reload scripts while program is executing. Neither D nor C++ work here.
> >
>
> Why not a dll? Those can be compiled/loaded/reloaded at runtime. And since it's just scripts, it wouldn't take long to compile at all, at least in D (maybe not so much in C++).
>

It's common for designers to edit scripts, and they don't usually have coding environments on their machines.

On 8 January 2012 03:46, Walter Bright <newshound2@digitalmars.com> wrote:

> It should also be possible to do the gc in another thread running at low priority, if the only other running thread is doing the critical stuff and is not the sole holder of references to any GC allocated memory it is using.
>

... sound like unreliable restrictions. Now sure I follow exactly what you mean by 'only other running thread', and 'critical stuff'.