[Gems-users] Running SPLASH2 benchmarks with LogTM


Date: Mon, 05 Mar 2007 23:44:00 -0500
From: Shougata Ghosh <shougata@xxxxxxxxxxxxx>
Subject: [Gems-users] Running SPLASH2 benchmarks with LogTM
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

[← Prev in Thread] Current Thread [Next in Thread→]