http://www.valvesoftware.com/publications/2008/GDC2008_CrossPlatformDevelopment.pdf
Explains it really well. On Mon, Jun 2, 2008 at 5:40 PM, Mike Blaszczak <[EMAIL PROTECTED]> wrote: > It's not that the OS isn't capable of memory management. It's that the > application can do better than the OS in many cases. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: Saturday, May 31, 2008 17:32 > To: [email protected] > Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > > There are only a few sections where the gains were at all significant. > Rather than a divergent library they probably could've realized a few > optimization patches and gotten the same benefit. The thing I don't > understand though is why so many software companies to this day still > try to do so much low-level memory management themselves, as if the OS > was incapable of it. It's not just gaming software either: case in > point, Firefox and its insane memory management that bloats to using > hundreds of megabytes over time. > > Paul Peloski wrote: > > -- > > [ Picked text/plain from multipart/alternative ] > > In the algorithms they made some significant gains on Windows and > Xbox, but > > not so much on Mac and Linux. I guess libstdc++ is faster than > Microsoft's > > STL implementation. Since a lot of games will target Microsoft > platforms I > > guess it was a good move to rewrite their STL implementation. > > > > I wonder if Valve has a similar benchmark comparison for CUtl* and the > > equivalent operations using STL. > > > > Regards, > > > > Paul > > > > On Fri, Feb 15, 2008 at 11:23 AM, Nate Nichols <[EMAIL PROTECTED]> > wrote: > > > > > >> That is a really interesting article. How did you find it? > >> > >> Also, they do have some performance benchmarks buried at the bottom: > >> > >> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html#Appen > dix_20<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html#Appendix_20> > >> > >> Nate > >> > >> On Fri, Feb 15, 2008 at 9:55 AM, Paul Peloski <[EMAIL PROTECTED]> > >> wrote: > >> > >>> -- > >>> [ Picked text/plain from multipart/alternative ] > >>> Interesting, thanks for finding that. > >>> > >>> I wonder if eastl is actually faster, more portable, etc. I'm sure > it > >>> satisfies their desire for a simpler std::allocator. But, I would > have > >>> > >> liked > >> > >>> to see some performance comparisons in this paper. There's nothing > like > >>> > >> hard > >> > >>> numbers to justify the time they spent rewriting/redesigning the > STL. > >>> > >>> Regards, > >>> > >>> Paul > >>> > >>> > >>> On Fri, Feb 15, 2008 at 4:56 AM, Justin Krenz <[EMAIL PROTECTED]> > wrote: > >>> > >>> > >>> > >>> > >>>> I found a good site that details EA's own version of STL and why > game > >>>> > >>> > companies don't use STL. > >>> > > >>> > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html > >>> > > >>> > Paul Peloski wrote: > >>> > > -- > >>> > > [ Picked text/plain from multipart/alternative ] > >>> > > Why doesn't Valve use the STL, anyways? I've always wondered. I > >>> > >> really > >> > >>> > like > >>> > > the STL (and Boost). Is there some important consideration I > missed > >>> > about > >>> > > their usage with the Source SDK? > >>> > > > >>> > > Regards, > >>> > > > >>> > > Paul > >>> > > > >>> > > >>> > _______________________________________________ > >>> > To unsubscribe, edit your list preferences, or view the list > >>> > >> archives, > >> > >>> > please visit: > >>> > http://list.valvesoftware.com/mailman/listinfo/hlcoders > >>> > > >>> > > >>> -- > >>> > >>> > >>> > >>> _______________________________________________ > >>> To unsubscribe, edit your list preferences, or view the list > archives, > >>> > >> please visit: > >> > >>> http://list.valvesoftware.com/mailman/listinfo/hlcoders > >>> > >>> > >>> > >> _______________________________________________ > >> To unsubscribe, edit your list preferences, or view the list > archives, > >> please visit: > >> http://list.valvesoftware.com/mailman/listinfo/hlcoders > >> > >> > >> > > -- > > > > _______________________________________________ > > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > > > > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- - Benjamin Davison _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
