Am 08.01.2012 12:05, schrieb Manu:
On 8 January 2012 08:03, F i L <witte2...@gmail.com
<mailto:witte2...@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?
