Replies: 2 comments 1 reply
-
I do not think this is a good solution. All the components in the memory hierarchy use the A better solution is to use a tracer to trace the DRAMs, or just to add a counter in the DRAM code and dump it at the end of the simulation. |
Beta Was this translation helpful? Give feedback.
0 replies
-
If the cache hits,it doesn't trigger a read or write operation on the DRAM?
If i trace DRAM, i still can not get the right number of memory access
…On Thu, Jul 25, 2024 at 11:35 PM Yifan Sun ***@***.***> wrote:
I do not think this is a good solution. All the components in the memory
hierarchy use the ReadRequestBuilder. The CU can use it to generate
requests for the L1 cache; the L1 cache needs to generate new requests for
L2 caches.
A better solution is to use a tracer to trace the DRAMs, or just to add a
counter in the DRAM code and dump it at the end of the simulation.
—
Reply to this email directly, view it on GitHub
<#86 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BJG4ZSZ54VBI4TEGPUNMKBDZOELKNAVCNFSM6AAAAABLIBYTIOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMJVGA3DANA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Mr. Sun
I want to know how many times per second the GPU can access memory when running a benchmark,
so I record how many readrequests was generated in the ReadReqBuilder method in protocol.go, and then divide it by the kernel time to get an average of 2 billion readreqs generated per second, is this the right figure?
Beta Was this translation helpful? Give feedback.
All reactions