• Manfred Nowak <svv1999 hotmail.com> May 01 2008
• downs <default_357-line yahoo.de> May 01 2008
• terranium <spam here.lot> May 02 2008
• Manfred Nowak <svv1999 hotmail.com> May 04 2008
• terranium <spam here.lot> May 07 2008

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

Manfred Nowak wrote:
 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

Manfred Nowak Wrote:

 AMD recommends some coding styles like:
 
 - make code paths as straight as possible
 - in general, avoid using more than three branches per 16 byte window
 - limit recursivity to a single call site


 How to achieve this in D?


Read AMD's "Source level optimizations" recommendation.

downs wrote:
 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



  

Manfred Nowak Wrote:

 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.