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

[付斌章 <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.