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

I just re-read the "Doom3 Source Code Review" by Fabien Sanglard (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)

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.