Hi all,
I work with Tony the author of the article and answer (or find someone to answer) any league questions you might have. Tony will be most likely be online later in the day as he works remotely with us from Australia.
Random Acts of Optimization
21–30 of 128 posts
Re: Random Acts of Optimization
#22This brings up a thought that I've had for a very long time. Almost every type of optimization that a programmer could employ is repeatable. It involves matching patterns ("Identification" in the context of this article), analysis ("Comprehension"), and rewriting ("Iteration"). All of these steps can be efficiently automated. And it turns out that compiler writers collectively know about the vast majority of these te…
There is such a thing as profile guided optimization. I don't think their results are particularly impressive. You're basically saying "can't you just" to which the answer is almost always no. No you can't just.
It's not that results are unimpressive, but the market has dictated faster compile times. When a PGO compilation is an order of magnitude slower, for the 90% of applications out there where the extra 5-25% improvement means less than a 60 sec improvement, then you won't care about PGO. You need to have an application an order of magnitude larger (in run time) to care about PGO. Smaller than Google, bigger than your startup. See xkcd [0][1] for when to care.
Re: Random Acts of Optimization
#23This is an interesting article, but Riot hasn't really earned any trust of mine at all as it comes to code quality; for a while they couldn't show the damage output of a spell because it caused the user's other summoner spell to go on cooldown for 15 minutes[1] when they tried. [1] ( https://www.reddit.com/r/leagueoflegends/comments/2hvukl/smi... )
Video games programmers have to learn more and make less. I'll give them the benefit of the doubt, especially since I can barely understand this particular blog post.
Re: Random Acts of Optimization
#24Earlier quoted context omitted.
There is such a thing as profile guided optimization. I don't think their results are particularly impressive. You're basically saying "can't you just" to which the answer is almost always no. No you can't just.
I've gotten pretty good results from PGO as well as JIT optimizations (which isn't conceptually much different), but even if I hadn't, your comment is still a fallacy on two accounts: 1) JITs were slow until they weren't. Poor results from existing experimental PGO compilers do not prove that the concept is flawed. 2) Profiling is a heuristic substitute for a real cost model. The most advanced optimizing compilers fo…
And in theory, dependent types are the awesomest thing ever. But they're not ready yet, and there's no guarantee they ever will be. There's a gulf between even having a few focused, carefully-chosen proofs of concept and a practically-useful technology.
(For that matter, I just grabbed that example off the top of my head as the thing I knew that most resembled the various fancy optimizers I've seen over the years, but it seems to me that dependent typing are full of things that would be darned useful for an optimizer. It would be funny if the fastest path towards whole-program optimization went through dependent types being practical.)
Re: Random Acts of Optimization
#25Earlier quoted context omitted.
There is such a thing as profile guided optimization. I don't think their results are particularly impressive. You're basically saying "can't you just" to which the answer is almost always no. No you can't just.
I've gotten pretty good results from PGO as well as JIT optimizations (which isn't conceptually much different), but even if I hadn't, your comment is still a fallacy on two accounts: 1) JITs were slow until they weren't. Poor results from existing experimental PGO compilers do not prove that the concept is flawed. 2) Profiling is a heuristic substitute for a real cost model. The most advanced optimizing compilers fo…
> Profiling is a heuristic substitute for a real cost model.
Even a perfect cost model can't tell you the difference between hot paths and cold paths. Profiling can.
Re: Random Acts of Optimization
#26Earlier quoted context omitted.
Riot's code base has a massive amount of technical debt, to a point where a rewrite is likely the best choice because of past technology decisions.
A rewrite would murder them. I'm not going to link that article everyone links about "never rewriting your code", because I don't think it's got the argument right, but I strongly feel that if they tried to rewrite a system as complex as theirs, they would either a) never finish or b) stop developing the game and, by the time they finished their rewrite, have no customers left. Anyway, it would end up being called a…
Not having a well-written client is murdering them. Sometimes the hard way is the best way.
Re: Random Acts of Optimization
#27This brings up a thought that I've had for a very long time. Almost every type of optimization that a programmer could employ is repeatable. It involves matching patterns ("Identification" in the context of this article), analysis ("Comprehension"), and rewriting ("Iteration"). All of these steps can be efficiently automated. And it turns out that compiler writers collectively know about the vast majority of these te…
Insulation from performance concerns also makes your performance model less predictable. Because the ends of optimisations are observable, but their means are not, people resort to “butterfly programming”. As a small example, in ActionScript 3, people used to write their conditionals like this:
if (a) if (b) {
...
}
if (a && b) {
...
}
In the real world, I’ve seen seemingly benign code changes prevent optimisations from firing—optimisations we didn’t know we were relying on. So people start coding to the implementation, rather than the language or the human, without even being able to see what they’re doing. I really don’t like that.
Optimisers are like garbage collectors—they give you better ergonomics than, and equal average performance to the manual alternative, if you’re willing to relinquish predictability and a non-voodoo mental model of your code’s performance.
Re: Random Acts of Optimization
#28This brings up a thought that I've had for a very long time. Almost every type of optimization that a programmer could employ is repeatable. It involves matching patterns ("Identification" in the context of this article), analysis ("Comprehension"), and rewriting ("Iteration"). All of these steps can be efficiently automated. And it turns out that compiler writers collectively know about the vast majority of these te…
The analysis part mostly is about legality of the transformation. Humans have a larger view of the program and change code to behave slightly different but way faster. A compiler can't change the behavior of the program.
Re: Random Acts of Optimization
#29Seems they don't want anyone using PIA to access their blog... Tried reconnecting and got denied again, had to switch endpoint country to actually get access.
> Error 1008 Access denied. The owner of this website (engineering.riotgames.com) has banned your IP address (108.61.57.217).
> Error 1008 Access denied. The owner of this website (engineering.riotgames.com) has banned your IP address (108.61.13.45).
Re: Random Acts of Optimization
#30This brings up a thought that I've had for a very long time. Almost every type of optimization that a programmer could employ is repeatable. It involves matching patterns ("Identification" in the context of this article), analysis ("Comprehension"), and rewriting ("Iteration"). All of these steps can be efficiently automated. And it turns out that compiler writers collectively know about the vast majority of these te…
> All of these steps can be efficiently automated. Good luck with that. Yes, a compiler will do a good job with i * 28, but the optimization in the article - which is a pretty simple case, chosen to fit in a blog post - requires manipulating the algorithm beyond the capability of any compiler I'm aware of. We do have good tooling to show what code is slow, for instance, so it's not like automation doesn't help here.
Indeed. Often the slowest code for us is due to cache friendliness more than algorithmic complexity.
For the data to be laid out correctly the problem needs to be solved way earlier in your toolchain as well as downstream with a rewrite of any algorithm that touches it