www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Adapting to a specific processor

reply Manfred Nowak <svv1999 hotmail.com> writes:
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
May 01 2008
next sibling parent downs <default_357-line yahoo.de> writes:
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
May 01 2008
prev sibling parent reply terranium <spam here.lot> writes:
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.
May 02 2008
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
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
May 04 2008
parent terranium <spam here.lot> writes:
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.


May 07 2008