Disable GC entirely

Manu turkeyman at gmail.com
Mon Apr 8 01:58:15 PDT 2013


On 8 April 2013 18:22, Manipulator <volcz at kth.se> wrote:

> I just re-read the "Doom3 Source Code Review" by Fabien Sanglard (
> http://fabiensanglard.net/**doom3/ <http://fabiensanglard.net/doom3/>)
> and apparently they don't use the Standard C++ library. "The engine does
> not use the Standard C++ Library: All containers (map,linked list...) are
> re-implemented but libc is extensively used."
> I certainly feel that there is room for improvement, like optimizing the
> GC, define a GC-free subset of Phobos etc. But it seems like if you're
> writing really performance critical realtime software most likely you've to
> implement everything bottom up to get the level of control.
>

I think it's important to realise though, that id software (and most game
devs for that matter) only implement their own containers/etc because C++
utterly failed them.
My whole point here is to make sure D gets it right in the std lib, so
people don't have to waste that time.
Rolling your own containers (or working upon any non-standard libs) leads
to generally incompatible code. Try plugging library X with its own set of
containers into application Y. If D fails on this front, I think it will
fail as a candidate for these developers; it will not be selected by
realtime developers trying to escape C++.
I suspect Andrei for one knows this, and that's why the D containers are
so... barely existing. The language is not yet ready to say with confidence
how they should look.

Performance critical shouldn't be incompatible with the notion of a
standard library. It just means the standard library authors didn't give a
shit, and I hope that doesn't transfer into D long-term... :/


Secondly it seems like it's most often cheaper to just throw faster
> hardware at a problem.
> "You can do tricks to address any one of them; but I pretty strongly
> believe that with all of these things that are troublesome in graphics,
> rather than throwing really complex algorithms at them, they will
> eventually fall to raw processing power."(http://fabiensanglard.**
> net/doom3/interviews.php <http://fabiensanglard.net/doom3/interviews.php>)
>

You saw the AMD guy who recently came out and said "moores law is over",
right? ;)

Remember that you're reading an article by a PC developer. The thing about
phones and games consoles (particular games consoles, since they have a
10-ish year lifetime... phones are more like 6 months, but they'll slow
with time), and now sunglasses (god knows what next!), is that they're
fixed hardware. The developers are required to compete to get the most out
of a fixed machine.
The language/libs need to help with this and not waste everyones time. If
the library is particularly bad, the developers will rewrite it themselves,
at expense of time, sanity, and portability.

I've reinvented more wheels in my career than I care to imagine. Actually,
It's probably not a far fetched call to say I've spent MOST of my working
life re-inventing wheels... just because a standard or popular library was
written by a PC developer for x86 :(
I don't believe D can afford to be that short-sighted. The future is not
high performance x86 pc's, that time is _already_ 5 years behind us.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130408/3595f073/attachment-0001.html>


More information about the Digitalmars-d mailing list