SoylentNews

Compiler Jump Threading

posted by martyb on Monday November 02 2015, @04:31AM   
from the next-up:-jump-jiving dept.

Phoenix666 writes:

The "jump threading" compiler optimization (aka -fthread-jump) turns conditional into unconditional branches on certain paths at the expense of code size. For hardware with branch prediction, speculative execution, and prefetching, this can greatly improve performance. However, there is no scientific publication or documentation at all. The Wikipedia article is very short and incomplete.

The linked article has an illustrated treatment of common code structures and how these optimizations work.

---

Original Submission

• Re:hmm...(Score: 2) by jdccdevel on Wednesday November 04 2015, @01:06AM

  by jdccdevel (1329) on Wednesday November 04 2015, @01:06AM (#258221) Journal

  To me it sounds like you are sticking an entire class's worth of functionality and variables inside of one single public method.

  This coding style is mostly useful to keep things straight when you don't have an Object-oriented language. O-O programming has a coding methodology, language features, and a lot of "syntactic sugar" which changes code maintenance dramatically.

  It sounds to me like you either need to reduce the number of returns to one location or extract that logic into another function.

  The coding style I was originally commenting on is designed to "reduce the number of returns to one location". Coding logic doesn't always make that easy. Error checking, for example, can halt the function's logic in any number of locations where you want the function to return right away. Backing out of some logic trees and nested loops can be really complicated. Goto makes it easy.

  Remember, this is C, so there is no "exception" construct in the language. You could think of this coding style as using "goto" as a primitive form of exception handling, to make sure everything is cleaned up before the function returns. The alternative is to duplicate the cleanup code everywhere an error could occur (which is, I'm sure you'll agree, fragile. Not to mention bad coding practice due to code duplication.)

  My idea was that if you had duplicate code because of cleanups, you could extract that cleanup to a function to prevent someone changing one code bit and not another

  Extracting the logic to another function also doesn't make any sense, as the sole purpose of that function would be to "clean up" for the other function. It has the same fragility as the code duplication we are trying to avoid (you have to remember to always call the "clean up" function before you return instead of just "return".) and it would be a real pain to maintain. How do you ensure that both functions are kept in sync? This is a maintenance nightmare. Not the least because every time you change something, the api for the "cleanup" function could change, necessitating you to change every line of code where the cleanup is called. (which, thanks to error handling, could be in dozens of different places.)

  No, the "goto done" coding style is much simpler to follow, easier to audit, and significantly better overall for languages like C.

  Unfortunately, many people see the "goto", and assume it has to be bad because someone told them "goto is bad, and makes code unmaintainable." Which is unfortunately something that every coding instructor will say to beginners, because a beginner will almost never use goto properly.

  Parent

  Starting Score:	1		point
  Karma-Bonus Modifier		+1
  Total Score:		2