Yes, I think your speculation is reasonable.
VC0 will get extra "n * m_vc_per_vnet" chances to transmit data, where n is
the number of extra VNs.
发件人: gems-users-bounces@xxxxxxxxxxx
[mailto:gems-users-bounces@xxxxxxxxxxx] 代表 Niket Agarwal
发送时间: 2010年4月8日 22:06
收件人: gems-users@xxxxxxxxxxx
主题: Re: [Gems-users] 答复: 答复: What happens if
NUMBER_OF_VIRTUAL_NETWORKS is greater than needed?
Yes, the empty VCs would be skipped and the switch doesn't go unused
because of the addition of extra VNs.
But, note that the way the round-robin arbiter is implemented, the
m_round_robin_inport is incremented on every arbitration cycle and then
a linear scan of VCs is done to select the next VC that will win the
switch. If we add an extra VN in which VCs will never have anything,
VN=0 will get a lot many arbitration wins just because of the way the
arbitration logic is coded up. The different performance numbers are due
to that.
If you are *always* seeing VN=4 performing better than VN=5, the reason
could be that the request network (VN=0) is getting a much higher
priority and data is not able to travel faster in the network. Just
speculation!
-Niket
On 04/08/2010 03:07 AM, Ikhwan Lee wrote:
> 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.
>>
>>
>>
> _______________________________________________
> 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.
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}