general questions

485 views
Skip to first unread message

Shaizeen

unread,
Oct 28, 2014, 6:44:57 PM10/28/14
to snip...@googlegroups.com
Hi.

  I am just starting to use sniper and pin. I had some basic questions about it. 

-Can sniper run traces only recorded using record_trace tool? I was wondering if I record a trace using say simics, would I able to run said trace of instructions using sniper? I believe I need to understand the trace format that sniper requires first, and get simics to dump instructions in this format.  Please correct me if I am wrong. 

- I have skimmed through the forum posts regarding running Java applications (and have not been successful myself to get them to run so far). But I am not sure I completely understand what limitations make java applications not portable to sniper? 
If I can do a pin analysis for my application, is it safe to say I should be able to port the application to sniper? 

-Can you point me to some documentation regarding what the command line option --sift does? 

(I am just starting to use this tool and I could possibly be over simplifying some things here. )

Wim Heirman

unread,
Oct 29, 2014, 3:08:12 AM10/29/14
to snip...@googlegroups.com
Hi Shaizeen,

Currently the only way to generate SIFT traces is using the record-trace tool, which uses a Pin tool (in sniper/sift/recorder) to extract dynamic instruction streams and dump them to a SIFT file. Using the --sift option to run-sniper does something similar, except that the Pintool and the simulator run simultaneously (but in different processes) and communicate over a UNIX pipe (using the same SIFT data format), this mode also supports multithreading as the simulator sends back per-thread timing information to the Pintool to make sure all threads advance according to their simulated IPC.

Generating a SIFT trace through other means, such as Simics, is definitely possible. Getting it to work with multithreaded applications or multicore Simics simulations will be quite difficult (both Sniper and Simics will try to "own" per-thread progress, which will deadlock if you don't carefully manage it), but getting a single-threaded stream and storing it to disk should be easy once you know the required Simics hooks. You'll need to extract the instruction opcode, memory addresses for loads and stores, and branch directions (taken/not taken). For each dynamic instruction you should then call the Instruction() function of the Sift::Writer class (in sift/sift_writer.cc) which will write the SIFT file for you (so no need to understand the binary format).

As for Java workloads, in theory everything that Pin can handle should simulate in Sniper, but in practice Sniper makes a few extra assumptions about the application that aren't always met. Java seems to break many of those. Problems can occur when the application forks (not supported, there should only be one process), does self-modifying code (should not happen inside ROI, although if you use replay compilation and make sure no code changes during ROI you should be fine), and certain synchronization behavior (Sniper emulates OS-based synchronization calls such as futex, pause, etc, to make sure they have the correct effect on simulated time). This page [1] documents some of our experiences in running DaCapo workloads with Jikes under Sniper, although I must admit the experience is still quite cumbersome and difficult to get to work correctly.

Regards,
Wim




--
--
--
You received this message because you are subscribed to the Google
Groups "Sniper simulator" group.
To post to this group, send email to snip...@googlegroups.com
To unsubscribe from this group, send email to
snipersim+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/snipersim?hl=en

---
You received this message because you are subscribed to the Google Groups "Sniper simulator" group.
To unsubscribe from this group and stop receiving emails from it, send an email to snipersim+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Message has been deleted

Shaizeen

unread,
Oct 29, 2014, 11:46:01 AM10/29/14
to snip...@googlegroups.com
Hi Wim.

   Thank you so much for a detailed reply. I see the complexities involved in running a multi-threaded application driven by Simics in sniper. I wanted to understand the challenges with running Java applications a little better. 

   I believe the SMC option in PIN and enable_smc_support in sniper, should take care of self modifying code? Or even with this option, sniper expects no code changes in ROI? 

  Regarding fork, is the difficulty "modelling the timing of IPC" (e.g pause) that will ensue if we allow multiple processes in sniper? Timing for communication between threads is something sniper models but not for multiple processes? Or there is more to this?

  
  I did try running Jikes but as I point here[1], I see that threads get into sleep mode and simulation hangs after running for some time. The last thing I see in application log is they are at a barrier. 

Wim Heirman

unread,
Nov 5, 2014, 2:22:03 AM11/5/14
to snip...@googlegroups.com
Hi Shaizeen,

Pin should fully support SMC, but Sniper has a few places of its own where decoded instructions are cached, these are not invalidated when code is modified leading to an inconsistency in what the benchmark is running and what the timing model expects (which is a problem when for instance the timing model expects a branch taken/not-taken indication from the application, but the code has been changed so that at this instruction pointer address there no longer is a branch).

Modeling fork() and IPC is possible, the main thing to take care of is to ensure that the timing model knows when threads are asleep. (Sniper does barrier synchronization every 100 simulated ns and will wait for threads that are behind -- but this barrier needs to know whether they should be expected to catch up soon or whether they are asleep, if you get this wrong it leads to the kind of deadlocks you are seeing with Jikes). This is partially handled in common/core/syscall_model.cc, see the cases for SYS_pause etc. Depending on what type of IPC system calls your application uses, you may have to add additional system calls here.

Regards,
Wim



On 29 October 2014 16:39, Shaizeen <shai...@umich.edu> wrote:
Hi Wim.

   Thank you so much for a detailed reply. I see the complexities involved in running a multi-threaded application driven by Simics in sniper. I wanted to understand the challenges with running Java applications a little better. 

   I believe the SMC option in PIN and enable_smc_support in sniper, should take care of self modifying code? Or even with this option, sniper expects no code changes in ROI? 

  Regarding fork, is the difficulty "modelling the timing of IPC" (e.g pause) that will ensue if we allow multiple processes in sniper? Timing for communication between threads is something sniper models but not for multiple processes? Or there is more to this?

  I did try running Jikes but as I point here[1], I see that threads get into sleep mode and simulation hangs after running for some time. The last thing I see in application log is they are at a barrier. 


On Wednesday, October 29, 2014 3:08:12 AM UTC-4, Wim Heirman wrote:
Reply all
Reply to author
Forward
0 new messages