Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch > #2158 > unrolled thread

Memory Transactions per Second.

Back to article view | Back to comp.arch

Contents

  Memory Transactions per Second. "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-06-12 07:57 +0200
    Re: Memory Transactions per Second. MitchAlsup <MitchAlsup@aol.com> - 2011-06-12 08:59 -0700
      Re: Memory Transactions per Second. "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-06-12 23:42 +0200
        Re: Memory Transactions per Second. Robert Redelmeier <redelm@ev1.net.invalid> - 2011-06-13 02:49 +0000
          Re: Memory Transactions per Second. "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-06-13 16:50 +0200
            Re: Memory Transactions per Second. Robert Redelmeier <redelm@ev1.net.invalid> - 2011-06-15 02:49 +0000
              Re: Memory Transactions per Second. "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-06-15 06:55 +0200
    Re: Memory Transactions per Second. "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-06-12 12:51 -0700
      Re: Memory Transactions per Second. MitchAlsup <MitchAlsup@aol.com> - 2011-06-12 14:40 -0700
      Re: Memory Transactions per Second. Jason Riedy <jason@lovesgoodfood.com> - 2011-06-13 09:33 -0400
    Re: Memory Transactions per Second. mr computer <microbrainz@gmail.com> - 2011-06-12 16:06 -0700
      Re: Memory Transactions per Second. "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-06-13 16:29 +0200
        Re: Memory Transactions per Second. mr computer <microbrainz@gmail.com> - 2011-06-13 07:54 -0700
          Re: Memory Transactions per Second. "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-06-13 17:08 +0200
            Re: Memory Transactions per Second. MitchAlsup <MitchAlsup@aol.com> - 2011-06-13 11:50 -0700
              Re: Memory Transactions per Second. "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-06-14 04:07 +0200

#2158 — Memory Transactions per Second.

Hello,

I would like to know how many "random locations" in a memory system can be 
read or written to per second.

This could also be called "memory transactions per second".

The devil is in the details, for example:

A spec might say: 32.000.000.000 bytes/sec of bandwidth.

But if my application for example needs to randomly seek 1 byte per memory 
transaction and the memory system reads/writes 64 bytes per memory 
transaction then the maximum memory transactions for my application would 
be:

32.000.000.000 / 64 = 500.000.000

So how should I read/interpret specifications to be able to determine 
"memory transactions per second", some specs might also not contain all 
details.

Some examples of specs:

http://www.geforce.com/#/Hardware/GPUs/geforce-gt-520/specifications

(Does this mention how many bytes are transferred per memory transaction ??? 
It mentions "bus width 64 bits" which would be 8 bytes, but I have seen 
"cuda documents" which claim each memory transaction is 32 bytes or 64 bytes 
or 128 bytes... so that's much larger ?!?

Example of another spec:

http://products.amd.com/pages/DesktopCPUDetail.aspx?id=65

^ seems quite a shitty spec for programmers ?!? Can you determine based on 
this spec how many memory transactions per second it can do ?

Memory should be considered main ram, caches can be ignored.

Bye,
  Skybuck. 

[toc] | [next] | [standalone]

#2169

Why don't you write a program that simply reads a lot of memory
locations (say 100 Billion) and use the wall clock timer to determine
how much time it takes and from there the real BW. You just have to
make the program access a similar data-set (i.e. random locations) as
the one you want to use in real life.

[toc] | [prev] | [next] | [standalone]

#2177

"
Why don't you write a program that simply reads a lot of memory
locations (say 100 Billion) and use the wall clock timer to determine
how much time it takes and from there the real BW. You just have to
make the program access a similar data-set (i.e. random locations) as
the one you want to use in real life.
"

That's pretty hard to do when I don't have the system don't you think ?

I want to know this information so I can decide which system to buy.

And there are a lot of systems out there ! ;)

Bye,
  Skybuck.

[toc] | [prev] | [next] | [standalone]

#2181

In alt.lang.asm Skybuck Flying <Windows7IsOK@dreampc2006.com> wrote in part:
> "
> Why don't you write a program that simply reads a lot of memory
> locations (say 100 Billion) and use the wall clock timer to determine
> how much time it takes and from there the real BW. You just have to
> make the program access a similar data-set (i.e. random locations) as
> the one you want to use in real life.
> "
> 
> That's pretty hard to do when I don't have the system don't you think ?
> I want to know this information so I can decide which system to buy.
> And there are a lot of systems out there ! ;)

