[Gems-users] Running SPLASH2 benchmarks with LogTM

[Shougata Ghosh <shougata@xxxxxxxxxxxxx>]

Hi

I am trying to run SPLASH-2 benchmarks with logTM. I have replaced the 
locks in the code with magic instructions (xaction begin and commit). 
The cache coherence protocol I'm using is MESI_SMP_LogTM_directory. My 
version of simics is 2.2.19 and GEMS is 1.3 (not hooking up opal).
I want to collect the memory traces (along with xaction begins, commits 
and aborts) and analyse them offline. I don't really care about the 
timing info generated by ruby. Running with ruby slows it down too much! 
And since I don't need the timing info that ruby provides, I think this 
slowdown is unjustified in my case!
I thought of running it with the PERFECT_MEMORY_SYSTEM=true and setting 
PERFECT_MEMORY_RESPONSE_LATENCY = 0, but then I figured out that will 
probably break the transactional memory part of the memory system. When 
PERFECT_MEMORY_SYSTEM is true, ruby seems to completely bypass the cache 
and simply return PERFECT_MEMORY_RESPONSE_LATENCY. That way, the xaction 
conflicts will never be detected. Can someone verify this?
One alternative I thought of was using Tourmaline. While tourmaline 
worked for some small microbenchmarks, it always breaks when I'm trying 
to run the SPLASH2 benchmarks.
Another option I tried is to let ruby do its thing but always return 0 
to simics for stall cycles. Basically, in ruby_operate(), I call 
mh_memorytracer_possible_cache_miss(mem_op) and then return 0. This 
would slow the execution down somewhat but atleast it won't stall 
simics. Conceptually this made sense to me but when I ran it, it gave me 
the following error right after the first xaction_begin:
simics-common: system/Sequencer.C:487: void Sequencer::makeRequest(const 
CacheMsg&): Assertion `isReady(request)' failed.
***  Simics getting shaky, switching to 'safe' mode.
***  Simics (main thread) received an abort signal, probably an assertion.

I understand there were some logTM bugs in this version of GEMS (1.3) 
which were fixed in the last release (1.4). Is this error being caused 
by one of those bugs? Is it worth the trouble to install GEMS 1.4 and 
try this method out or is there something fundamentally wrong with what 
I'm doing and won't work in 1.4 either?
Any other ways of achieving whaty+simics (where ruby stalls simics) 
setup and I notic I'm trying to do?
Btw, I did try running barnes with the regular ruby+simics (where ruby 
stalls simics) setup and I noticed ruby always returned 2000000000 
cycles as the stall cycle! What's causing this???
I'd really appreciate any ideas.

Thanks in advance
shougata