On 8 January 2012 08:03, F i L <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? 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?