<div dir="ltr">On 8 April 2013 18:22, Manipulator <span dir="ltr"><<a href="mailto:volcz@kth.se" target="_blank">volcz@kth.se</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I just re-read the "Doom3 Source Code Review" by Fabien Sanglard (<a href="http://fabiensanglard.net/doom3/" target="_blank">http://fabiensanglard.net/<u></u>doom3/</a>) 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."<br>

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.<br>
</blockquote><div><br></div><div style>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.</div><div style>
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.</div><div style>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++.</div>
<div style>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.</div><div><br></div><div style>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... :/</div>
<div style><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Secondly it seems like it's most often cheaper to just throw faster hardware at a problem.<br>
"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."(<a href="http://fabiensanglard.net/doom3/interviews.php" target="_blank">http://fabiensanglard.<u></u>net/doom3/interviews.php</a>)<br>
</blockquote><div><br></div><div style>You saw the AMD guy who recently came out and said "moores law is over", right? ;)</div><div style><br></div><div style>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.</div>
<div style>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.</div><div style>
<br></div><div style>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 :(</div>
<div style>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.</div></div></div></div>