Skip to main content
Spelling and grammar; inline link
Source Link
Toby Speight
  • 1.7k
  • 1
  • 14
  • 31

DISCLAIMER: I'm no "expert", but I have been around the block quite a few times.

This should have occurred to me earlier, but being otherwise distracted, never articulated fully my thoughts.

I'll give you some background:

  1. Optimisations are very likely heuristic. If > 50% of specific sequences of code does x, rather than y, then optimise for that scenario. Rinse and repeat. This was something that Systems Programmers on mainframes did for a living to eekeke out some more CPU cycles.
  2. We're not just talking about C here. It's done in many placeslanguages...
  3. Processors have (adaptive) branch prediction logic/caches (see https://stackoverflow.com/questions/24852649/how-does-the-branch-predictor-know-if-it-is-not-correctHow does the branch predictor know if it is not correct?)
  4. VM'sVMs have optimising compilers which alter the underlying runtime bytecode to speed things up a bit by switching whether a branch needs to be made (possibly costing slightly more CPU cycles to fetch more memory if the branch is far away(see 3))
  5. PossibleIt's possible that some higher-level languages could be leveraging functionality from c/c++C or C++ compilers... meaning the same "boilerplate" code is shared acr ossacross many languages.
  6. No doubt there are many many more that I'd care to know.
  7. The moral of the story...: you either have to be lucky, or FULLY understand what's going on in order to crack performance optimisation.

DISCLAIMER: I'm no "expert", but I have been around the block quite a few times.

This should have occurred to me earlier, but being otherwise distracted, never articulated fully my thoughts.

I'll give you some background:

  1. Optimisations are very likely heuristic. If > 50% of specific sequences of code does x, rather than y, then optimise for that scenario. Rinse and repeat. This was something that Systems Programmers on mainframes did for a living to eek out some more CPU cycles.
  2. We're not just talking about C here. It's done in many places...
  3. Processors have (adaptive) branch prediction logic/caches (see https://stackoverflow.com/questions/24852649/how-does-the-branch-predictor-know-if-it-is-not-correct)
  4. VM's have optimising compilers which alter the underlying runtime bytecode to speed things up a bit by switching whether a branch needs to be made (possibly costing slightly more CPU cycles to fetch more memory if the branch is far away(see 3))
  5. Possible that some higher-level languages could be leveraging functionality from c/c++ compilers... meaning the same "boilerplate" code is shared acr oss many languages.
  6. No doubt there are many many more that I'd care to know.
  7. The moral of the story... you either have to be lucky, or FULLY understand what's going on in order to crack performance optimisation.

DISCLAIMER: I'm no "expert", but I have been around the block quite a few times.

This should have occurred to me earlier, but being otherwise distracted, never articulated fully my thoughts.

I'll give you some background:

  1. Optimisations are very likely heuristic. If > 50% of specific sequences of code does x, rather than y, then optimise for that scenario. Rinse and repeat. This was something that Systems Programmers on mainframes did for a living to eke out some more CPU cycles.
  2. We're not just talking about C here. It's done in many languages...
  3. Processors have (adaptive) branch prediction logic/caches (see How does the branch predictor know if it is not correct?)
  4. VMs have optimising compilers which alter the underlying runtime bytecode to speed things up a bit by switching whether a branch needs to be made (possibly costing slightly more CPU cycles to fetch more memory if the branch is far away(see 3))
  5. It's possible that some higher-level languages could be leveraging functionality from C or C++ compilers... meaning the same "boilerplate" code is shared across many languages.
  6. No doubt there are many many more that I'd care to know.
  7. The moral of the story: you either have to be lucky, or FULLY understand what's going on in order to crack performance optimisation.
Source Link

DISCLAIMER: I'm no "expert", but I have been around the block quite a few times.

This should have occurred to me earlier, but being otherwise distracted, never articulated fully my thoughts.

I'll give you some background:

  1. Optimisations are very likely heuristic. If > 50% of specific sequences of code does x, rather than y, then optimise for that scenario. Rinse and repeat. This was something that Systems Programmers on mainframes did for a living to eek out some more CPU cycles.
  2. We're not just talking about C here. It's done in many places...
  3. Processors have (adaptive) branch prediction logic/caches (see https://stackoverflow.com/questions/24852649/how-does-the-branch-predictor-know-if-it-is-not-correct)
  4. VM's have optimising compilers which alter the underlying runtime bytecode to speed things up a bit by switching whether a branch needs to be made (possibly costing slightly more CPU cycles to fetch more memory if the branch is far away(see 3))
  5. Possible that some higher-level languages could be leveraging functionality from c/c++ compilers... meaning the same "boilerplate" code is shared acr oss many languages.
  6. No doubt there are many many more that I'd care to know.
  7. The moral of the story... you either have to be lucky, or FULLY understand what's going on in order to crack performance optimisation.