> Rewriting some x87 FPU code and inlining a whole ton of useless getter functions along the critical paths because the developers at Bethesda, for some reason, compiled the game without using any of the optimization flags for release build.
That sounds appalling. This is not some tricky algorthm-level optimization - they seem to have simply disabled compiler optimizations. Or forgot to reenable them for the final release. Inlining a function should have zero impact on the QA process (some try to explain the lack of optimization by the need to 'fix' bugs). If it does, then there is some sort of memory corruption bug somewhere, and the code should fail QA anyway.
Ensuring compiler optimizations are active would be the first low-hanging-fruit thing to come to anyone's mind when considering performace. The fact that it was 'forgotten' means that no one even considered performance during the whole development process. Not even in the "let's leave it to the compiler" form.
I think you're making the same mistakes as people on that thread. It's a long stretch from "there's some x87 assembly instructions and some function calls that could be inlined" to "they compiled with optimisations off".
It's entirely possible, for example, that the relevant code came from a 3rd party library that the game was statically linked against; or that they had to disable optimisations in parts of the code because they were found to cause bugs elsewhere.
Creating a rich interactive world the size of Skyrim is a considerable technical achievement, so I certainly don't think you can accuse the developers of incompetence.
>disable optimisations in parts of the code because they were found to cause bugs elsewhere.
Well that is exactly what I meant. Compiler optimizations by themselves do not cause bugs - they reveal bugs. They are specfically designed to be sematically equivalent[1]. Without the compiler optimizations the bugs may not manifest themselves, or only manifest themselves in particular conditions that may not be spotted by QA - but the bugged/unsafe code is still present. Any functional discrepancy between compiler-optimized and non-optimized code should be cause for concern.
>Creating a rich interactive world the size of Skyrim is a considerable technical achievement,
I wouldnt say that the size is a technical acheivement - the credit would mostly go to the artists there - and they did an amazing job. Although it would cerainly not be possible without a decent quality engine.
Don't get me wrong. I really like skyrim, and have spent a lot of time with it. But I simply get the feeling that performance receives less and less attention in the modern products.
Compiler optimizations by themselves do not cause bugs - they reveal bugs.
This is incorrect. Optimizations do often reveal bugs rather than causing them, but turning on optimizations can also cause bugs in itself. See for example:
These are due to bugs in the compiler, not inherent property of optimizations. It's quire rare for anyone to hit a optimizer bug and when it happens one can always selectively disable the buggy optimization method. Disabling all optimizations kinda overdoes it.
Compiler optimisations aren't always designed to be semantically equivalent - for instance options which control floating point behaviour, like -ffast-math in gcc.
That aside, sometimes compilers themselves have bugs as others have pointed out (I found one once involving a combination of python, boost, exceptions and the Intel C++ compiler - which only happened at -O3, not at -O2). Or you might not be able to use certain settings because it would be incompatible with some thirdparty library that you don't have the source to.
Re: the size, the technical achievement is in managing all the content, how you interact with it and how it interacts with itself, etc. It's doing quite a lot of I/O to pull in the right assets at the right time - not to mention some computational geometry to figure out which are the right assets; running lots of AI for the creatures & NPCs; balancing memory usage between RAM & VRAM; simulating a night & day cycle, with weather too; rendering it all in (usually!) less than 30 milliseconds; and more besides. I certainly don't mean to play down the achievement of the artists involved, but don't underestimate the technical side either!
> Compiler optimizations by themselves do not cause bugs - they reveal bugs.
Incorrect, and naive in the extreme.
> They are specfically designed to be sematically equivalent
Unconvincing. Machines are specifically designed to not blow up, and yet they do.
> But I simply get the feeling that performance receives less and less attention in the modern products.
I agree, but often we gain something in terms of the scope of games that a team can create. If you want to make a movie, you probably shouldn't start by designing the camera.
> Ensuring compiler optimizations are active would be the first low-hanging-fruit thing to come to anyone's mind when considering performace. The fact that it was 'forgotten' means that no one even considered performance during the whole development process. Not even in the "let's leave it to the compiler" form.
This is a silly conclusion. More likely it means that either it was a conscious decision, or at the last minute the ball was dropped and those who should have signed off on this decision didn't even know about it.
How could you go from serious-performance-error/tradeoff ships to "no one even considered performance during the whole development process" (my emphasis).
For the type of vector arithmetic you do in games, SSE (much less later flavors like SSE2/3/etc.) is a big win. SIMD instructions for number crunching is huge.
Your example there is more GCC being shitty than anything else.
You're both wrong. iso-8859-1 is wrong that it's not inherently faster. Individual SSE instructions are not necessarily faster (in a latency sense) than the x87 equivalents, but the cleaner register architecture (no stack) means that they can be parallel-issued better by the CPU, and code generated to use them does less spilling and filling to memory. SSE is just plain better, though not overwhelmingly so.
And angersock is missing the point: you can't take scalar code and rebuild it into SIMD (except in the very limited, never-works-as-well-as-you-think-it-should auto vectorization features in modern compilers), the parallelism needs to be designed in. That's not possible here without a rewrite of the game engine.
So, I specifically said that SSE was better for the vector arithmetic that games do. Almost any game you pick will, in the source somewhere, have Vector3::Add(), Vector4::Dot(), etc. functions.
Scalar code is not trivially fixed by using SSE, true, but the majority of really obnoxious math being done (skinning, vector arithmetic, etc.) should be really easy to make really fast.
Right, which is missing the point. The use case at hand is rebuilding some particular part of the engine (honestly it's unclear to me exactly what was done) with different flags, not reworking the vector librar{y,ies} to use SSE.
SSE wouldn't be a flags issue. Building a vectorized SSE library in "debug mode" would still produce vector instructions.
That sounds appalling. This is not some tricky algorthm-level optimization - they seem to have simply disabled compiler optimizations. Or forgot to reenable them for the final release. Inlining a function should have zero impact on the QA process (some try to explain the lack of optimization by the need to 'fix' bugs). If it does, then there is some sort of memory corruption bug somewhere, and the code should fail QA anyway.
Ensuring compiler optimizations are active would be the first low-hanging-fruit thing to come to anyone's mind when considering performace. The fact that it was 'forgotten' means that no one even considered performance during the whole development process. Not even in the "let's leave it to the compiler" form.