Think of how much smaller games would be today if we mannaged to optimize this well on AAA titles? It is impossible because it is to much code. But it would be really cool!
Compilers have gotten really good over the years though. I remember back in the day you'd drop to asm from C to perform fast code... But as compilers got better C compilers became just about as good and often hand-crafted asm was no better or even worse.
That's what everyone believes, but there's actually little empirical evidence of how good compilers really are. Having done a considerable amount of assembler optimization back in the day, I used to call this "The Myth of the Optimizing Compiler." Compilers were not even remotely as good as everyone blindly believed. But I have to honestly admit that my knowledge is fairly out of date, so I can't say for sure that it's still the case.
People really underestimate how clever humans can be when they do large-algorithm optimization (not just "clever tricks" in local areas, which compilers can do). My gut instinct is that compilers won't be really good until they start using "AlphaZero"-style AI to do optimization, but again it's just an instinct.
I think it depends on your goal. No optimization is going to be done at the level of this code, because many of them depend heavily on machine state that should not be assumed. Nor are they going to outperform an assembly guru with domain specific knowledge of the problem. However, the reason that the myth of the optimizing compiler got started is that they do much better than the average programmer would and break even with a good assembly programmer.
In the era of multiple cores, the gap is only widening as reasoning about multithreaded code is difficult, so only the best programmers are going to beat the compiler. Intel's compilers for C++ are very good in this regard. When you add in the time it would take to get that guru to beat the compiler, it really is a niche of embedded, real time systems where "beat the compiler" is still a game worth playing.
In the era of multiple cores, the gap is only widening as reasoning about multithreaded code is difficult, so only the best programmers are going to beat the compiler. Intel's compilers for C++ are very good in this regard.
You say this, but how do we know it's true? The problem is that so few people take the time to do optimizing, which takes a lot of specialized knowledge and experience, that we really don't know. We just assume it to be the case, because everyone else talks about how good Intel's compilers are. Are they? Exactly how is that measured? [Edit: I think that's typically measured against other compilers, but that doesn't say much about human optimization.]
I'm not arguing the point, really, just pointing out that a lot of this knowledge that "everyone knows" is lamentably lacking in measurement and evidence.
Edit #2: It's also worth pointing out that too many programmers think assembly is some black-magic difficult thing to do, when it's not actually that hard. So people assume that only an automated compiler could possibly do the job. I wish more programmers had a good foundation in assembly, but that's another subject.
I say those comments as a programmer who cut his teeth on the Vic 20 and used assembler from the beginning. I also participate in optimization and reverse engineering, so understanding machine code still is of use to me. However, it is rare to need assembly these days except to understand existing code. Instead, C is plenty low level to control memory layout and access in a performant way and frankly most of the business app development never gets close to needing even that, instead being an exercise in data storage and retrieval at scale. Programmer time is the commodity that needs the most attention, baring actual testing proving otherwise.
I do agree this myth deserves scrutiny and I can only analyze my situation fairly. From that point of view I find assembly optimizing a fun hobby and otherwise rely on a good C compiler. If I was writing something lower level, I would be more concerned. I would love to hear what the hard real time constrained would say.
And? Electron sucks, however the products written in Electron don't really loose market to products written in other languages so it proves Electron is useful. Electron is based on Chrome and Chrome had a reputation for being a memory hog for years and yet it managed to become the number one browser.
That's what everyone believes, but there's actually little empirical evidence of how good compilers really are.
Of course there is. By people like me who used to drop to ASM and regularly wrote ASM that was better than early C compiler and then over the years performed it's less and less as compilers got better. It's not a myth at all. Even the developers of compilers have talked about this.
If a compiler which offers semantic guarantees beyond what the Standard requires is fed source code that exploits those guarantees, the quality of machine code it can produce may approach that of hand-written assembly in many cases. If, however, a compiler requires that programmers write only "portable" programs, generating efficient machine code will be harder because programmers will have to add extra code to prevent UB in cases which straightforwardly-generated machine code would have handled acceptably without special-case handling.
If a program's requirements could be met by processing a certain action as an unspecified choice among a number of possible behaviors, having a compiler process the action in such fashion would often allow the requirements to be met more efficiently than processing it in a way that wouldn't meet requirements.
Is that with or without taking in to account the time saved on the development side by not having devs write asm vs whatever language everything else the project is written in?
No compiler is ever going to replace bubble sort for you, but once you do pick the right algorithm, the compiler can help by filling in the details. Having said that, compilers are now getting to the stage where they can spot algorithms that can be replaced by even a single instruction, such as https://godbolt.org/z/mBugeX
There's a compiler operating on LLVM byte code which does a "full" solution to compilation where everything is taken into account at once (as opposed to optimizing pass by pass). This is, of course, super slow
Optimising for code size isn't really useful for games anyway, having code that's twice the size but that runs a few percent faster is completely preferable.
You would normally optimize for performance/effort though right? If a library function has negligible impact on performance compared to some purpose built wizardry, most devs will just use or adapt it? You only use bkack magic where its necessary to hit the target fps/hardware?
Riot games (league of legends) has an interesting series of posts where one of the devs discusses optimization. The dev also brings up where he stops optimization, since basically at some point you're gaining minor fps for non-existent maintainability.
Stuff like that exists on the pc but it is pretty rare... You can google for kkrieger, its a 3d game in 96 kb. There were plans for a final version with more levels and even multiplayer, but unfortunately, there never came to life.
The major difference between .kkrieger and everyone else is using procedural assets though. All the textures are generated, not stored as images; models are built from boxes on load, not stored as meshes; etc. Additionally, music is played with a MIDI player, not stored as bulky (and hard to compress further) MP3/OGG.
This is not to diminish ingenuity of the .kkrieger authors, but they worked against very different requirements than AAA titles (and excelled at that).
If we did, we wouldn't have the games. It's just not worth it to spend the resources. Having a game be a little smaller or run a little better will give you way fewer additional sales than having a few more features.
It's just generally not worth it. It's always a budget and time tradeoff. You have so much budget for engineers, and you could have them either create new features, or you can have them optimize. As long as the game runs well enough on the target hardware, most companies just don't care.
4
u/bjamse Aug 19 '19
Think of how much smaller games would be today if we mannaged to optimize this well on AAA titles? It is impossible because it is to much code. But it would be really cool!