Re: [Gems-users] 答复: 答复: What happens if NUMBER_OF_VIRTUAL_NETWORKS is greater than needed?

[Ikhwan Lee <ikhwan@xxxxxxxxxxxxxxx>]

Oh, I missed the 'for' statement at line-11. Yes, you're right. And
I'm stuck again =(.

2010/4/8 付斌章 <fubinzhang@xxxxxxxxx>:
> Line-11, line-14, and line-15 guarantee that the empty VCs belonging to
> "extra" VN will be skipped
>
> 1. void SWallocator_d::arbitrate_inports()
> 2. {
> 3       // First I will do round robin arbitration on a set of input vc
> requests
> 4        for(int inport = 0; inport < m_num_inports; inport++)
> 5        {
> 6                int invc = m_round_robin_inport[inport]; //get the vc id
> just before the vc we will first try, because invc is added again in line-13
> 7                m_round_robin_inport[inport]++;
> 8
> 9                if(m_round_robin_inport[inport] >= m_num_vcs)
> 10                        m_round_robin_inport[inport] = 0;
> 11      for(int j = 0; j < m_num_vcs; j++)// This guarantees that every
> input vc will be checked
> 12              {
> 13                      invc++;
> 14                      if(invc >= m_num_vcs)
> 15                              invc = 0; // wrap around..
> 16                      if(m_input_unit[inport]->need_stage(invc, ACTIVE_,
> SA_) && m_input_unit[inport]->has_credits(invc))
> 17                      { // find a "need process" vc
> 18                              if(is_candidate_inport(inport, invc))// this
> line is used to keep packets' order, ignor it
> 19                              {
> 20                                      int outport =
> m_input_unit[inport]->get_route(invc);
> 21                                      m_local_arbiter_activity++;
> 22                                      m_port_req[outport][inport] = true;
> 23                                      m_vc_winners[outport][inport]= invc;
> 24                                      break; // got one vc winner for this
> port
> 25                              }
> 26                      }
> 27              }
> 28        }
> 29}
>
> -----邮件原件-----
> 发件人: gems-users-bounces@xxxxxxxxxxx
> [mailto:gems-users-bounces@xxxxxxxxxxx] 代表 Ikhwan Lee
> 发送时间: 2010年4月8日 13:43
> 收件人: Gems Users
> 主题: Re: [Gems-users] 答复: What happens if NUMBER_OF_VIRTUAL_NETWORKS is
> greater than needed?
>
> The swtich allocator wakes up, checks exactly one VC for each input
> port in a round-robin manner, and goes back to sleep. So, empty VCs
> associated with the extra VN will actually consume extra cycle, which
> kind of explains why VN=4 is slightly faster than VN=5 in my
> simulations.
>
> Ikhwan
>
> 2010/4/8 付斌章 <fubinzhang@xxxxxxxxx>:
>> If the "extra" VN is empty, it does not affect the performance since empty
>> VCs are always skipped.
>>
>> -----邮件原件-----
>> 发件人: gems-users-bounces@xxxxxxxxxxx
>> [mailto:gems-users-bounces@xxxxxxxxxxx] 代表 Ikhwan Lee
>> 发送时间: 2010年4月8日 13:18
>> 收件人: Gems Users
>> 主题: Re: [Gems-users] What happens if NUMBER_OF_VIRTUAL_NETWORKS is
> greater
>> than needed?
>>
>> I'm using the GARNET fixed pipeline model, and it looks like the
>> round-robin arbitration could indeed cause different executions.
>> SWallocator_d::arbitrate_inports() function uses m_num_vcs to wrap
>> around, and since m_num_vcs = m_virtual_networks*m_vc_per_vnet,
>> different number of VNs could lead to different timing.
>>
>> Thanks for pointing that out.
>>
>> Ikhwan
>>
>> On Wed, Apr 7, 2010 at 11:36 PM, Niket Agarwal <niketa@xxxxxxxxxxxxx>
> wrote:
>>> What interconnect model you are using? In GARNET, most arbitrations
> across
>>> different VNs are independent. So, having extra unused VNs should not
>>> matter. Having said that, I can imagine round-robin arbitrations inside
>> the
>>> router taking separate decisions with different number of VNs. This could
>>> lead to different order of packet delivery and hence different
> executions.
>>>
>>> -Niket
>>>
>>> On 04/08/2010 12:31 AM, Dan Gibson wrote:
>>>
>>> Well, actually the same argument applies. As far as I understand the
>>> situation, your two runs (VN=4 and VN=5) could have had different
>>> g_RANDOM_SEEDs, which could account for the difference in performance.
>>> Admittedly, I'm no expert on Ruby's interconnect, so I don't know what
> the
>>> actual effect of extra VCs would be... but it seems like the kind of
> thing
>>> that would have an effect.
>>>
>>> Regards,
>>> Dan
>>>
>>> On Wed, Apr 7, 2010 at 8:57 PM, Ikhwan Lee <ikhwan@xxxxxxxxxxxxxxx>
> wrote:
>>>>
>>>> Dan,
>>>> I was not trying to compare the performance of VN=4 and VN=5. I was
>>>> rather concerned about the integrity of the simulation results since I
>>>> could not understand why they weren't exactly the same. But I do
>>>> appreciate your advice. Thanks,
>>>> mos
>>>> Ikhwan
>>>>
>>>> On Tue, Apr 6, 2010 at 8:17 AM, Dan Gibson <degibson@xxxxxxxx> wrote:
>>>> > Ikhwan,
>>>> > Let me put it another way. In multiprocessor simulations, no two runs
>>>> > are
>>>> > different in a /statistically significant way/. Only when two
>>>> > configurations
>>>> > (e.g., VN=4, VN=5) are run each MANY times, and averages taken, with
>>>> > nice,
>>>> > tight 95% confidence intervals, can one say with confidence that X is
>>>> > faster
>>>> > than Y.
>>>> >
>>>> > I.e., try VN=4 and VN=5 each with many different RANDOM_SEEDs.
>>>> >
>>>> > Regards,
>>>> > Dan
>>>> >
>>>> > See also:
>>>> > "Variability in Architectural Simulations of Multi-threaded
> Workloads",
>>>> > by
>>>> > Wisconsin's own Alaa Alameldeen and David A. Wood.
>>>> > LINK: http://www.cs.wisc.edu/~alaa/papers/hpca03_variability.pdf
>>>> >
>>>> >
>>>> > On Mon, Apr 5, 2010 at 5:07 PM, Ikhwan Lee <ikhwan@xxxxxxxxxxxxxxx>
>>>> > wrote:
>>>> >>
>>>> >> Thanks Dan. I was running MOESI_SMP_directory using a fixed
>>>> >> g_RANDOM_SEED for all simulations. I am still not sure why results
> are
>>>> >> different for having an extra VNET. I'll keep the list posted if I
>>>> >> figure out why.
>>>> >>
>>>> >> Ikhwan
>>>> >>
>>>> >> On Tue, Apr 6, 2010 at 7:57 AM, Dan Gibson <degibson@xxxxxxxx> wrote:
>>>> >> > It depends.
>>>> >> > 1. If you're not using a protocol ending in _m, then your protocol
>>>> >> > doesn't
>>>> >> > use the MemoryController module. If that is the case, random noise
>>>> >> > (aka
>>>> >> > rand() % 5) is simply added to MAIN_MEMORY_LATENCY_MINUS_2 to
>>>> >> > generate
>>>> >> > the
>>>> >> > 'actual' memory latency.
>>>> >> > 2. If your protocol ends in _m, then you are using the
>>>> >> > MemoryController
>>>> >> > model, which has some built-in features to add random delays, when
>>>> >> > activated. Check out MemoryController.[Ch] (specifically, the
>>>> >> > comments
>>>> >> > at
>>>> >> > the start) to see how that works.
>>>> >> >
>>>> >> > In either case, for a fixed RANDOM_SEED, you should get precisely
>> the
>>>> >> > same
>>>> >> > results.
>>>> >> >
>>>> >> > Regards,
>>>> >> > Dan
>>>> >> >
>>>> >> > On Mon, Apr 5, 2010 at 4:43 PM, Ikhwan Lee <ikhwan@xxxxxxxxxxxxxxx>
>>>> >> > wrote:
>>>> >> >>
>>>> >> >> How is a simulation randomized? I've been getting exactly the same
>>>> >> >> results for each run with same simulation parameters.
>>>> >> >>
>>>> >> >> Thanks,
>>>> >> >> Ikhwan
>>>> >> >>
>>>> >> >> On Sat, Apr 3, 2010 at 12:24 PM, Dan Gibson <degibson@xxxxxxxx>
>>>> >> >> wrote:
>>>> >> >> > Average many runs of each (e.g., 8 runs w/ VNs = 4, 8 runs w/
> VNs
>>>> >> >> > =
>>>> >> >> > 5)
>>>> >> >> > and
>>>> >> >> > see if there is a statistically significant difference or not.
>>>> >> >> > Since
>>>> >> >> > the
>>>> >> >> > difference in runtime is pretty small, this could be due only to
>>>> >> >> > difference
>>>> >> >> > in RANDOM_SEED.
>>>> >> >> >
>>>> >> >> > That said, I don't actually know how Ruby might react to having
>>>> >> >> > 'extra'
>>>> >> >> > VNs.
>>>> >> >> >
>>>> >> >> > Regards,
>>>> >> >> > Dan
>>>> >> >> >
>>>> >> >> > On Fri, Apr 2, 2010 at 4:52 PM, Ikhwan Lee
>>>> >> >> > <ikhwan@xxxxxxxxxxxxxxx>
>>>> >> >> > wrote:
>>>> >> >> >>
>>>> >> >> >> The MOESI_SMP_directory protocol needs 4 virtual networks;
>>>> >> >> >> however,
>>>> >> >> >> it
>>>> >> >> >> should also run fine with 5 virtual networks since the 5th
>>>> >> >> >> virtual
>>>> >> >> >> network will never be used by the protocol. The question is,
>> when
>>>> >> >> >> I
>>>> >> >> >> compare the results of two simulations (one with 4 and one with
>> 5
>>>> >> >> >> virtual networks), I get something like below.
>>>> >> >> >>
>>>> >> >> >> 153c153
>>>> >> >> >> < NUMBER_OF_VIRTUAL_NETWORKS: 4
>>>> >> >> >> ---
>>>> >> >> >> < NUMBER_OF_VIRTUAL_NETWORKS: 5
>>>> >> >> >> 1457c1458
>>>> >> >> >> < Ruby_current_time: 25741756
>>>> >> >> >> ---
>>>> >> >> >> > Ruby_current_time: 27894100
>>>> >> >> >> 1459c1460
>>>> >> >> >> < Ruby_cycles: 25741755
>>>> >> >> >> ---
>>>> >> >> >> > Ruby_cycles: 27894099
>>>> >> >> >> 1461,1468c1462,1469
>>>> >> >> >> < mbytes_resident: 480.223
>>>> >> >> >> < mbytes_total: 508.523
>>>> >> >> >> < resident_ratio: 0.944347
>>>> >> >> >> <
>>>> >> >> >> < Total_misses: 2736589
>>>> >> >> >> < total_misses: 2736589 [ 221437 184551 181803 181854 165005
>>>> >> >> >> 165866
>>>> >> >> >> 172800 177348 162455 164810 168559 167311 146275 158797 158483
>>>> >> >> >> 159235
>>>> >> >> >> ]
>>>> >> >> >> < user_misses: 199059 [ 6640 12908 16388 12543 9998 14914 11967
>>>> >> >> >> 11834
>>>> >> >> >> 17170 11744 11685 12695 13389 11501 12351 11332 ]
>>>> >> >> >> < supervisor_misses: 2537530 [ 214797 171643 165415 169311
>> 155007
>>>> >> >> >> 150952 160833 165514 145285 153066 156874 154616 132886 147296
>>>> >> >> >> 146132
>>>> >> >> >> 147903 ]
>>>> >> >> >> ---
>>>> >> >> >> > mbytes_resident: 177.781
>>>> >> >> >> > mbytes_total: 498.574
>>>> >> >> >> > resident_ratio: 0.356579
>>>> >> >> >> >
>>>> >> >> >> > Total_misses: 2976004
>>>> >> >> >> > total_misses: 2976004 [ 231381 201401 206063 197190 177795
>>>> >> >> >> > 182883
>>>> >> >> >> > 187239
>>>> >> >> >> > 196167 175355 180539 183532 179732 157077 173355 171734
> 174561
>>>> >> >> >> > ]
>>>> >> >> >> > user_misses: 200169 [ 12482 12593 12510 11561 13957 9487
> 11581
>>>> >> >> >> > 12406
>>>> >> >> >> > 17732 13232 11811 11721 12437 12137 12108 12414 ]
>>>> >> >> >> > supervisor_misses: 2775835 [ 218899 188808 193553 185629
>> 163838
>>>> >> >> >> > 173396
>>>> >> >> >> > 175658 183761 157623 167307 171721 168011 144640 161218
> 159626
>>>> >> >> >> > 162147
>>>> >> >> >> > ]
>>>> >> >> >> --- omitted the rest
>>>> >> >> >>
>>>> >> >> >> The differences are not too big, but still quite strange since
> I
>>>> >> >> >> expected them to be exactly the same. Any idea on what is
>>>> >> >> >> happening?
>>>> >> >> >> I'm using Garnet fixed pipeline network.
>>>> >> >> >>
>>>> >> >> >> Thanks,
>>>> >> >> >> Ikhwan
>>>> >> >> >> _______________________________________________
>>>> >> >> >> 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.
>>>> >> >> >>
>>>> >> >> >
>>>> >> >> >
>>>> >> >> >
>>>> >> >> > --
>>>> >> >> > http://www.cs.wisc.edu/~gibson [esc]:wq!
>>>> >> >> >
>>>> >> >> > _______________________________________________
>>>> >> >> > 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.
>>>> >> >> >
>>>> >> >> >
>>>> >> >> >
>>>> >> >> _______________________________________________
>>>> >> >> 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.
>>>> >> >>
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > --
>>>> >> > http://www.cs.wisc.edu/~gibson [esc]:wq!
>>>> >> >
>>>> >> > _______________________________________________
>>>> >> > 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.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> _______________________________________________
>>>> >> 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.
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > http://www.cs.wisc.edu/~gibson [esc]:wq!
>>>> >
>>>> > _______________________________________________
>>>> > 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.
>>>> >
>>>> >
>>>> >
>>>> _______________________________________________
>>>> 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.
>>>>
>>>
>>>
>>>
>>> --
>>> http://www.cs.wisc.edu/~gibson [esc]:wq!
>>>
>>> _______________________________________________
>>> 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.
>>>
>>>
>>> _______________________________________________
>>> 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.
>>>
>>>
>>>
>> _______________________________________________
>> 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.
>>
>>
>>
>> _______________________________________________
>> 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.
>>
>>
> _______________________________________________
> 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.
>
>
> _______________________________________________
> 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.
>
>