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
