sleyzerzon / soar

Automatically exported from code.google.com/p/soar
1 stars 0 forks source link

Soar stats timings in Linux are off by a factor of 10 #143

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
I've noticed that the run times reported by the "stats" command are 
consistently completely wrong in Linux. For example, I compiled the trunk 
kernel (r13874) with optimizations, and ran the 15 puzzle agent for about 1 
minute. I disabled all output and removed the monitor rule, so no time was 
spent printing to the terminal. The output of stats after this is:

Soar 9.3.2 on puff at Mon Jun 24 20:30:39 2013

98 productions (73 default, 13 user, 12 chunks)
   + 0 justifications
                                                        |   Computed
Phases:      Input   Propose   Decide   Apply    Output |     Totals
========================================================|===========
Kernel:      0.001    0.001    0.009    6.006    0.001  |      6.018
========================================================|===========
Input fn:    0.001                                      |      0.001
========================================================|===========
Outpt fn:                                        0.000  |      0.000
========================================================|===========
Callbcks:    0.000    0.000    0.000    0.000    0.002  |      0.002
========================================================|===========
Computed------------------------------------------------+-----------
Totals:      0.002    0.001    0.009    6.006    0.003  |      6.021

Values from single timers:
 Kernel CPU Time:       6.023 sec. 
 Total  CPU Time:       6.028 sec.

8521 decisions (0.707 msec/decision)
25634 elaboration cycles (3.008 ec's per dc, 0.235 msec/ec)
25634 inner elaboration cycles
8532 p-elaboration cycles (1.001 pe's per dc, 0.706 msec/pe)
148508 production firings (5.793 pf's per ec, 0.041 msec/pf)
282374 wme changes (141293 additions, 141081 removals)
WM size: 212 current, 210.842 mean, 371 maximum

Running the same test for 30 seconds and 120 seconds, I noticed that the times 
reported are always approximately 1/10 of the real time. So I'm guessing that 
somewhere in the code there's a division that's missing a 0. If that's the 
case, the fix should be simple.

I've confirmed that the times reported in Windows are correct, but I haven't 
tried on Mac.

Original issue reported on code.google.com by joseph...@gmail.com on 25 Jun 2013 at 12:57

GoogleCodeExporter commented 8 years ago
This issue was closed by revision r13886.

Original comment by joseph...@gmail.com on 1 Jul 2013 at 8:26