{"id":36973,"date":"2004-12-16T07:00:00","date_gmt":"2004-12-16T15:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2004\/12\/16\/optimization-is-often-counter-intuitive\/"},"modified":"2021-07-31T08:49:08","modified_gmt":"2021-07-31T15:49:08","slug":"20041216-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20041216-00\/?p=36973","title":{"rendered":"Optimization is often counter-intuitive"},"content":{"rendered":"

Anybody who’s done intensive optimization knows that optimization is often counter-intuitive. Things you think would be faster often aren’t.<\/p>\n

Consider, for example, the exercise of obtaining the current instruction pointer. There’s the na\u00efve solution:<\/p>\n

__declspec(noinline)\r\nvoid *GetCurrentAddress()\r\n{\r\n  return _ReturnAddress();\r\n}\r\n\r\n...\r\nvoid *currentInstruction = GetCurrentAddress();\r\n<\/pre>\n
If you look at the disassembly, you’ll get something like this:<\/p>\n
GetCurrentAddress:\r\n    mov eax, [esp]\r\n    ret\r\n\r\n...\r\n    call GetCurrentAddress\r\n    mov [currentInstruction], eax\r\n<\/pre>\n
“Pah,” you say to yourself, “look at how inefficient that is. I can reduce that to two instructions. Watch:<\/p>\n
void *currentInstruction;\r\n__asm {\r\ncall L1\r\nL1: pop currentInstruction\r\n}\r\n<\/pre>\n
That’s half the instruction count of your bloated  girly-code<\/a>.”<\/p>\n
But if you sit down and race the two code sequences, you’ll find that the function-call version is faster by a factor of two! How can that be?<\/p>\n
The reason is the “hidden variables” inside the processor. All modern processors contain much more state than you can see from the instruction sequence. There are TLBs, L1 and L2 caches, all sorts of stuff that you can’t see. The hidden variable that is important here is the return address predictor.<\/p>\n
The more recent Pentium (and I believe also Athlon) processors maintain an internal stack that is updated by each CALL<\/code> and RET<\/code> instruction. When a CALL<\/code> is executed, the return address is pushed both onto the real stack (the one that the ESP<\/code> register points to) as well as to the internal return address predictor stack; a RET<\/code> instruction pops the top address of the return address predictor stack as well as the real stack.<\/p>\n
The return address predictor stack is used when the processor decodes a RET<\/code> instruction. It looks at the top of the return address predictor stack and says, “I bet that RET<\/code> instruction is going to return to that address.” It then speculatively executes the instructions at that address. Since programs rarely fiddle with return addresses on the stack, these predictions tend to be highly accurate.<\/p>\n
That’s why the “optimization” turns out to be slower. Let’s say that at the point of the CALL L1<\/code> instruction, the return address predictor stack looks like this:<\/p>\n\n\n\n\n
Return address
\npredictor stack:<\/th>\n		\u00a0<\/td>\ncaller1<\/td>\n\u2192<\/td>\ncaller2<\/td>\n\u2192<\/td>\ncaller3<\/td>\n\u2192<\/td>\n\u22ef<\/td>\n<\/tr>\n
Actual stack:<\/th>\n\u00a0<\/td>\ncaller1<\/td>\n\u2192<\/td>\ncaller2<\/td>\n\u2192<\/td>\ncaller3<\/td>\n\u2192<\/td>\n\u22ef<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Here, caller1<\/code> is the function’s caller, caller1<\/code> is the function’s caller’s caller, and so on. So far, the return address predictor stack is right on target. (I’ve drawn the actual stack below the return address predictor stack so you can see that they match.)<\/p>\n
Now you execute the CALL<\/code> instruction. The return address predictor stack and the actual stack now look like this:<\/p>\n\n\n\n\n
Return address
\npredictor stack:<\/th>\n		\u00a0<\/td>\nL1<\/td>\n\u2192<\/td>\ncaller1<\/td>\n\u2192<\/td>\ncaller2<\/td>\n\u2192<\/td>\ncaller3<\/td>\n\u2192<\/td>\n\u22ef<\/td>\n<\/tr>\n
Actual stack:<\/th>\n\u00a0<\/td>\nL1<\/td>\n\u2192<\/td>\ncaller1<\/td>\n\u2192<\/td>\ncaller2<\/td>\n\u2192<\/td>\ncaller3<\/td>\n\u2192<\/td>\n\u22ef<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
But instead of executing a RET<\/code> instruction, you pop off the return address. This removes it from the actual stack, but doesn’t remove it from the return address predictor stack.<\/p>\n\n\n\n\n
Return address
\npredictor stack:<\/th>\n		\u00a0<\/td>\nL1<\/td>\n\u2192<\/td>\ncaller1<\/td>\n\u2192<\/td>\ncaller2<\/td>\n\u2192<\/td>\ncaller3<\/td>\n\u2192<\/td>\n\u22ef<\/td>\n<\/tr>\n
Actual stack:<\/th>\n\u00a0<\/td>\ncaller1<\/td>\n\u2192<\/td>\ncaller2<\/td>\n\u2192<\/td>\ncaller3<\/td>\n\u2192<\/td>\ncaller4<\/td>\n\u2192<\/td>\n\u22ef<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
I think you can see where this is going.<\/p>\n
Eventually your function returns. The processor decodes your RET<\/code> instruction and looks at the return address predictor stack and says, “My predictor stack says that this RET<\/code> is going to return to L1<\/code>. I will begin speculatively executing there.”<\/p>\n
But oh no, the value on the top of the real stack isn’t L1<\/code> at all. It’s caller1<\/code>. The processor’s return address predictor predicted incorrectly, and it ended up wasting its time studying the wrong code!<\/p>\n
The effects of this bad guess don’t end there. After the RET<\/code> instruction, the return address predictor stack looks like this:<\/p>\n\n\n\n\n
Return address
\npredictor stack:<\/th>\n		\u00a0<\/td>\ncaller1<\/td>\n\u2192<\/td>\ncaller2<\/td>\n\u2192<\/td>\ncaller3<\/td>\n\u2192<\/td>\n\u22ef<\/td>\n<\/tr>\n
Actual stack:<\/th>\n\u00a0<\/td>\ncaller2<\/td>\n\u2192<\/td>\ncaller3<\/td>\n\u2192<\/td>\ncaller4<\/td>\n\u2192<\/td>\n\u22ef<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Eventually your caller returns. Again, the processor consults its return address predictor stack and speculatively executes at caller1<\/code>. But that’s not where you’re returning to. You’re really returning to caller2<\/code>.<\/p>\n
And so on. By mismatching the CALL<\/code> and RET<\/code> instructions, you managed to cause every single return address prediction on the stack to be wrong. Notice in the diagram that, in the absence of somebody playing games with the return address predictor stack of the type that created the problem initially, not a single prediction on the return address predictor stack will be correct<\/strong>. None of the predicted return addresses match up with actual return addresses.<\/p>\n
Your peephole optimization has proven to be shortsighted.<\/p>\n
Some processors expose this predictor more explicitly. The Alpha AXP, for example, has several types of control flow instructions, all of which have the same logical effect, but which hint to the processor how it should maintain its internal predictor stack. For example, the BR<\/code> instruction says, “Jump to this address, but do not push the old address onto the predictor stack.” On the other hand, the JSR<\/code> instruction says, “Jump to this address, and push the old address onto the predictor stack.” There is also a RET<\/code> instruction that says, “Jump to this address, and pop an address from the predictor stack.” (There’s also a fourth type that isn’t used much.)<\/p>\n
Moral of the story: Just because something looks better doesn’t mean that it necessarily is<\/strong> better.<\/p>\n","protected":false},"excerpt":{"rendered":"
Things you think would be faster often aren’t.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[26],"class_list":["post-36973","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-other"],"acf":[],"blog_post_summary":"
Things you think would be faster often aren’t.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/36973","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=36973"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/36973\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=36973"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=36973"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=36973"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}