AMD recommends some coding styles like:
- favor conditional execution instructions over branches
- make code paths as straight as possible
- avoid using more than two branches per 16 byte window, in case of
poor temporal locality
- in general, avoid using more than three branches per 16 byte window
- use far branches only when absolutely necessary
- limit recursivity to a single call site
- ensure that for each call a corresponding return exists
- avoid having code and data mixed up in the same cache line
- dont use self modifying code
http://developer.amd.com/media/SWOpt2FetchBranchPred0208.wmv
[cited 2008/04/30]
How to achieve this in D?
-manfred

AMD recommends some coding styles like:
- favor conditional execution instructions over branches
- make code paths as straight as possible
- avoid using more than two branches per 16 byte window, in case of
poor temporal locality
- in general, avoid using more than three branches per 16 byte window
- use far branches only when absolutely necessary
- limit recursivity to a single call site
- ensure that for each call a corresponding return exists
- avoid having code and data mixed up in the same cache line
- dont use self modifying code
http://developer.amd.com/media/SWOpt2FetchBranchPred0208.wmv
[cited 2008/04/30]
How to achieve this in D?
-manfred

I think most of this is more relevant to compiler writers than to programmers.
In any case, all but a few of these can't be directly influenced from code. So
I guess it comes down to "trust the compiler" ^^
--downs

I think most of this is more relevant to compiler writers than to
programmers.

terranium wrote:

Read AMD's "Source level optimizations" recommendation.

One might be able to notice the contradiction and please notice that
AMD writes in Chapter 2.2:
| Source-code transformations interact with a compilerís code
| generator, making it difficult to control the generated machine
| code from the source level.
http://www.amd.com/us-
en/assets/content_type/white_papers_and_tech_docs/40546.pdf
[cited 2008/05/05]
Furthermore downs wrote:

In any case, all but a few of these can't be directly influenced
from code.

I believe that good advertising for a language that claims to support
high level abstractions and bare bones access to hardware would be
something like:
| Code in this language allows for adapting to specific processors
| without disturbing the expressiveness for higher level
| abstractions.
Have a look on an example from chapter 2.6:
| if (a <= max && a >= min && b <= max && b >= min)
seems to be some canonical code for the range checks.
But whenever a respective b are likely to be out of range AMD
recommends:
| if (a > max || a < min || b > max || b < min)
Reading the latter version seems to require much more capability in
recognising the underlying abstraction. Of course this would not be
necessary when the language would allow for an annotation like:
if (a <= max && a >= min && b <= max && b >= min; apply !)
-manfred

One might be able to notice the contradiction and please notice that
AMD writes in Chapter 2.2:
| Source-code transformations interact with a compilerís code
| generator, making it difficult to control the generated machine
| code from the source level.

Furthermore downs wrote:

In any case, all but a few of these can't be directly influenced
from code.