Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Electronic Arts Standard Template Library for C++ Open Sourced

github.com

Post reply on HN
Print view View original

31–40 of 60 posts

Re: Electronic Arts Standard Template Library for C++ Open Sourced

#31

Post by yelnatz »

Ono-Sendai wrote: post #21
CyberDildonics wrote: post #10

Earlier quoted context omitted.

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.

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.

Re: Electronic Arts Standard Template Library for C++ Open Sourced

#32

Post by santaclaus »

Animats wrote: post #22

Cute. It's fun to see game programmer code. This is really C with a little C++. Lots of pointer casts, comments like "The user must provide ample buffer space, preferably 256 chars or more." There's a lot of stuff in there to deal with Microsoft Visual C++'s interpretation of the language, which prior to 2010, was kind of off. Why does "swap" use EASTL/move_help.h? There are things that can go wrong with a move that…

> Move is a swap with a constraint that the destination be empty.

Is there actually any constraint here? I thought the only constraint on a moved-from object is that you can't use it in the current state.

Re: Electronic Arts Standard Template Library for C++ Open Sourced

#33

Post by pcwalton »

ixtli wrote: post #23
Animats wrote: post #22

Cute. It's fun to see game programmer code. This is really C with a little C++. Lots of pointer casts, comments like "The user must provide ample buffer space, preferably 256 chars or more." There's a lot of stuff in there to deal with Microsoft Visual C++'s interpretation of the language, which prior to 2010, was kind of off. Why does "swap" use EASTL/move_help.h? There are things that can go wrong with a move that…

> Cute. It's fun to see game programmer code. This. I work almost exclusively with game programmers and it can be ... difficult at times. They seem to be largely unaware of the larger computer science community that's existed since the mid sixties, often "discovering" things that were solved by the science years ago.

On the other hand, game programmers are just as frequently the only ones exercising anything close to the full functionality of today's hardware. It's kind of depressing how little use SIMD, multicore, and GPU (compute or otherwise) get outside of games. Games have done a pretty good job keeping up with the ending of Moore's Law for sequential code, but we continue to use our old sequential libraries and leave so much performance on the table in the app world.

I do agree that the apps and server world is ahead, in many cases way ahead, in terms of effective development practices and programming languages. But we've lost sight of how to get performance out of the hardware.

Re: Electronic Arts Standard Template Library for C++ Open Sourced

#34

Post by santaclaus »

pcwalton wrote: post #33
ixtli wrote: post #23

Earlier quoted context omitted.

> Cute. It's fun to see game programmer code. This. I work almost exclusively with game programmers and it can be ... difficult at times. They seem to be largely unaware of the larger computer science community that's existed since the mid sixties, often "discovering" things that were solved by the science years ago.

On the other hand, game programmers are just as frequently the only ones exercising anything close to the full functionality of today's hardware. It's kind of depressing how little use SIMD, multicore, and GPU (compute or otherwise) get outside of games. Games have done a pretty good job keeping up with the ending of Moore's Law for sequential code, but we continue to use our old sequential libraries and leave so muc…

> game programmers are just as frequently the only ones exercising anything close to the full functionality of today's hardware

I know some ML and HPC cats who obsess about hitting peak gigaflops...

Re: Electronic Arts Standard Template Library for C++ Open Sourced

#35

Post by pcwalton »

santaclaus wrote: post #34
pcwalton wrote: post #33

Earlier quoted context omitted.

On the other hand, game programmers are just as frequently the only ones exercising anything close to the full functionality of today's hardware. It's kind of depressing how little use SIMD, multicore, and GPU (compute or otherwise) get outside of games. Games have done a pretty good job keeping up with the ending of Moore's Law for sequential code, but we continue to use our old sequential libraries and leave so muc…

> game programmers are just as frequently the only ones exercising anything close to the full functionality of today's hardware I know some ML and HPC cats who obsess about hitting peak gigaflops...

Yeah, I was too broad there, sorry about that. There are definitely a few fields like scientific computing and HFT that are very good at extracting performance out of modern hardware.

Still, app and server developers, by and large, have not been able to do this (and I count myself among them!) We use languages with no support for SIMD, we stick to language implementations without optimizing compilers, single-threaded language implementations are very popular, we ignore GPU computing despite the fact that the die space reserved for the GPU is as large or larger than the die space reserved for the CPU cores nowadays, and so on.

Re: Electronic Arts Standard Template Library for C++ Open Sourced

