Template Metaprogramming Made Easy (Huh?)

[Tom S]

Jeremie Pelletier wrote:
> Tom S Wrote:
> 
>> Jeremie Pelletier wrote:
>>> I myself allocate all my meshes and textures directly on the GC and I'm pretty sure its faster than C's malloc and much safer.
>> Hm, why would it be faster with the GC than malloc? I'm pretty sure it's 
>> the opposite :P Plus, I could use a specialized malloc implementation, 
>> like TLSF.
> 
> The D GC is already specialized, and given its being used quite a lot in D, there are good chances its already sitting in the CPU cache, its heap already having the available memory block waiting on a freelist, or if the alloc is more than 0x1000 bytes, the pages available in a pool. You'd need to use malloc quite a lot to get the same optimal performance, and mixing the two would affect the performance of both.

It might be specialized for _something_, but it definitely isn't 
real-time systems. I'd say with my use cases there's a very poor chance 
the GC is sitting in the CPU cache since most of the time my memory is 
preallocated and managed by specialized structures and/or malloc. I've 
found that using the GC only for the hard-to-manually-manage objects 
works best. The rest is handled by malloc and the GC has a very shallow 
vision of the world thus its collection runs are very fast. Of course 
there's a drawback that both the GC and malloc will have some pages 
cached, wasting memory, but I don't let the GC touch too much so it 
should be minimal. YMMV of course - all depends on the memory allocation 
patterns of the application.


>>>>>> - I like how D doesn't totally ignore safety as C does, in D sometimes the default way is the safer one, and the unsafe way is used only where you ask for it.  I'd like to see more safeties added to D, like optional run-time and compile-time integral overflow tests, some pointer safety, better template error messages (template constraints help some in such regard), stack traces, less compiler bugs, safer casts (in C# you need explicit casts to convert double => float), a safer printf, some optional annotations inspired by Plint (a lint program) to give more semantics to the compiler, that can be used to both speed up code and avoid bugs. There's lot that can be done in this regard. And release-mode performance can be usually kept unchanged.
>>>>> Stack traces is a feature for the runtime, I made one for mine, which shows a dialog window with the stack trace, current registers values, loaded modules and whatnot. Took me almost a week to piece together my CodeView reader, I still need a DWARF reader for linux. I'm gonna try and implement it in druntime and submit the patch to bugzilla.
>>>> Tango's runtime already does stack tracing on Windows and *NIX, however 
>>>> its CV parser is subject to some licensing issues :( Perhaps you could 
>>>> release yours under some liberal license so it can be plugged there? :)
>>>>
>>> Sure, I wouldn't mind at all, I'm not into licenses myself so I might just release it to public domain. I'll try and get a standalone package ready and post it somewhere, I just don't know where yet :x
>> Sweet :D As for a place, there are plenty of options, e.g. 
>> http://dsource.org/projects/scrapple/ or a separate dsource project.
> 
> I thought of that, but I don't feel like opening a project for just a few random code snippets or standalone classes. I think I'll just post it in this forum and let interested people grab it for now.

WORKSFORME :)


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode