-
Notifications
You must be signed in to change notification settings - Fork 1
Optimizing Performance
Most models should run fairly quickly right out of the box. However, when it comes to running batch executions, the faster the better. There are numerous plugin optimizations that can be applied based on your situation. They are not enabled by default because they also incur added costs elsewhere (e.g., memory usage), and their code is often more complex.
First you will want to enable coarse performance profiling. To do this, set the model's CycleProcessor parameter to org.jactr.tools.profile.CycleProcessor. After the model run, you will see the profiling stats for six measures in stdout.
With the exception of the simplest models, the greatest time sink is time sync. That is, the model will spend most of its time waiting for other processes to synchronize. This is required to maintain consistency in the simulation. The time spent waiting for the clock is the most difficult to reduce, so for now we'll just list some common values on current hardware.
- <1ms, simplest models or those with independent clocks.
- 1-2ms, multimodes or in-JVM simulation
- 2-10ms, local networked simulations
- >10ms, internet based
Most of the logic and side-effects of production firing is handled on the timed event queue. Values greater than 1ms for event processing are rare unless there is a very large declarative memory. In these instances, enabling the parallel search delegates can significantly improve runtimes. Set the ExactSearchDelegate and PartialSearchDelegate parameters of the declarative module to org.jactr.core.modules.declarative.storage.ParallelExactSearchDelegate and org.jactr.core.modules.declarative.storage.ParallelPartialSearchDelegate, respectively. Exact performance numbers can be found by using the org.jactr.tools.profile.ProfiledSearchDelegate to wrap the respective implementation.
After synchronization, the process of building the conflict set and instantiating candidate productions are the most expensive operations. If you are seeing times greater that 1ms, apply the following for improved performance:
The extension org.jactr.extensions.cached.procedural.CachedProceduralSystem creates a RETE-like tree based not on the production conditions, but on the cause of the instantiation failure. This can have profound impacts on runtime if you have a more than a few productions. The parameter EnableCaching turns the system on or off. ValidateInstantiations runs the cache, but actually attempts to instantiate every production anyway, comparing the failures. This is a sanity check to be sure the system runs correctly. It is recommended you run it in validation mode once, verify there are no errors (in stdout), then turn it off.
If you've still got >1ms production cycle times and have a large procedural memory (+100), try turning on parallel conflict resolution. This can be enabled through the ConflictSetAssemblerClass parameter set to org.jactr.core.modules.procedural.six.ParallelConflictSetAssembler. Exact performance numbers can be found by using the org.jactr.tools.profile.ProfiledConflictSetAssembler to wrap the respective implementation.
EnableParallelInstantiations in the procedural module will do this currently, but it will soon be accessed as in 2.