• Manfred Nowak (4/4) Aug 12 2007 As some may know current DDR dual channel configurations access 128
• Regan Heath (5/9) Aug 12 2007 std.bitarray?
• Manfred Nowak (9/10) Aug 14 2007 I post in the learn-group because do not know exactly what the point
• Don Clugston (6/19) Aug 14 2007 It would, if there was no cache. In fact, ALL access from RAM is very sl...
• Manfred Nowak (9/11) Aug 14 2007 Seems not to be true shortly. Instead:
• Manfred Nowak (67/69) Aug 15 2007 Both not confirmed!!!
• Witold Baryluk (8/12) Aug 12 2007 It isn't. 128 is used only by hardware. If it will be avaible to
• =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (4/8) Aug 14 2007 Write the code in C, and call it from D ?

Manfred Nowak <svv1999 hotmail.com> writes:

As some may know current DDR dual channel configurations access 128 
bits in each transaction.

How has this to be modelled in D?

-manfred

Regan Heath <regan netmail.co.nz> writes:

Manfred Nowak wrote:
 As some may know current DDR dual channel configurations access 128 
 bits in each transaction.
 
 How has this to be modelled in D?

std.bitarray?

ucent? (once it is implemented)

Or am I missing the point entirely?

Regan

Manfred Nowak <svv1999 hotmail.com> writes:

Regan Heath wrote

 Or am I missing the point entirely?

I post in the learn-group because do not know exactly what the point 
is.

At first glance it seems that the current hardware emulates bytes of 
size 8 bits on main memory with a granularity of 128 bits.

If this is true then a severe slowdown should happen by exceeding the 
128 bit boundary for consecutive accesses of 8 bit bytes---and 
algorithms as well as the compiler should take this into account.

-manfred

Don Clugston <dac nospam.com.au> writes:

Manfred Nowak wrote:
 Regan Heath wrote
 
 Or am I missing the point entirely?

 
 I post in the learn-group because do not know exactly what the point 
 is.
 
 At first glance it seems that the current hardware emulates bytes of 
 size 8 bits on main memory with a granularity of 128 bits.
 
 If this is true then a severe slowdown should happen by exceeding the 
 128 bit boundary for consecutive accesses of 8 bit bytes---and 
 algorithms as well as the compiler should take this into account.

It would, if there was no cache. In fact, ALL access from RAM is very slow.
The accessing works like this:

RAM -> L2 cache -> L1 cache -> CPU.

The 128 bits only affects the speed at which you load from RAM into L2 cache.
But normally you try to stay in the L1 cache, so it doesn't matter.

Manfred Nowak <svv1999 hotmail.com> writes:

Don Clugston wrote

 RAM -> L2 cache -> L1 cache -> CPU

Seems not to be true shortly. Instead:

RAM -> L1 --------------|
       | -> L2----------|       
             |-> L3 -> CPU

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2939&p=9


 But normally you try to stay in the L1 cache, so it doesn't matter.

Trying to stay in the L1 cache at least needs information about how big 
the L1 cache is. Where can this information be entered?

-manfred

Manfred Nowak <svv1999 hotmail.com> writes:

Don Clugston wrote

 If this is true then a severe slowdown should happen

 It would, if there was no cache.

Both not confirmed!!!

This table shows the quotient Q for the slow down for some access 
differences delta, compared to an access difference of 1 Byte. 

delta:  Q
------------
    2:  0.98
    3:  1.04
    4:  1.06
    5:  1.20
    6:  1.35
    7:  1.53
    8:  1.68
    9:  1.52
   10:  1.66
   12:  2.23
   14:  2.73
   16:  3.21
   18:  3.64
   20:  4.24
   23:  5.15
   26:  6.25
   29:  7.15
   32:  8.31
   36:  9.31
   40: 10.30
   45: 10.97
   50: 11.89
   56: 12.96
   62: 13.80
   69: 14.37
   76: 14.96
   84: 15.90
   93: 16.62
  103: 16.72
  114: 14.08
  126: 10.49
  139:  9.80
  153:  9.96
  169: 10.12
  186: 10.33
  205: 10.46
  226: 10.82
  249: 10.87
  274: 11.16
  302: 11.55
  333: 11.60
  367: 11.83
  404: 12.26
  445: 12.68
  490: 13.25
  540: 13.13
  595: 12.96
  655: 13.02
  721: 13.40
  794: 13.49
  874: 14.11
  962: 14.72
 1059: 14.89
 1165: 15.23
 1282: 15.52
 1411: 16.05
 1553: 16.78
 1709: 17.44
 1880: 18.11

Tested on an Athlon64 X2 4200, winXP, dmd1.016

-manfred 

Witold Baryluk <baryluk smp.if.uj.edu.pl> writes:

Dnia Sun, 12 Aug 2007 20:39:24 +0000 (UTC)
Manfred Nowak <svv1999 hotmail.com> napisa=B3/a:

 As some may know current DDR dual channel configurations access 128=20
 bits in each transaction.
=20
 How has this to be modelled in D?

It isn't. 128 is used only by hardware. If it will be avaible to
programer it will be called "cent and ucent".

--=20
Witold Baryluk
MAIL: baryluk smp.if.uj.edu.pl, baryluk mpi.int.pl
JID: movax jabber.autocom.pl

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Manfred Nowak wrote:

 As some may know current DDR dual channel configurations access 128 
 bits in each transaction.
 
 How has this to be modelled in D?

Write the code in C, and call it from D ?

At least until it allows 128-bit types...

--anders