I recommend you to run in Dev mode before setting the vverb severity in simics
up to ~120k cycles. c #number of instructions. While in simics simulation 
without
flexus timing component instructions and cycles are equivalent because IPC=1.
However, when you load the timing component this is not the case. So you need
to estimate how much is the ipc for the flexpoint. When you reach the 120k 
cycles
you change the severity to vverb and then you capture the vverb output of the 
10k
cycles.

Regards,
-Stavros


On Aug 3, 2010, at 10:54 PM, Mahmood Naderan wrote:

I have found somwthing unusual. In the timing simulation, the first 3 flex 
folders are created normally:
46 <microArch.cpp:358> {140000}- Timestamp: 2010-Aug-04 10:10:50
47 <flexus.cpp:283> {150000}- Saving stats at: 150000
48 <microArch.cpp:358> {150000}- Timestamp: 2010-Aug-04 10:10:51
49 <flexus.cpp:277> {150001}- Reached target cycle count. Ending simulation.
50 <flexus.cpp:680> {150001}- Terminating simulation. Timestamp: 2010-Aug-04 
10:10:51
51 <flexus.cpp:681> {150001}- Saving final stats_db.
Simulation terminated by flexus.
Starting initial flexpoint creation of flexus_test with UniFlex.OoO in 
/home/mahmood/flexus-3.0.0/flexus-test-app/runs/mahmood-timing-04Aug10-100933/flexpoint_0003
~/flexus-3.0.0/flexus-test-app/runs/mahmood-timing-04Aug10-100933/flexpoint_0003/exec
 ~/flexus-3.0.0/flexus-test-app
00-directory-tflex
bpred-00
simics-state
simics-state.raw
sys-L1d
sys-L1i
sys-L2
sys-magic-break
But for others, I have noticed that "run-job" is actually killed because of 
memory leakage:
39 <flexus.cpp:272> {100000}- Timestamp: 2010-Aug-04 10:11:28
40 <flexus.cpp:283> {100000}- Saving stats at: 100000
41 <microArch.cpp:358> {100000}- Timestamp: 2010-Aug-04 10:11:28
42 <microArch.cpp:358> {110000}- Timestamp: 2010-Aug-04 10:11:31
43 <microArch.cpp:358> {120000}- Timestamp: 2010-Aug-04 10:11:34
44 <microArch.cpp:358> {130000}- Timestamp: 2010-Aug-04 10:11:37
./run-job: line 254:  3230 Killed                  ./go.sh
Starting initial flexpoint creation of flexus_test with UniFlex.OoO in 
/home/mahmood/flexus-3.0.0/flexus-test-app/runs/mahmood-timing-04Aug10-100933/flexpoint_0004
~/flexus-3.0.0/flexus-test-app/runs/mahmood-timing-04Aug10-100933/flexpoint_0004/exec
 ~/flexus-3.0.0/flexus-test-app
00-directory-tflex
bpred-00
simics-state
simics-state.raw
sys-L1d
sys-L1i
sys-L2
sys-magic-break

I have attached a picture that shows the memory leakage. I tried to use "verb" 
severity to find out but the bug occur in {130000} but I have to wait long long 
time to reach that cycles and the log file will have a very huge size that can 
not be opened with any text editor.

How can I find what is happenning in the {130000}?

// Naderan *Mahmood;


________________________________
From: Volos Stavros <[email protected]<mailto:[email protected]>>
To: Mahmood Naderan <[email protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>
Sent: Wed, August 4, 2010 1:06:56 AM
Subject: RE: total execution cycles in "print sum"

You should look in the flexpoint directories whether the stats_db.out.gz was 
created or not. Also check for the
stdout and stderr to see the output and possible errors. Last, check the 
condor.log to see if the job was executed
or dropped for some reason. In general the files that you have in the 
results/.../flexpoint_dir show whether the
flexpoint was executed succesfully.

Regards,
-Stavros

________________________________
From: Mahmood Naderan [[email protected]]
Sent: Tuesday, August 03, 2010 8:56 PM
To: simflex
Subject: Re: total execution cycles in "print sum"

>The stats.out that I am reffering to is the output of print sum :)
I understand

>Which stats_db.out.gz are you using to "print sum" ?
Hard question.... according to manual:
cd FLEXUS_HOME/flexus-test-app/runs/<run name>
../../sampleresults
These scripts will create a file called stats_db.out.gz in the current 
directory, which contains the aggregated results from
all flex-points

>Did you check that all flexpoints were executed properly?
I am not sure. How can I check?

// Naderan *Mahmood;


________________________________
From: Volos Stavros <[email protected]<mailto:[email protected]>>
To: Mahmood Naderan <[email protected]<mailto:[email protected]>>; 
simflex <[email protected]<mailto:[email protected]>>
Sent: Tue, August 3, 2010 11:09:27 PM
Subject: RE: total execution cycles in "print sum"

The stats.out that I am reffering to is the output of print sum :)

Which stats_db.out.gz are you using to "print sum" ?

Did you check that all flexpoints were executed properly?

Regards,
-Stavros


________________________________
From: Mahmood Naderan [[email protected]]
Sent: Tuesday, August 03, 2010 8:22 PM
To: simflex
Subject: Re: total execution cycles in "print sum"

Sorry But I am testing with flexus3.0.

>In the stats.out you should have something like that:
> reduce-SelectedRegions                   Region (002)
I have this file in all of the flex folders (for the timing simulation) but all 
them are zero in size.


// Naderan *Mahmood;


________________________________
From: Volos Stavros <[email protected]<mailto:[email protected]>>
To: Mahmood Naderan <[email protected]<mailto:[email protected]>>; 
simflex <[email protected]<mailto:[email protected]>>
Sent: Tue, August 3, 2010 10:47:13 PM
Subject: RE: total execution cycles in "print sum"

>From the provided information you are using 150k cycles and interval 50k cycles
(if the information is listed in the command that you are using in timing 
simulation
for your workload)

For example:

array set flexus_commands_timing {
        common {
                flexus.set "-magic-break:stop_cycle" "150000"
                flexus.set-region-interval "50000"
                instruction-fetch-mode instruction-fetch-trace
                console_tracker.add-break-string "bash"
        }
}
rungen timing {
{ oracle_16cpu_16cl          baseline  0-3:5-24  
$flexus_commands_timing(common) }

}

In the stats.out you should have something like that:

 reduce-SelectedRegions                   Region (002)

Check whether all the flexpoints were executed properly. Give a look in the
error and outpout files of each flexpoint and also the condor log to see if the
flexpoint was sent properly.  It seems that only 8 flexpoints were executed.

Regarding the Busy cycles, they are equal to sys-cycles and it makes sense
because you didn't spend any time in system (System Accounted cycles = 0).

Regards,
-Stavros

________________________________
From: Mahmood Naderan [[email protected]]
Sent: Tuesday, August 03, 2010 8:01 PM
To: simflex
Subject: Re: total execution cycles in "print sum"

> how many regions do you have in these stats?
Config/OoO/postload.simics:
flexus.set-stat-interval "50000"
flexus.set-region-interval "50000"
>Secondly, the sys-cycles should be equal to flexpoints x 
>Cycles_for_each_flexpoint.
sys-cycles                  400000
Config/flexpoint/start.simics:
flexus.set-stop-cycle "25000000"

> How many cycles do you simulate in timing simulation for each flexpoint?
flexus.set-stop-cycle "150001"

>The most common is to use 100k for warm up and 50k for the final stats (region 
>002).
No idea.... What are the names?

> Secondly, you shoud better use the sum of the System:AccountedCycles and
> the User:AccountedCycles. Their sum is equal to Flexpoints x Cores x 
> Cycles_of_regions.
sys-uarch-TB:User:AccountedCycles        399997
sys-uarch-TB:System:AccountedCycles      0
So their sum is not equal to what you mentioned.

>For example for 16 cores, 10 flexpoints, 50k for each region you
>should have total 8M cycles while for the sys-cycles 500k
Here I use only 1 core (or better say, I didn't change anything and I use 
defaults) to see what is happening. I also have 18 flexpoints and 50k for each 
region. so 1*18*50k = 900,000

>Also, I suppose that you are interested in UIPC and not the IPC of
>kernel instructions, so the uarch-TB:User:Commits:Busy is the one that you 
>should use.
I am interested in UIPC, but for me sys-uarch-TB:User:Commits:Busy           
506601

Regards,
// Naderan *Mahmood;


________________________________
From: Volos Stavros <[email protected]<mailto:[email protected]>>
To: Mahmood Naderan <[email protected]<mailto:[email protected]>>; 
simflex <[email protected]<mailto:[email protected]>>
Sent: Tue, August 3, 2010 9:37:27 PM
Subject: RE: total execution cycles in "print sum"

Hi,

First of all, how many regions do you have in these stats? Secondly, the 
sys-cycles
should be equal to flexpoints x Cycles_for_each_flexpoint. How many cycles do 
you
simulate in timing simulation for each flexpoint? The most common is to use 100k
for warm up and 50k for the final stats (region 002). Secondly, you shoud 
better use the
sum of the System:AccountedCycles and the User:AccountedCycles. Their sum is 
equal
to Flexpoints x Cores x Cycles_of_regions. For example for 16 cores, 10 
flexpoints, 50k
for each region you should have total 8M cycles while for the sys-cycles 500k. 
In sum
all results are for all cores so you should devide with 8M instead of 500k. 
Also, I suppose
that you are interested in UIPC and not the IPC of kernel instructions, so the
uarch-TB:User:Commits:Busy is the one that you should use.

Regards,
-Stavros

________________________________
From: Mahmood Naderan [[email protected]]
Sent: Tuesday, August 03, 2010 4:45 PM
To: simflex
Subject: total execution cycles in "print sum"

Hi,
According to the manual, IPC can be calculated by this expression:
{sys-uarch-Commits}/{sys-cycles}

I have these numbers for them:
sys-uarch-Commits           506601
sys-cycles                  400000

But I don't think sys-cycles is true because I have 17 flexpoints and each has 
25M cycles.
Is sys-cycles different from the total execution cycles we get from workload?


// Naderan *Mahmood;







Reply via email to