Post B517R9Y2VZLPfpDIYK by Rairii@labyrinth.zone
 (DIR) More posts by Rairii@labyrinth.zone
 (DIR) Post #B517R9KZJeZL02uXYW by millihertz@oldbytes.space
       0 likes, 0 repeats
       
       something just occurred to me.so for a couple of decades now, x86 CPUs have employed a specialised call/ret predictor to speed up subroutine predictions. the critical bit is the RET predictor, which takes the prediction off the CPU's internal stack that was left there by CALL and starts executing code there.fortunately, i doubt it uses a whole lot of silicon real estate. i say fortunately, because frankly, you might as well completely ignore it and rely instead of the x86's unparallelled ability to predict indirect jumps instead. (is that what compilers do these days? i don't know...)because while most of the time it will work as advertised, immediately after a context switch every single prediction it retuns will be wrong. in a way that the indirect predictor just won't be. and while the innermost subroutines might return quickly, that pretty much accounts for the bottom two or three layers. the rest of them? pointless... unless the core is running single threaded code, with no context switches at all.which, of course, doesn't happen a whole lot on modern computers...
       
 (DIR) Post #B517R9Y2VZLPfpDIYK by Rairii@labyrinth.zone
       0 likes, 0 repeats
       
       @millihertz it'll happily speed up kernel code though, i wonder how much that matters
       
 (DIR) Post #B517dcCTo0Oy0o4Ulc by millihertz@oldbytes.space
       1 likes, 0 repeats
       
       @Rairii even kernel code has to context switch
       
 (DIR) Post #B517dcS4s0sWnBMx4y by Rairii@labyrinth.zone
       0 likes, 0 repeats
       
       @millihertz that tends to leave the kernel code alone though