Re: [Gems-users] Different numbers of instructions, msgs, etc when running Ruby on the same workload

[Mike Marty <mikem@xxxxxxxxxxx>]

If your routing algorithm changes the timing in any way, this can and 
usually will affect the execution path of a multithreaded program
--Mike


Lide Duan wrote:
> Hello there,
>
> I have got some confusion about Ruby running on the same checkpoint...
>
> Basically I modified the routing algorithm utilized in the on-chip
> interconnect of Ruby, and compared the output results with the unmodified
> Ruby version. For both simulations, the checkpoint has been run from one
> magic instruction to the other, implying the same amount of work. I assumed
> that the msgs injected into the interconnect (from the components) should be
> the same for both cases because the only difference is the routing
> algorithm, which should not affect the behaviors on the cache level since
> all the msgs finally arrive to their corresponding destinations.
>
> However, the numbers of the injected msgs of the two runs have 5%
> difference, and the msgs generated in the interconnect (all of them are
> Invalidate_Control, to my observation) have more the 10% difference. The
> numbers of instructions of the two simulations are also different (but not
> much) although the two runs were from the same start point to the same end
> point.
>
> On the other hand, if I run Ruby twice without making any modification
> between the two runs (i.e. the same Ruby on the same workload), the results
> are exactly the same. So I don't think there is any random effect to cause
> the above difference. Then, are the results I have got reasonable?
>
> Thanks,
> Lide
>
>   
> ------------------------------------------------------------------------
> _______________________________________________
> 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.
>
>