I just uploaded a new update to jACT-R and ACT-R/S is coming out shortly.
jACT-R
The jACT-R update covers many aspects. The first is the support for batch runs. I’m quite pleased. The only thing left to do is to have the IDE support for the iterative listener which will permit modelers to customize each iteration of the batch (e.g. tweak a parameter, set a different random seed, etc). Right now as it runs, it snags all the files generated on each run and sticks them into a zip file - so if a particular tool generates lots of output, you won’t be drowning in thousands of files. Unfortunately, the batch run doesn’t support embodied models just yet - there are some sticky runtime issues since CommonReality was designed to be instantiated just once per JVM.
Right now I’m using it as for performance profiling. Thanks to Apple’s Shark profiler, I was able to identify a few hotspots. Before optimization I was getting around 200x real time performance. Then after catching a few stupid string processing mistakes that jumped up to 500x. A couple of tweaks later to remove unnecessary stack frame calculations in signal exceptions, we’re up to 600x. As impressive as that number sounds, there are three caveats.
- that’s running a disembodied model (e.g. no visual system).
- with the hotspot compiler it takes around 1000 cycles to get up to that speed (out of the gate it’s running around 300x)
- That’s effective real time factor, not actual real time factor. What’s the difference? The effective factor is total simulated time / total running time. It ignores the fairly major optimization of skipping cycles and advancing the clock when you know no productions can fire (i.e. all the productions are waiting for an event that will fire in the future). The actual factor is total simulated cycle time / total real cycle time. This measures how much faster than the simulation the model is running when it is actually working. Modelers need only be concerned with the effective factor, but for optimizations and the like, actual is more important. Oh, and what was the actual real time factor? 400x.
If these numbers hold up, I should be able to run my experiment model (experiment time around 2 hours) in 12 seconds, or a 1000 simulated runs in 3 hours and 20 minutes. Nice. So much better than real subjects.
I was also looking at the scaling with an increase in the number of models running concurrently. Not as good as I’d hoped. Moving from 1 to 2 models, you get a 30% decrement (not bad) - from 2 to four you get a 40% (a little better than linear), and 4 to 8 you get a 50% decrement. Part of the reason for this is that the system, even with 1 model, is already running at least two threads. For disembodied models the number of threads is 1(main) + 1 (background) + N(models). For embodied models its 1 (main) + 1(background) + N(models) + N(embodiment) + 1 (CommonReality) + 1(sensor). Let me get my hands on one of the new 8 core machines and I’ll show you something really cool.
Other stuff includes numerous bug fixes, code clean up, more documentation, etc.
ACT-R/S
Anyway - what about ACT-R/S? Whenever people ask if it’s ready the answer is always almost. Why? because ready is a vague term. Does it run? hell, yes. But what does it do? That’s the issue. There are many components to it. Currently attending to targets, updating them (in the head translation and rotation), linking them to their correlated visual objects, and general queries all work. So does the establishment of configural-locations (linking two reps to form a unique location). What doesn’t work? Making sure that the location tags (that identify the locations) are reused for identical locations, an actual embodied updating (haven’t cobbled together any legs yet), nor the navigational queries (if I’m here, where to I go to get there). I only need the components that are currently implemented. I’m always reluctant to release things without examples. If you’d like to play with it now - lemme know. Otherwise, the release will be held until I can show what’s what with my models.
