View mode: basic / threaded / horizontal-split · Log in · Help
January 07, 2012
Re: [OT] Previously: DMD - Windows -> C# in gamedev
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!
January 07, 2012
Re: [OT] Previously: DMD - Windows -> C# in gamedev
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.
January 07, 2012
Re: [OT] Previously: DMD - Windows -> C# in gamedev
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...
January 08, 2012
Re: [OT] Previously: DMD - Windows -> C# in gamedev
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++.
January 08, 2012
Re: [OT] Previously: DMD - Windows -> C# in gamedev
> 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.
January 08, 2012
Re: [OT] Previously: DMD - Windows -> C# in gamedev
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.
January 08, 2012
Re: [OT] Previously: DMD - Windows -> C# in gamedev
"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++).
January 08, 2012
Re: [OT] Previously: DMD - Windows -> C# in gamedev
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.
January 08, 2012
Re: [OT] Previously: DMD - Windows -> C# in gamedev
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.
January 08, 2012
Re: [OT] Previously: DMD - Windows -> C# in gamedev
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'.
1 2 3 4
Top | Discussion index | About this forum | D home