Speed varies based on who initiates run

[GoogleCodeExporter]

Description From Dave Ray 2007-08-15 12:53:10 (-) [reply]
It seems like the speed of a system can vary based on who initiates the run
command. To reproduce:

* Run TankSoar and create a new agent with obscure-bot.soar and no debugger
* Run the java debugger and connect it to the TankSoar kernel
* Run the agent from the TankSoar interface and note the rate of the watch 
1
output printed in the debugger.
* Now stop the agent
* Run the agent from the debugger and note the rate of the watch 1 output
printed. 

When I do this test there is a noticeable decrease in speed when the agent 
is
run from the debugger.  I also occasionally sees great variation in speed  
just
starting and stopping the agent repeatedly in the debugger.
------- Comment #1 From Bob Marinier 2007-08-16 18:29:12 (-) [reply] ------
-
This is a known behavior; Doug explained it to me a while ago.  Here's the
email thread (messages are in reverse chronological order):

--- Begin copy ----

Yes it could be around a factor 2.  If that thread is using a sleep call we
could potentially speed it up in a future release by switching to a signal
so the thread wakes up immediately when an event arrives.

Of course there may be other things involved too.  We'd want to do a little
profiling before banging on the code.

Doug

-----Original Message-----
From: Bob Marinier [mailto:rmarinie@eecs.umich.edu] 
Sent: Tuesday, May 16, 2006 3:08 PM
To: 'Soar SML'
Subject: Re: speed differences in running from debugger vs environment

No, it's faster from Eaters.  I can understand this, it's just that the
difference is so pronounced.  I mean, does the extra thread explain a 
50+% difference in performance? (Not that I've actually timed it, but
visually that seems about right).

Bob

Douglas Pearson wrote:
> > I haven't tried this but I'm guessing it's faster when run from eaters.
> >
> > I think the difference is how the events are handled.  When running 
from
> > eaters the "run" call blocks and eaters is 100% locked into waiting for
> > events and dispatching them.  There's no thread switching.  When 
running
> > from the debugger, eater's main thread is sitting doing nothing 
(handling
> > windows messages really) and the separate event thread is checking for
> > incoming events.
> >
> > Of course if it's faster from the debugger then forget that explanation  
:) 
> >
> > Doug
> >
> > -----Original Message-----
> > From: Bob Marinier [mailto:rmarinie@eecs.umich.edu] 
> > Sent: Tuesday, May 16, 2006 1:53 PM
> > To: Soar SML
> > Subject: speed differences in running from debugger vs environment
> >
> > Does anyone know why there's such a large difference in speed if I run,
say,
> > eaters from an attached debugger vs running from eaters itself (even 
with
> > the same debugger attached)?
> >
> > Bob
------- Comment #2 From Bob Marinier 2007-08-16 18:42:01 (-) [reply] ------
-
The speed variation from stopping and starting could be related to bug 711.  
In
general, we have observed a small difference on Windows machines, even when
running from the environment (although it may be less noticeable there).  
On
Vista, the differences can be much more pronounced if there is a low-
priority
task that takes all of the cpu running in the background (e.g., one of the
@Home projects).  On a multicore processor, if you set the process affinity 
to
one of the cores (in Task Manager), the problem goes away.

Original issue reported on code.google.com by voigtjr@gmail.com on 23 Jul 2009 at 4:41

[GoogleCodeExporter]

Original comment by voigtjr@gmail.com on 23 Jul 2009 at 5:29

• Added labels: Imported-Bugzilla

[GoogleCodeExporter]

This hasn't been reproducible for a while.

Original comment by voigtjr@gmail.com on 23 Feb 2010 at 5:41

• Changed state: WontFix