#36

Post by Noughmad »

greggman wrote: post #27
jupp0r wrote: post #5

And I thought my workplace was the last shop in the world to still write new code in hungarian notation ...

That's "bad" systems hungarian instead of "good" apps hungarian http://www.joelonsoftware.com/articles/Wrong.html

If you use C++, you should really be using a separate type for this, rather then rely on variable names. The compiler is much better at catching these things than you are.

Re: Electronic Arts Standard Template Library for C++ Open Sourced

#37

Post by sharpneli »

ixtli wrote: post #23
Animats wrote: post #22

Cute. It's fun to see game programmer code. This is really C with a little C++. Lots of pointer casts, comments like "The user must provide ample buffer space, preferably 256 chars or more." There's a lot of stuff in there to deal with Microsoft Visual C++'s interpretation of the language, which prior to 2010, was kind of off. Why does "swap" use EASTL/move_help.h? There are things that can go wrong with a move that…

> Cute. It's fun to see game programmer code. This. I work almost exclusively with game programmers and it can be ... difficult at times. They seem to be largely unaware of the larger computer science community that's existed since the mid sixties, often "discovering" things that were solved by the science years ago.

The constraints and things that matter are different. I've had both experiences like you and also the opposite ones. As an example the constant factor in time usage is surprisingly important in games. Amortized time consumption is not the absolute end all be all.

Designing any soft realtime application is subtly different from traditional application. Your frametime budget is 16ms. It's rock solid. You spend 17ms and you're down to 30fps and you could've just spent 33ms.

That's actually the reason why garbage collection is big no no in games. One cannot afford even 1ms gc pauses. And in server world that's considered blazingly fast. If a game is for some reason developed using a language with GC it's just skipped by making object pools. And then tediously checking that no allocations and freeing actually happens during a frame.

Re: Electronic Arts Standard Template Library for C++ Open Sourced

#38

Post by pgeorgi »

chris_wot wrote: post #13
albertzeyer wrote: post #3

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…

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

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

Re: Electronic Arts Standard Template Library for C++ Open Sourced

#39

Post by sshumaker »

pcwalton wrote: post #18

We on the Rust team got to speak about the lessons learned from the EASTL with Paul Pedriana (the author of much of it) while designing the Rust standard library. It's a significant influence on the proposed allocators API currently in RFC. The EASTL is worth looking at for anyone interested in designing libraries that work well in low-memory environments. (Much of this library was written with devices like the Ninte…

I had the pleasure of being Paul's intern way back in 2000. At the time, Paul was at Maxis and if IIRC the library actually had its roots in the C++ frameworks Paul built for SimCity 3000. Those games actually were quite a bit ahead, engineering-wise, in terms of the C++ of the day.

Re: Electronic Arts Standard Template Library for C++ Open Sourced

#40

Post by nickpsecurity »

pcwalton wrote: post #33
ixtli wrote: post #23

Earlier quoted context omitted.

> Cute. It's fun to see game programmer code. This. I work almost exclusively with game programmers and it can be ... difficult at times. They seem to be largely unaware of the larger computer science community that's existed since the mid sixties, often "discovering" things that were solved by the science years ago.

On the other hand, game programmers are just as frequently the only ones exercising anything close to the full functionality of today's hardware. It's kind of depressing how little use SIMD, multicore, and GPU (compute or otherwise) get outside of games. Games have done a pretty good job keeping up with the ending of Moore's Law for sequential code, but we continue to use our old sequential libraries and leave so muc…

I was re-exploring that issue recently. It wasn't obvious to me which of two strategies I commonly saw are best: extend existing languages with parallel constructs as in Cilk/C, ParaSail/Ada, or Lime/Java; create custom languages + compilers like Cray's Chapel or academic Triolet whose output cleanly integrates with apps in an existing language. My uncertainty comes from the fact that general-purpose languages founded in sequential use might be too hard to max out on arbitrary multi-core & CPU architectures. What's your opinion on which looks to be the best route so far?

Cilk http://supertech.lcs.mit.edu/cilk/

ParaSail http://www.embedded.com/design/other/4375616/ParaSail--Less-...

Lime Compilation http://researcher.watson.ibm.com/researcher/files/us-bacon/D...

Chapel http://chapel.cray.com/overview.html

Triolet http://impact.crhc.illinois.edu/shared/Papers/dissertation-r...

Post reply on HN