Sure, but a friendly store would let you run test pgms.
Some time ago, I wrote (apologies for the C):



/*  lat10m.c - Measure latency of 10 million fresh memory reads
  (C) Copyright 2005 Robert Redelmeier - GPL v2.0 licence granted  */
int  p[ 1<<21 ] ;
main (void) {
int i, j ;
for ( i=0   ; i < 1<<21   ; i++ )  p[i] = 0x1FFFFF & (i-4095) ;
for ( j=i=0 ; i < 9600000 ; i++ )     j = p[j] ;
return  j ; }


compile: $  gcc -O2 lat10m.c
run:     $  time ./a.out    [multiply user time by 100 to give ns]


Not perfect and it could be modernized -- increase size from 2M to
32M bytes, and more concurrent pointer-chasers `k=p[k]` in the second
`for` to test how may fetches a system can truly run concurrently.
Of course, this uses wall-time, so a quiet system is necessary.


The improvements in this pointer-chasing have been far less 
than CPU clock speed for bandwidth.  An old P3 PC100 system takes
about 200ns , an Atom DDR2 150ns and a Athlon DDR3 80ns per read.


-- Robert

[toc] | [prev] | [next] | [standalone]

#2190

"Robert Redelmeier"  wrote in message news:it3tsk$vg6$2@speranza.aioe.org...

In alt.lang.asm Skybuck Flying <Windows7IsOK@dreampc2006.com> wrote in part:
> "
> Why don't you write a program that simply reads a lot of memory
> locations (say 100 Billion) and use the wall clock timer to determine
> how much time it takes and from there the real BW. You just have to
> make the program access a similar data-set (i.e. random locations) as
> the one you want to use in real life.
> "
>
> That's pretty hard to do when I don't have the system don't you think ?
> I want to know this information so I can decide which system to buy.
> And there are a lot of systems out there ! ;)

"
Sure, but a friendly store would let you run test pgms.
Some time ago, I wrote (apologies for the C):
"

LOL, Next time I will ask the webstore if they wanna run a program like 
that.

Ofcourse there is a problem with your reasoning if it's a new system I might 
not yet know how to program it.

