21–30 of 68 posts
I really have problems reading this website. You don't have to make a website bloated to make it readable: http://bettermotherfuckingwebsite.com
Have a look at the Chromium/Chrome's extension Just Read before / after https://i.imgur.com/Ihy5wQh.png
I really have problems reading this website. You don't have to make a website bloated to make it readable: http://bettermotherfuckingwebsite.com
This is even better, in my opinion: https://bestmotherfucking.website/ Anyway, I agree. Text should always have a max width. Long lines of text aren't really readable. I use this in my SurfingKeys settings, and use it on a lot of sites to make them more readable: mapkey(' ', 'Centers the current page', function() { document.body.style.cssText = "font-family: sans-serif !important"; document.body.style.cssText += "col…
Earlier quoted context omitted.
This is even better, in my opinion: https://bestmotherfucking.website/ Anyway, I agree. Text should always have a max width. Long lines of text aren't really readable. I use this in my SurfingKeys settings, and use it on a lot of sites to make them more readable: mapkey(' ', 'Centers the current page', function() { document.body.style.cssText = "font-family: sans-serif !important"; document.body.style.cssText += "col…
Disagree, or at least if there's a width that's too wide then I haven't found it yet. Let the user set the width they want in their browser, don't force your own max width on them.
The "two-bit" scheme that fig 12 is for does not have branch history, whereas "two-level adaptive, global" which has fig 14 fits the bill.
Earlier quoted context omitted.
The compiler is (probably) smarter than you. Generally speaking, it will automatically decide which branches are most likely and arrange them accordingly (e.g. for things like for loops and while loops especially, where the biggest gains are). You'd likely gain more performance out of algorithmic changes, and then a number of other processor optimizations (like vectorization and pre-fetch hints) first. Also, CPU manu…
Whether or not it's an early optimization depends on when you add the __builtin_expect, no? Perhaps you already have identified a very hot branch in your code that the compiler fails to treat correctly even though you provided it with profile data.
Very informative. I missed the part about 1500000 BC though – a time when our ancestors lived in the branches of trees? Another beginner-friendly explanation of the effects of branch prediction is this Stack Overflow post which compares a processor to a train: https://stackoverflow.com/questions/11227809/why-is-it-faste...
Top quality article. Now we need one with specifics of how to write code that's aware of this. For instance when do use what compiler hints. Anyone have links or books?
(1) Mark branches as likely/unlikely to be taken. eg. debug code might be marked as unlikely. The Linux kernel does this, and it's explained here (for GCC): https://stackoverflow.com/questions/109710/likely-unlikely-m... [There is some question about whether this is really worthwhile, but I trust the kernel developers ...]
(2) Use profile-guided optimization (PGO), which involves running the program, collecting information about branches and other optimizations, then recompiling with these hints. See eg: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_g...
There are also two negative things to avoid doing:
(3) Some things like threaded code (used by FORTH interpreters) and bytecode interpreters reuse the same piece of code followed by a branch, where the branch jumps to the next high level instruction. This code structure defeats branch prediction.
(4) Don't do strange stuff to the return stack, because modern processors keep track of the return stack and predict branch targets (ie. of RET instructions). A CALL with an unmatched RET or vice versa can defeat branch prediction.
I would say that doing anything else is too difficult, or means that you have to become a compiler writer, but I'm interested to know if there are any other practical techniques.
I really have problems reading this website. You don't have to make a website bloated to make it readable: http://bettermotherfuckingwebsite.com
Have a look at the Chromium/Chrome's extension Just Read before / after https://i.imgur.com/Ihy5wQh.png
The use of previous branch history and branch address as a "context" for prediction reminds me of the very similar technique used for prediction in arithmetic compression as used in e.g. JBIG2, JPEG2000, etc. --- the goal being that, if an event X happens several times in context C, then whenever context C occurs, the probability of X is more likely. Also, since modern CPUs internally have many functional units to wh…
You could do it, but 'work' produces heat. From that point of view a branch predictor /saves/ you from spending the heat of the cases you /don't/ need to have processed. The performance per watt of such a design would probably leave it on the back of a napkin as an educated guess of how costly that would be.