Hacker News Reader

Comment by United857 | Hacker News Reader

It's worth noting that chips that were designed for high-performance computing (e.g. the Cell) from the outset generally don't have silicon devoted to things like out of order execution, register renaming, etc. In this case, the bulk of the optimization logic does shift to the programmer (aided by the compiler).

The reason is that in these domains (e.g. game consoles, supercomputing), you know ahead of time the precise hardware characteristics of your target, you can assume it won't change, and can thus optimize specifically for that ahead of time.

This isn't true for "mass-market" software that needs to run across multiple devices, with many variants of a given architecture.

View on HN

> The reason is that in these domains (e.g. game consoles, supercomputing), you know ahead of time the precise hardware characteristics of your target, you can assume it won't change, and can thus optimize specifically for that ahead of time.

Cell was a failure in large part because this proved to be less true / less relevant than its designers thought.

Source: many late nights / weekends trying to get PS3 launch titles performing well enough to ship.

I did work in graduate school trying to make the Cell easier to program - basically, providing OpenMP-like abstractions that would take advantage of the SPEs. I've always been really curious: how much did your games take advantage of the SPEs? When did you send code to the SPEs versus using the GPU? Were you using libraries that helped managing the SPEs, or did you do all of it manually?

OpenMP is a bad approach for the types of problems commonly encountered in games and graphics programming in my experience. Matt Pharr's excellent series of articles on the history of ISPC gives some good explanations of what programming models actually work well for graphics particularly: http://pharr.org/matt/blog/2018/04/30/ispc-all.html

At the time I was doing most of my SPE work (helping to optimize launch titles at EA prior to the launch of the PS3) most titles weren't taking much advantage of them at all. We were a central team helping move some code that seemed like it would most benefit over, I was particularly involved in moving animation code to the SPEs. There weren't really any options for libraries to help at that point, other than things we were building internally, so it was almost all manual work.

Later on in the PS3 lifecycle people moved more and more code to the SPEs. To my knowledge most of that work was largely manual still. For a while I was project lead on EA's internal job/task management library which had had a big focus on supporting use of the SPEs but my involvement in it was mostly during the early part of the Xbox One / PS4 generation. The Frostbite graphics team in particular did a lot of interesting work shifting GPU work over to the SPEs (I think some of it they've talked about publicly) but I wasn't directly involved in that.

I completely believe you on OpenMP being bad for games and graphics programming; we were targeting the HPC community which had a heavy interest in Cell as well. But all the while, I knew a bunch of programmers out in the world were shipping Cell code, and I was always curious what their patterns were. Thanks for the answers!

The point of dynamic optimizations (such as ooo) is not only to hide implementation details (such as register file size) but very much to take advantage of dynamic opportunities that simply cannot be known statically. The optimal schedule can be very different depending on whether some load hit L1 vs L2 or even was forwarded from the store buffer.

There are some classes of very regular algorithm where you could probably predict everything (and handle the memory hierarchy) statically, such as GEMM, but it's not very common.

Yeah, this is a very important point that many people seem to be missing, including the authors of the original article it seems to me. It was certainly a big problem for performance of games on Cell in my experience.

Reply on news.ycombinator.com