"
/*  lat10m.c - Measure latency of 10 million fresh memory reads
"

Only 10 million ? I think my AMD x2 3800+ dual core can easily do 180 
million per core per second.

So your test is already flawed.

Doesn't that scare you a bit ? ;)

I'd rather have the manufacturer figure it out... if they can't figure it 
out then who can ? ;)

Also another potential problem is with running out of memory.

Suppose the processor is 1 Terrahertz and the memory is only 10 gigabytes 
then one can't simply generate a "unique" table and pointer-chase-walk it.

There is a chance that some of the memory addresses will be cached and the 
more transactions happen the more chance it gets cached.

However as long as the theoretical maximum number of memory transactions is 
less than the ammount of memory then this is for now not yet a problem, but 
could be a problem later on.

A small problem perhaps but none the less. A simple solution would be an 
option in the bios/processor to turn caching off, for proper memory 
benchmarking.

(My pentium III can actually do it, the AMD X2 3800+ cannot as far as I know 
?!)

Perhaps I should run a memtest on my Pentium III one day with caching off... 
just to see what happens ! LOL ;) =D

Bye,
  Skybuck. 

[toc] | [prev] | [next] | [standalone]

#2207

In alt.lang.asm Skybuck Flying <Windows7IsOK@dreampc2006.com> wrote in part:
> LOL, Next time I will ask the webstore if they wanna
> run a program like that.

Why not?  All they need to do under Linux is make the systems
visible via ssh and give you guest login.

> Ofcourse there is a problem with your reasoning if it's a
> new system I might not yet know how to program it.

It'd better have a C compiler somewhere.  Then you
could run my code.

> " /* lat10m.c - Measure latency of 10 million fresh memory
> reads "
>
> Only 10 million ? I think my AMD x2 3800+ dual core can
> easily do 180 million per core per second.

Maybe in-order.  The quad Athlon/DDR3  I tested could
only do 12 million pseudo-random.  I could try it multicore.


> So your test is already flawed.
> Doesn't that scare you a bit ? ;)

Not in the least.  I know it's flawed.  Going to 100m
iterations is an easy change.


> I'd rather have the manufacturer figure it out... if they
> can't figure it out then who can ? ;)

No-one -- memory performance will depend on the DRAM
used (timings).  Which the CPU mfr doesn't control.

> Also another potential problem is with running out of memory.
>
> Suppose the processor is 1 Terrahertz and the memory is only 10
> gigabytes then one can't simply generate a "unique" table and
> pointer-chase-walk it.
>
> There is a chance that some of the memory addresses will be cached
> and the more transactions happen the more chance it gets cached.

Not really -- if I have 10 GB RAM and 10 MB cache, the
chances a random location will be in cache is 0.001 .

-- Robert

[toc] | [prev] | [next] | [standalone]

#2208

"Robert Redelmeier"  wrote in message news:it96ir$kfq$3@speranza.aioe.org...

In alt.lang.asm Skybuck Flying <Windows7IsOK@dreampc2006.com> wrote in part:
> LOL, Next time I will ask the webstore if they wanna
> run a program like that.

"
Why not?  All they need to do under Linux is make the systems
visible via ssh and give you guest login.
"

Way to complex, way to dangerous to connect systems like that.

And they don't trust it and don't have the time for it.

And the systems I am interested in are probably in pieces.

> Ofcourse there is a problem with your reasoning if it's a
> new system I might not yet know how to program it.

"
It'd better have a C compiler somewhere.  Then you
could run my code.
"

Unlikely since I am interested in cuda and other parallel systems which 
require special programming and compilers.

> " /* lat10m.c - Measure latency of 10 million fresh memory
> reads "
>
> Only 10 million ? I think my AMD x2 3800+ dual core can
> easily do 180 million per core per second.

"
Maybe in-order.  The quad Athlon/DDR3  I tested could
only do 12 million pseudo-random.  I could try it multicore.
"

Another big flaw in your test program.

Your benchmark is probably limited by the random number generator.

It make sense.. go view some benchmarks about integer performance.

> So your test is already flawed.
> Doesn't that scare you a bit ? ;)

"
Not in the least.  I know it's flawed.  Going to 100m
iterations is an easy change.
"

Unlikely since it's flaw after flaw.. it needs new approach ;)

It's gonna take you a while to do it properly.

> I'd rather have the manufacturer figure it out... if they
> can't figure it out then who can ? ;)

"
No-one -- memory performance will depend on the DRAM
used (timings).  Which the CPU mfr doesn't control.
"

Timings is a start.

My formula for now is:

MemoryTransactionPerSecond = MemoryClockInHertz / BytesPerTransaction

^ Seems pretty good to me, and pretty simple too ! ;) :)

> Also another potential problem is with running out of memory.
>
> Suppose the processor is 1 Terrahertz and the memory is only 10
> gigabytes then one can't simply generate a "unique" table and
> pointer-chase-walk it.
>
> There is a chance that some of the memory addresses will be cached
> and the more transactions happen the more chance it gets cached.

"
Not really -- if I have 10 GB RAM and 10 MB cache, the
chances a random location will be in cache is 0.001 .
"

Not quite, first of all the table requires 64 bit memory addresses, using 
anything less wouldn't make much sense since that would slow it down even 
further.

Therefore 10 GB must be divided by 8 bytes which is = 1.342.177.280 possible 
memory locations.

The cache itself is probably even worse and stores 64 bytes per cache line 
or so which means:

10 MB / 64 = 163.840 memory locations.

It's highly likely that all cache lines will be overwritten each time and 
that the chance of actually hitting anything is non-existent. This is called 
cache trashing.

So in a way I dismissed my own worries about the cache non the less it's an 
interesting calculation so let's go on.

The real chance of hitting the cache is:

163.840 /  1.342.177.280 = 0,0001220703125

An order of magnitude worse then you thought, another big flaw in your 
reasoning ! ;) =D

One could wonder why caches are added at all there chance of being hit is 
0,0001220703125% in this scenerio... which would be absolutely worthless.

At least the data cache would be worthless... the instruction cache would be 
nice... though perhaps the data cache is also still nice for static pointers 
to tables or so... pointers
which never change... like base addresses.

However the story does not end yet... because you have another flaw in your 
reasoning... another missing factor in the equation.

The chance must be multiplied by the number of tries. This depends on the 
actual speed of the memory system.

I mentioned a 1 THZ processor, so let's keep it realistic and divide that by 
100 for a realistic memory system.

That's 10 GHZ for the memory system, which means 10.000.000.000 * 
0,0001220703125 = 1.220.703 cache hits !

So it turns out the cache is not useless after all ! And does play a big 
roll... what a surprising turn of the story isn't it !

So again another big flaw in your reasoning.

Let's calculate how many additional hz that cache gives:

1.220.703 * 100 = 122.070.312

That's roughly an additional 122 MHZ just because of the cache.

That's not so bad... it could ofcourse be a lot better if the memory seeks 
where within it's range but that's just the point they are not.

Let's see how much procentage that is of the entire memory system:

(122 / 10000) * 100% = 1.22%

1%

That's still a bit too much for my taste ! ;) =D

I hope you not a chip designer or anything, cause your tests suck big time ! 
;) =D

Bye,
  Skybuck =D 

[toc] | [prev] | [next] | [standalone]

#2173

On 6/11/2011 10:57 PM, Skybuck Flying wrote:
> Hello,
>
> I would like to know how many "random locations" in a memory system can
> be read or written to per second.
>
> This could also be called "memory transactions per second".
>
> The devil is in the details, for example:
>
> A spec might say: 32.000.000.000 bytes/sec of bandwidth.

This is a really important metric.  But, unfortunately, it is often hard 
to tell from published specs or benchmarks.

(By the way, a networking guy a few years ago proposed that this become 
a standard metric, which he called (random) address bandwidth - since 
each transaction would have a random address.)

As Mitch says, the only really good way to do this is to run your own 
benchmark.

Certain supercomputer benchmarks have aspects of this..  For example, 
GUPS is related - although it tends to do read-modify-writes.

It is usually quite hard, if not impossible, to determine this from 
published specs of a system.  As you have seen, memory bandwidth is 
usually measured on sequential access patterns, and is barely related to 
random address bandwidth.

You can make a start if you can determine the timing for a worst case 
DRAM access, that requires closing an open page, precharging, accessing, 
etc.

But this does not tell you about the internals inside the processor. 
Cache and queing overheads, etc.

In particular, you need to say whether you want dependent addresses, or 
independent.

If independent, you will eventually be measuring the amount  of 
buffering in the memory system. And the number of memory channnels, DIM 
ranks, etc. - basically, the amount to which you can overlap transactions.

[toc] | [prev] | [next] | [standalone]

#2176

On Jun 12, 2:51 pm, "Andy \"Krazy\" Glew" <a...@SPAM.comp-arch.net>
wrote:
> It is usually quite hard, if not impossible, to determine this from
> published specs of a system.  As you have seen, memory bandwidth is
> usually measured on sequential access patterns, and is barely related to
> random address bandwidth.

The actual delivered BW is ALSO dependent on the logical to physical
mappings deterined by the OS. So on one run you might get X MB/s and
on another you might only get 0.75*X if you end up with physical page
collisions at the DRAMs in the later and not in the former.

Mitch

[toc] | [prev] | [next] | [standalone]

#2186

And Skybuck Flying writes:
> I would like to know how many "random locations" in a memory
> system can be read or written to per second.

And Andy Glew writes:
> This is a really important metric.  But, unfortunately, it is
> often hard to tell from published specs or benchmarks.

A very rough but surprisingly useful upper bound with which I've
been working: Consider the tightest bottleneck between memory
request issuers (CPUs) and servicers (memory) and adjust by the
request concurrency.  It's a bit obvious, but it seems to work
fairly well.

Let R be the rate of memory requests being issued.  Let T be the
density of memory requests per CPU clock cycle (assume global
sync for modeling) to relate it back to the executed code and
number of processors.  Let's say that the bottleneck for issuing
memory operations is the interconnect between CPU and memory.  If
that interconnect issues operations at 220 Mop/s per processor,
that gives you an issuing slope of R_issue = 0.22*T Gop/s.  In
real life, that rate needs some split between reads and writes.

Let's further say the memory's running at 100MHz, giving a peak
service rate of 100 Mop/s per memory unit.  If you have M memory
units, the magic ideal peak service rate is R_ideal = 0.1*M Gop/s
*if* you can keep enough requests in flight.  Let F be the
fraction of latency you can tolerate (number of requests in
flight over number needed to cover latency).  The R_mem = 0.1*M*F
Gop/s.  Yes, this is an overestimate, but surprisingly it doesn't
seem too horrible.

So a given code should be bound by the least of R_issue and
R_mem.  This forms a nice roofline model.  Seems to work
beautifully for predicting when speed-up tops out for simple
graph codes on a Cray XMT (using above specs with twiddles for
bisection bandwidth, need to edit and re-submit paper on it,
damned hard to fit into ten pages).

Still poking at the right bottlenecks to measure on QPI-based
servers (97 outstanding ops, iirc) and the Intel SCC (a ton of
modeling complexity), but the rough shape looks right in
microbenchmarks.  And for these, a request is a cache line and
not a 64-bit work.  Doesn't matter much for a microbenchmark but
does for a graph kernel.

Haven't thought hard about GPGPUs yet, but they're on my to-do
list.  I don't wanna touch graph algorithms there, but some of
our students do, so good. ;)

> As Mitch says, the only really good way to do this is to run
> your own benchmark.

A good one (for the peanut gallery, as many of us have written
this a zillion times) is to generate a long array of 0...BIG,
permute it randomly, and have each thread start walking it
somewhere for a large number of iterations.  Time the walking
part.  You can adjust the requested concurrency by having each
thread start at a few positions and follow each of them in
lock-step.  And then you can poke at the read/write split by
having the threads copy the data into a second array.
-- 
Jason

[toc] | [prev] | [next] | [standalone]

#2179

On Jun 12, 1:57 am, "Skybuck Flying" <Windows7I...@DreamPC2006.com>
wrote:
> Hello,
>
> I would like to know how many "random locations" in a memory system can be
> read or written to per second.
>
> This could also be called "memory transactions per second".
>
> The devil is in the details, for example:
>
> A spec might say: 32.000.000.000 bytes/sec of bandwidth.
>
> But if my application for example needs to randomly seek 1 byte per memory
> transaction and the memory system reads/writes 64 bytes per memory
> transaction then the maximum memory transactions for my application would
> be:
>
> 32.000.000.000 / 64 = 500.000.000
>
> So how should I read/interpret specifications to be able to determine
> "memory transactions per second", some specs might also not contain all
> details.
>
> Some examples of specs:
>
> http://www.geforce.com/#/Hardware/GPUs/geforce-gt-520/specifications
>
> (Does this mention how many bytes are transferred per memory transaction ???
> It mentions "bus width 64 bits" which would be 8 bytes, but I have seen
> "cuda documents" which claim each memory transaction is 32 bytes or 64 bytes
> or 128 bytes... so that's much larger ?!?
>
> Example of another spec:
>
> http://products.amd.com/pages/DesktopCPUDetail.aspx?id=65
>
> ^ seems quite a shitty spec for programmers ?!? Can you determine based on
> this spec how many memory transactions per second it can do ?
>
> Memory should be considered main ram, caches can be ignored.
>
> Bye,
>   Skybuck.

Hello,

    Memory bandwidth can't be accurately measured using the cpu, the
best you could hope for is a realistic average. The problem is that
the memory bus is shared among all devices on the computer. If for
instance there is a dma transfer taking place at the same time you are
doing your memory reads, it will be slowed down. On the CPU side of
things, non sequential reads will cause the cache to be discarded and
you will have to wait for the bus to open up to get your data, which
it will read ahead and fill the cache again. The architecture is
simply designed for sequential reads as that is how most data is
organized, eg: programs. That is why cpus have branch prediction in
order to cache data that is not cached but will be needed on a
conditional/unconditional jump. Probably the best you could hope for
would be a tester that was loaded by the boot loader. Disabling
interrupts in short bursts in order to not lose much interrupts. After
all there would be no way to stop it regardless of the other impacts
of having interrupts disabled. A large sampling would help to minimize
statistical anomalies. Some kind of deep analysis would then be need
to pick out the common data points where the bus was free of
contention, and report that as it's speed. I don't have the talent to
do that, just the conceptualization. I would like to see a tool come
out of this someday.

  Derrick

[toc] | [prev] | [next] | [standalone]

#2189

Memtest comes to mind.

I think it can also test memory, but perhaps it does bandwidth only.

To me it seems you guys are trying to find all kinds of excuses why these 
memory and cpu manufacturer wouldn't have to published some meaning full 
number.

Bye,
  Skybuck.

"mr computer"  wrote in message 
news:25107446-656a-4c71-81ac-f7043e406542@c41g2000yqm.googlegroups.com...

On Jun 12, 1:57 am, "Skybuck Flying" <Windows7I...@DreamPC2006.com>
wrote:
> Hello,
>
> I would like to know how many "random locations" in a memory system can be
> read or written to per second.
>
> This could also be called "memory transactions per second".
>
> The devil is in the details, for example:
>
> A spec might say: 32.000.000.000 bytes/sec of bandwidth.
>
> But if my application for example needs to randomly seek 1 byte per memory
> transaction and the memory system reads/writes 64 bytes per memory
> transaction then the maximum memory transactions for my application would
> be:
>
> 32.000.000.000 / 64 = 500.000.000
>
> So how should I read/interpret specifications to be able to determine
> "memory transactions per second", some specs might also not contain all
> details.
>
> Some examples of specs:
>
> http://www.geforce.com/#/Hardware/GPUs/geforce-gt-520/specifications
>
> (Does this mention how many bytes are transferred per memory transaction 
> ???
> It mentions "bus width 64 bits" which would be 8 bytes, but I have seen
> "cuda documents" which claim each memory transaction is 32 bytes or 64 
> bytes
> or 128 bytes... so that's much larger ?!?
>
> Example of another spec:
>
> http://products.amd.com/pages/DesktopCPUDetail.aspx?id=65
>
> ^ seems quite a shitty spec for programmers ?!? Can you determine based on
> this spec how many memory transactions per second it can do ?
>
> Memory should be considered main ram, caches can be ignored.
>
> Bye,
>   Skybuck.

Hello,

    Memory bandwidth can't be accurately measured using the cpu, the
best you could hope for is a realistic average. The problem is that
the memory bus is shared among all devices on the computer. If for
instance there is a dma transfer taking place at the same time you are
doing your memory reads, it will be slowed down. On the CPU side of
things, non sequential reads will cause the cache to be discarded and
you will have to wait for the bus to open up to get your data, which
it will read ahead and fill the cache again. The architecture is
simply designed for sequential reads as that is how most data is
organized, eg: programs. That is why cpus have branch prediction in
order to cache data that is not cached but will be needed on a
conditional/unconditional jump. Probably the best you could hope for
would be a tester that was loaded by the boot loader. Disabling
interrupts in short bursts in order to not lose much interrupts. After
all there would be no way to stop it regardless of the other impacts
of having interrupts disabled. A large sampling would help to minimize
statistical anomalies. Some kind of deep analysis would then be need
to pick out the common data points where the bus was free of
contention, and report that as it's speed. I don't have the talent to
do that, just the conceptualization. I would like to see a tool come
out of this someday.

  Derrick 

[toc] | [prev] | [next] | [standalone]

#2191

On Jun 13, 10:29 am, "Skybuck Flying" <Windows7I...@DreamPC2006.com>
wrote:
> Memtest comes to mind.
>
> I think it can also test memory, but perhaps it does bandwidth only.
>
> To me it seems you guys are trying to find all kinds of excuses why these
> memory and cpu manufacturer wouldn't have to published some meaning full
> number.
>
> Bye,
>   Skybuck.
>
> "mr computer"  wrote in message
>
> news:25107446-656a-4c71-81ac-f7043e406542@c41g2000yqm.googlegroups.com...
>
> On Jun 12, 1:57 am, "Skybuck Flying" <Windows7I...@DreamPC2006.com>
> wrote:
>
>
>
>
>
>
>
>
>
> > Hello,
>
> > I would like to know how many "random locations" in a memory system can be
> > read or written to per second.
>
> > This could also be called "memory transactions per second".
>
> > The devil is in the details, for example:
>
> > A spec might say: 32.000.000.000 bytes/sec of bandwidth.
>
> > But if my application for example needs to randomly seek 1 byte per memory
> > transaction and the memory system reads/writes 64 bytes per memory
> > transaction then the maximum memory transactions for my application would
> > be:
>
> > 32.000.000.000 / 64 = 500.000.000
>
> > So how should I read/interpret specifications to be able to determine
> > "memory transactions per second", some specs might also not contain all
> > details.
>
> > Some examples of specs:
>
> >http://www.geforce.com/#/Hardware/GPUs/geforce-gt-520/specifications
>
> > (Does this mention how many bytes are transferred per memory transaction
> > ???
> > It mentions "bus width 64 bits" which would be 8 bytes, but I have seen
> > "cuda documents" which claim each memory transaction is 32 bytes or 64
> > bytes
> > or 128 bytes... so that's much larger ?!?
>
> > Example of another spec:
>
> >http://products.amd.com/pages/DesktopCPUDetail.aspx?id=65
>
> > ^ seems quite a shitty spec for programmers ?!? Can you determine based on
> > this spec how many memory transactions per second it can do ?
>
> > Memory should be considered main ram, caches can be ignored.
>
> > Bye,
> >   Skybuck.
>
> Hello,
>
>     Memory bandwidth can't be accurately measured using the cpu, the
> best you could hope for is a realistic average. The problem is that
> the memory bus is shared among all devices on the computer. If for
> instance there is a dma transfer taking place at the same time you are
> doing your memory reads, it will be slowed down. On the CPU side of
> things, non sequential reads will cause the cache to be discarded and
> you will have to wait for the bus to open up to get your data, which
> it will read ahead and fill the cache again. The architecture is
> simply designed for sequential reads as that is how most data is
> organized, eg: programs. That is why cpus have branch prediction in
> order to cache data that is not cached but will be needed on a
> conditional/unconditional jump. Probably the best you could hope for
> would be a tester that was loaded by the boot loader. Disabling
> interrupts in short bursts in order to not lose much interrupts. After
> all there would be no way to stop it regardless of the other impacts
> of having interrupts disabled. A large sampling would help to minimize
> statistical anomalies. Some kind of deep analysis would then be need
> to pick out the common data points where the bus was free of
> contention, and report that as it's speed. I don't have the talent to
> do that, just the conceptualization. I would like to see a tool come
> out of this someday.
>
>   Derrick

Not excuses, just the awareness of the problems that are involved.
Wouldn't it be a little ridiculous to walk in to a best buy and tell
them you want to run a program on all of their computers in order to
find the best one? Wouldn't they be worried about that program being
more than a tester, like maybe a virus? If you are that worried,
custom build a machine, test it, if you don't like the performance
send it back and get another. Toms Hardware Guide is an excellent
resource as they test for performance issues, I remember reading how
they found that a faster intel chip was slower than a slower chip of
the same type. Also buying memory based on it's timing capabilities
can help, it tends to cost more as they are targeting it towards
'gamers'.

[toc] | [prev] | [next] | [standalone]

#2192

This assumes benchmarks are available.

Last time I checked the quality of "benchmarking" websites has gone done.

I'll be lucky if I find a benchmark for my hardware... especially if it's 
not the "high end" "in the picture" "in the media" "the hyped" graphics 
cards.

I'll be lucky if the benchmark includes something like "memory transaction 
per second" or anything similar ;)

Benchmarks like: "gje this cards runs game x at fps y doesn't really cut it" 
! ;) =D

Bye,
  Skybuck.

[toc] | [prev] | [next] | [standalone]

#2195

On Jun 13, 10:08 am, "Skybuck Flying" <Windows7I...@DreamPC2006.com>
wrote:
> This assumes benchmarks are available.
>
> Last time I checked the quality of "benchmarking" websites has gone done.

Exactly how many dollars have you sent any of them their way because
you have borrowed and used some resource they support?

Mitch

[toc] | [prev] | [next] | [standalone]

#2197

"MitchAlsup"  wrote in message 
news:238ca222-ab88-4ffa-97c7-e1752302f496@dq9g2000vbb.googlegroups.com...

On Jun 13, 10:08 am, "Skybuck Flying" <Windows7I...@DreamPC2006.com>
wrote:
> This assumes benchmarks are available.
>
> Last time I checked the quality of "benchmarking" websites has gone done.

"
Exactly how many dollars have you sent any of them their way because
you have borrowed and used some resource they support?
"

None, but do ask their advertiser that question ! ;) =D

Bye,
  Skybuck =D

[toc] | [prev] | [standalone]

Back to top | Article view | comp.arch

csiph-web