Hacker News Reader

Comment by albertzeyer | Hacker News Reader

STL is maybe a bit missleading because it doesn't seem like it is a drop-in replacement for the STL.

However, this is certainly interesting because the emphasis on speed (and thus also on simplicity) is what I'm sometimes missing in the real STL or in Boost. That's exactly what you need in a game but also in much other performance critical code.

As far as I remember, Chrome has used the STL earlier. But I looked now and I see this: https://chromium.googlesource.com/chromium/blink/+/master/So...

Gecko also seem to have a lot of custom stuff: https://github.com/mozilla/gecko-dev/tree/master/xpcom/strin...

Doom3 idLib: https://github.com/id-Software/DOOM-3-BFG/tree/master/neo/id...

Unreal engine: https://answers.unrealengine.com/questions/2695/rocket-and-t...

You'll find much more similar libs when you search in some of the big games.

View on HN

> As far as I remember, Chrome has used the STL earlier. But I looked now and I see this:

The WTF (Web Template Framework) is actually inherited from WebKit and used in the core rendering engine. I'm not sure how widely it's used in the Google parts of Chromium.

> Gecko also seem to have a lot of custom stuff

That's the old XPCOM stuff. While those string types continue to get a lot of use, the closest analogue to the STL is MFBT: https://github.com/mozilla/gecko-dev/tree/master/mfbt

Chromium uses STL, WebKit (forked to Blink) uses custom stuff.

I've never had a problem shipping 60hz games with STL even on consoles.

What parts of the EASTL are faster than the normal STL? Does it have better maps?

Edit: From a look at the source it definitely at least has some extra map classes for more specialized uses.

One goal of EASTL is to be faster in non-optimized builds compared to other variants. If a game is running too slow to be playable, it can become impossible to debug! This was especially a problem on consoles with no OOE. It achieves this by sacrificing a lot of encapsulation and accepting non-DRY, manually inlined function implementations.

I didn't realise this was a goal, but it's good that it was. C++'s prime faults tend to be spiteful iteration time (common cause: too many templates) and appalling performance in unoptimized builds (common cause: too many function calls, possibly due to overloaded operators and overly-finely-grained code that relies on inlining not to run like shit).

The famous maxim about how much cleverer you have to be to debug code than to write it always applies! No need to make things worse by forcing yourself to debug the optimized build.

I measured the sort to be slightly faster: https://www.reddit.com/r/programming/comments/451yje/ea_open...

For the lazy:

std_sort_time: 0.08805380923877237s (11.908354778344838 M keys/s)

eastl_sort_time: 0.07010223707038676s (14.957810817751337 M keys/s)

EA's sort seems to respond better to full program optimisation than std::sort. Platform: vs2012 x64, i7 CPU.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n227... search for "20 - Performance comparison"

When I first saw that commit, I was all wtf?? wtf?! Thanks for that explanation.

You should see what was in the LibreOffice codebase at one point!

That simply predated the STL by a number of years, no?

Many, many years :-) it wasn't a true criticism

Reply on news.ycombinator.com