[OT] Previously: DMD - Windows -> C# in gamedev

[Joshua Reusch]

Am 08.01.2012 12:05, schrieb Manu:
> On 8 January 2012 08:03, F i L <witte2008 at gmail.com
> <mailto:witte2008 at gmail.com>> wrote:
>
>     I've got some interesting ideas on how pre-written code packages
>     could be easily designer-style assembled in-editor and compiled into
>     efficient native logic blocks "on the fly". Only D's fast native
>     compile times and easy-to-grasp syntax would really allow for what
>     I'm thinking.
>
>
> If you're talking about stringing together pre-written code blocks with
> some editor, then this might be an interesting approach.
> I'm not so sure how 'easy-to-grasp' D is, or why that's important if
> you're providing an editor?
> I tend to think D is considerably less simple than C, possibly more
> complex (but less archaic) than C++... It's not really something you
> could expose to a designer.
>
>     Given your experience in this area, I would appreciate any insight
>     you could offer about the potential pros/cons for writing low level
>     game engine components in D. Would you say D is a effective tool to
>     write a general purpose memory pool, or would something like that be
>     better written in C?
>
>
> I'm probably not the best to comment, because I still haven't
> internalised all the possibilities of D's powerful language features.
> But I think C is basically a subset of D, so I don't see any inhibiting
> reason why it couldn't all be done in D. My concern is mainly over
> whether D makes it easy, or ugly to manage all the resources as strictly
> as required, and how much of D's idioms/paradigms you need to subvert to
> actually do it.
>
> Writing an engine in 'C-ish' D is surely possible, writing it in 'D'...
> potentially problematic.
> I'm keen to have a go in the near future as an experiment, I expect in
> engine level code, the GC might frustrate me.
> Writing various memory managers/pools/buffers themselves is surely fine
> in D, no problem... but USING them in an idiomatic way to allocate
> objects, there's no support in D.
>
> D:
> MyObject obj = new MyObject(x, y, z);
>
> D (subverting GC):
> MyObject* obj = (MyObject*)someManager.Alloc(MyObject.sizeof);
> ....? how do I even perform a placement new?
>

Just an idea how it could look whith allocators: What about adding an 
argument to the new operator for the allocator struct (like GC), and let 
the user define an default one ? I think something similar can already 
be done by overloading the new  and assignment operator:

Runtime.setDefaultAllocator!GC();
auto refcounted = new!RefCounter MyObject();

> I wouldn't want to be doing that everywhere.
> If D implements allocators, then I can see that being much better,
> enabling one to still write fairly conventional D code.
>
>     Or.. is it common to have an array of specialized object pools? I'd
>     imagine such an engine would sacrifice flexibility and eat up more
>     memory, but most likely easier to implement.
>
>
> I fail to see where this is sacrificing flexibility, but yes, you do
> tend to over-reserve in these sorts of pools, but there's no real
> alternative (although I use a lot of tricks).
>
> Cache efficiently is all about memory locality, and pooling 'like'
> things together and stream processing them in batches is the most
> efficient way to do work on ANY computer.
> Once you write your systems this way, they tend to thread+scale well,
> and automatically.. You could even easily offload them to a video card,
> or other sort of DSP.
>
> What I usually do to avoid major over-reservation of memory is to break
> the pools into smaller 'buckets' (some multiple-of and aligned-to the
> systems most course grained cache), and extend/contract the pool size as
> needed.
> Cache alignment is very important, I was surprised+concerned the other
> night when Walter mentioned that D does NOT support aligning anything to
> any power of 2 using the align() attribute.
> I'm curious to know under what circumstances it actually works?