Do 360/PS3 programmers still use assembler?
- Thread starter Commenter
- Start date
We mainly use CPU-specific intrinsics instead of ASM (when we need VMX128 and PPC specific instructions). Nowadays you do not need raw ASM that much, since the compiler does register allocation so well (and you often want to inline efficiently).
But intrinsics are very close to ASM (usually 1:1 mapping to CPU instructions), and you should always check what set of ASM instructions the intrinsics compile to (you might get silly load/stores if you do not know what you are doing).
But intrinsics are very close to ASM (usually 1:1 mapping to CPU instructions), and you should always check what set of ASM instructions the intrinsics compile to (you might get silly load/stores if you do not know what you are doing).
To be clear, that's only for certain functions and not the entire engine, right? No-one rwrites a complete engine in a low-level language any more, unlike the old days of gaming where that low level code was essential. ASM/Intrinsics and just dived into where there's an obvious bottleneck in the C++ compiled version, or where a task is so common that you want as efficient an engine running it as possible.
Would it in any way be possible to quantify to what degree low level languages are used?
Would it in any way be possible to quantify to what degree low level languages are used?
Outside of vector optimizations, usually you look at the disassembly and decide if it's worthwhile.
Usually it isn't, performance is all about cache hits, not instruction scheduling, and that's go so much more to do with data layouts than the code that's doing the work. Occasionally if you need particular cache behavior, you might resort to assembler, if you can't get the compiler to generate the code you want.
IME it'd be a lot less than 1% of the average code base today written using intrinsics/assembler.
Having said that I still consider assembler to be one of the most important skills for a game programmer, because C++ programmers who don't understand processors and caches are a liability.
Usually it isn't, performance is all about cache hits, not instruction scheduling, and that's go so much more to do with data layouts than the code that's doing the work. Occasionally if you need particular cache behavior, you might resort to assembler, if you can't get the compiler to generate the code you want.
IME it'd be a lot less than 1% of the average code base today written using intrinsics/assembler.
Having said that I still consider assembler to be one of the most important skills for a game programmer, because C++ programmers who don't understand processors and caches are a liability.
Makes sense. You don't need to use assembler to make use of the knowledge. Is assembler still relevant in education, or one of those skills/knowledges that only come with grizzled coding vets with several tours of duty under their belt, and all the green recruits are oblivious to it?
I think both assembler and machine architecture are still important in education.
However for the most part American universities seem to disagree.
It's understandable to some extent, for most programming jobs "good enough" doesn't include knowledge of how a program runs.
There are plenty of studios that won't hire people who can't demonstrate knowledge in these areas.
I always used to ask candidates to write a trivial CRT function in an interview, and then discuss how to optimize it. I'm looking for understanding of what's actually expensive, and what you can save.
However for the most part American universities seem to disagree.
It's understandable to some extent, for most programming jobs "good enough" doesn't include knowledge of how a program runs.
There are plenty of studios that won't hire people who can't demonstrate knowledge in these areas.
I always used to ask candidates to write a trivial CRT function in an interview, and then discuss how to optimize it. I'm looking for understanding of what's actually expensive, and what you can save.
Is that anything being addressed in these new gaming courses that you know of? I've always looked on specific game-development courses with a degree of suspicion, and expect a lot of students go in expecting an easy, fun doss about, won't be the smartest cookies in the jar, and the colleges/uni's will want applicants to get through to get funding so won't have high entry requirements or tough syllabi. Very cynical, I know!
IME they are much the same as other courses, you get good students and bad.
My biggest issue with new college grads, is the combination of them not understanding what they don't know, and their not respecting the fact that what they do impacts everyone on the team. They can easily cost more than they contribute, it's on of the reasons I dislike intern programs, interns are there just long enough to do the damage and not be there to see the consequences.
Passion is one of the most important parts of looking at college grads, but it has to be metered by realism, or you end up losing them at the end of projects when the reality of shipping games sinks in.
Everyone has to start somewhere, no one is born a game developer.
The single most common reason to use asm/intrinsics is for vector instructions. You just can't live without them, and no compiler can automatically generate good vectorized code (esp for in-order CPUs that have lots of stall cases).
Other common uses for asm/intrinsics are cache hints (preload data), cache control (clearing/flushing pages, non-cache polluting stores, etc) and complex CPU instructions (bitscan, fsel, etc). We do not write the asm/intrinsics around our code, we have macros for these, so that we can define different sets of intrinsics to emit for different platforms.
Sometimes you have to use assembler to order your instructions perfectly when you have a pipeline stall situation. For example when you want to move data from float pipeline registers to vector pipeline registers, the data needs to go though the L1, and this takes time. You want to do all your float stuff first, move some other instructions in between (to "waste" some cycles) and then load the data to vector registers. The compiler however is happy to "optimize" and reorder your code so that the float and vector stuff gets "nicely" interleaved. With assembler you have direct control of the order of execution. On PC OOO architectures, this problem is much smaller, since the CPU can automatically move instructions to fill stall cycles. You do not do this kind of optimizations right away when you write the code. Console profilers have good tools for detecting pipeline stalls. Sometimes you are fine with restructuring the C++ code, but sometimes getting hands dirty with assembler is the only choice. Other common case when ordering is important is when you are writing to memory that is not cached (write combined pages or streaming non-polluting vector writes --- for example when you are writing to your dynamic vertex buffers). You need to write whole cache lines (and with certain alignment requirements), or you get severe stalls. Sometimes C++ just doesn't want to cooperate.
Other common uses for asm/intrinsics are cache hints (preload data), cache control (clearing/flushing pages, non-cache polluting stores, etc) and complex CPU instructions (bitscan, fsel, etc). We do not write the asm/intrinsics around our code, we have macros for these, so that we can define different sets of intrinsics to emit for different platforms.
Sometimes you have to use assembler to order your instructions perfectly when you have a pipeline stall situation. For example when you want to move data from float pipeline registers to vector pipeline registers, the data needs to go though the L1, and this takes time. You want to do all your float stuff first, move some other instructions in between (to "waste" some cycles) and then load the data to vector registers. The compiler however is happy to "optimize" and reorder your code so that the float and vector stuff gets "nicely" interleaved. With assembler you have direct control of the order of execution. On PC OOO architectures, this problem is much smaller, since the CPU can automatically move instructions to fill stall cycles. You do not do this kind of optimizations right away when you write the code. Console profilers have good tools for detecting pipeline stalls. Sometimes you are fine with restructuring the C++ code, but sometimes getting hands dirty with assembler is the only choice. Other common case when ordering is important is when you are writing to memory that is not cached (write combined pages or streaming non-polluting vector writes --- for example when you are writing to your dynamic vertex buffers). You need to write whole cache lines (and with certain alignment requirements), or you get severe stalls. Sometimes C++ just doesn't want to cooperate.
That's very true. We only have a handful of (senior) programmers that are comfortable with assembler/intrinsics, processor caches and various pipeline stall situations. And that's a burden, since we are the only ones who do performance profiling and optimize all our bottlenecks.
How much will users of a third party engine like Unreal dabble with low-level coding?
If your game is simple enough, you could basically just write it with script on top of the commercial middleware. Even completely unoptimized C++ code tends to be much faster than script, so you should be fine without any low-level coding.
However if you need to make any customizations or have complex game logic that requires performance critical code that the middleware doesn't provide you, you at least need to know the CPU stall cases and the CPU cache behaviour, and how to solve problems with these. Aligning structures properly to cache lines, using cache-friendly structures/algorithms, knowing multithreaded programming basics and knowing when to use which SDK functions is often enough. No asm/intrinsics needed. However for best performance you should manually add some extra cache hints (prefect data) based on your profiling results. Middleware's include optimized vector math libraries, SDKs tend to include some basic (but highly optimized) stuff as well, so you dont need to implement the vector math yourself (unless you need some customized solutions for your own performance critical code sections).
I recall an ancient interview with Peter Molyneux, after Bullfrog had just finished Populous 2. He lamented that the game consisted of...I cannot recall the exact number, but probably a hundred thousand+ lines of assembler, and how difficult a project it had been, and how he never wanted to repeat that experience again.
I also have an impression of Popu2 being very very buggy, most certainly partly a function of being written in pure assembler (and probably a certain amount of rushed-ness as well.)
Sounds like Braben and Frontier (Elite 2) to me. Populous 2 on Amiga was a solid affair. Frontier was a mess and Braben insisted on doing it all in assembler.
Assembler is very unforgiving of poor planning.You can hack 100K lines of C and get away with it, hacking 100K lines of assembler will cost you.
It's one of the reasons I miss programmers having assembler experience on a real product, it pretty much guaranteed they could do architecture at least at a tactical level.
I've probably written a million plus lines of assembler, and the largest of the games I wrote in asm were probably in the 100K lines range. It's manageable, you just have to plan appropriately, major design changes can be a killer though.
It's one of the reasons I miss programmers having assembler experience on a real product, it pretty much guaranteed they could do architecture at least at a tactical level.
I've probably written a million plus lines of assembler, and the largest of the games I wrote in asm were probably in the 100K lines range. It's manageable, you just have to plan appropriately, major design changes can be a killer though.
No I don't believe anyone wrote in pure assembler last gen, it was probably the case even on PS1.
Modern games have millions of lines of code it simply isn't practical.
Genesis was the last system I wrote assembler games on.
