Well this is a closed system. Without memory-level parallelism, then I
can certainly see how the memory bandwidth is proportional to latency.
Philip Garcia wrote:
I have a problem I've been trying to solve. When I'm using ruby to
measure my memory performance, I end up in a situation where my
memory bandwidth for a single stream of data is directly proportional
to the memory latency I have set. I am wondering if this situation
is created by design, or if there's something I'm overlooking.
The overall memory bandwidth wouldn't be a problem if I were
accessing multiple streams of memory, however when I'm accessing a
single stream, I end up in a situation where reading the first cache
line from stream S_0 takes the full memory latency, and all
subsequent reads from that stream will also incur the full memory
latency.
Does anyone know of a "simple" way to change how this is? In
theory, the second access should be much faster than the first, and
should be a factor of only the memory bandwidth. Is anything like
this modeled within ruby, and if not does anyone know where it would
make sense to add such a thing?
One way to offload this problem is through the use of prefetching,
however I think I'd need to heavily modify how I do my "hardware"
prefetching in my code.
I just wanted to see if anyone has come up with a reasonable solution
to this problem, or if my best luck is to see to it that the hardware
is issuing prefetches sufficiently early to avoid the bandwidth issues.
Phil
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
|
![[Computer Systems Lab]](https://www-auth.cs.wisc.edu/pics/csl_logo.gif){kind=logo}