On 10/7/2022 1:03 PM, Aritra Bagchi wrote:
Hi all,
Any suggestions on this are most helpful.
Thanks and regards,
Aritra
My guess is that is is because the non-unrolled loop
has a test of i against 1000 before each access to A[i].
That test guards the load, so must be completed before
the load can proceed. It could also be because of the
way j is used - the next update cannot proceed until
the last one finishes. It might be helpful to loop
at the actual instructions involved, but the control
dependency could be an issue.
The unrolled loop avoids both of these possible
dependencies.
I further observe that if we are talking about an
Intel processor. those processor handle loads in the
order the program presents them. Not sure if that
has any impact here. Also unsure whether cpu
speculative execution plays a role (which would actually
improve matters).
Best - Eliot Moss
On Thu, Oct 6, 2022 at 6:01 PM Aritra Bagchi <bagchi95ari...@gmail.com
<mailto:bagchi95ari...@gmail.com>> wrote:
Hi all,
*for (i = 0; i < 1000; i++) {*
* j = j + A[ i ]*
*}*
Suppose such a loop program is executed on gem5 (single-core execution,
with O3 CU model). In
that case, the memory hierarchy gets to see only one access at a time, e.g.
only after A[ k ] is
completed, A [ k + 1 ] access is sent to the memory hierarchy. Whereas, if
the loop is unrolled
(on i), multiple memory accesses are seen simultaneously. Why is that so?
The memory loads could
be serviced independently (even without unrolling the loop), so why is gem5
taking such a
conservative approach?
Any form of help/suggestion is highly appreciated.
Thanks and regards,
Aritra Bagchi
Research Scholar,
Department of Computer Science and Engineering,
Indian Institute of Technology Delhi
_______________________________________________
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
_______________________________________________
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
