Interact with Sniper, dumping stats for specific segments of the application

[Alexandru Iordan]

Hello

I only recently started "playing" with Sniper and would like to know if some functionalities that are available to me in my current simulator (GEM5) are also available in Sniper. To be more specific, I want to mark certain regions in the code and get stats for those regions (the end goal is to push these stats into McPAT and see the energy consumed during the execution of those code regions). GEM5 has some special functions for dumping and resetting stats and I can call these functions when my interest region is reached in the execution. Is something similar implemented in Sniper? If not, where should I start looking so I can understand how the stats are gathered and reported and also how I can signal the simulator from within the application so I can try to implement what I need.

Best regards,

Alexandru Iordan

[Wim Heirman]

Hi Alexandru,

Sniper should have everything you need for this:

* Use marker instructions (SimMarker, see sniper/include/sim_api.h) to
mark regions of code in your application
* See the scripts/marker.py script on how to write out a snapshot of
all statistics when a marker is encountered (uncomment line 12, and
add "-smarker" to the run-sniper command line)
* Use the --partial command line option for mcpat.py or cpistack.py to
restrict them to the region defined by two marker names (default is
roi-begin to roi-end).

Note that in Sniper, the idea is never to reset statistics, but to
take snapshots at certain points during the simulation (ROI begin, ROI
end, and whenever you have a script call sim.stats.write). Processing
scripts later subtract the statistics value at the beginning of the
region of interest from their value at the end.

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

[Alexandru Iordan]

Hello Wim

First of all thank you for taking the time to answer my questions. After you told me what to look for, I found that the FFT test application is using the SimMarker() to define the ROI. This gives me good example. I also notice that the FFT-marker version of the application is executed using the "-s iter2.py" command line argument. As I understand it, this Python script describes how different encounters with the SimMarker will be treated. Is this true? Can I use such a script to better manage the SimMarker?

On a different note, I found a lot of command line arguments that are not listed when you run "run-sniper --help" nor in the Sniper manual (like -s marker, --roi-script and others ). Do I need to parse the code to find all of them or there is a better way?

Best regards,

Alexandru Iordan

[Wim Heirman]

Hi Alexandru,

> First of all thank you for taking the time to answer my questions. After you
> told me what to look for, I found that the FFT test application is using the
> SimMarker() to define the ROI. This gives me good example. I also notice
> that the FFT-marker version of the application is executed using the "-s
> iter2.py" command line argument. As I understand it, this Python script
> describes how different encounters with the SimMarker will be treated. Is
> this true? Can I use such a script to better manage the SimMarker?

Correct. The scripting interface allows for callbacks when certain
events (such as the application executing a SimMarker) happen, at this
point you can have the simulator do things (such as write out
statistics, start/end detailed mode, etc.).

> On a different note, I found a lot of command line arguments that are not
> listed when you run "run-sniper --help" nor in the Sniper manual (like -s
> marker, --roi-script and others ). Do I need to parse the code to find all
> of them or there is a better way?

The manual is a work in progress... Do complain if you feel something
is missing. There are a few more options which you can find in the
source of run-sniper, but they're used for debugging only. Usually the
mailing list and its archives are the best way to get help if you need
anything specific.

Regards,
Wim

[Alexandru Iordan]

I tried a simple test. I added some SimMarker() calls to my code and I tried to run it in Sniper. The command I used is:

./run-sniper -n 4 -s markers -d ../sniper_output/wool/stress/ -c gainestown -- /home/alexandru/bots/wool-tasks/stress.gcc.wool -p 4 -s 1000 -g 1000 -d 10 -i 1

I used the default markers.py script, so the only results should have been some prints in the console (something like [SCRIPT] Magic marker from thread ... ). However, the execution terminated with and error: 

[SNIPER] Start

Running ['bash', '-c', '/home/alexandru/sniper/pin_kit/intel64/bin/pinbin -mt -injection child -xyzzy -enable_vsm 0 -t /home/alexandru/sniper/lib/pin_sim -c /home/alexandru/sniper/config/base.cfg --general/total_cores=4 --general/output_dir=../sniper_output/wool/stress/ --config=/home/alexandru/sniper/config/nehalem.cfg --config=/home/alexandru/sniper/config/gainestown.cfg -g --hooks/numscripts=1 -g --hooks/script0name=/home/alexandru/sniper/scripts/markers.py -g --hooks/script0args= -- /home/alexandru/bots/wool-tasks/stress.gcc.wool -p 4 -s 1000 -g 1000 -d 10 -i 1']

terminate called after throwing an instance of 'std::logic_error'

  what():  __sso_string_base::_M_construct NULL not valid

Pin app terminated abnormally due to signal 6.

[SNIPER] End

[SNIPER] Elapsed time: 0.19 seconds

Any idea what is going wrong?

Regards,

Alexandru Iordan

P.S.: When I run without the "-s markers" the simulation completes, but with no "[SCRIPT] Magic marker " printouts.

[Wim Heirman]

Hi Alexandru,

It looks like something is wrong with the Python setup in your copy of
Sniper. Can you make sure you have the latest version (should be 3.06,
you can check it using "git log"), do a "make distclean" followed by a
"make" to make sure everything is cleanly compiled, and try again?
What OS are you using, if not the default which GCC version, and what
architecture (32 or 64-bit)?

Regards,
Wim

[Alexandru Iordan]

Hello Wim

Information on my system:

Sniper version: 3.06

OS: Ubuntu 10.04.4 LTS

GCC version: 4.4.3 (Ubuntu 4.4.3-4ubuntu5.1)

Architecture: x86_64

Python version: 2.6.5

I performed the distclean and recompilation but the error is still the same. Maybe is worth mentioning that I can run the sniper/test/fft application but the sniper/test/fft-marker application fails with the same error as my application. 

Can you give me any pointers towards were I can start debugging?

Best regards,

Alexandru Iordan

[Wim Heirman]

Can you add the --gdb flag to run-sniper and get a backtrace of where
exactly this is failing?

Thanks,
Wim

> <javascript:>

> > To unsubscribe from this group, send email to

> > snipersim+...@googlegroups.com <javascript:>

> > For more options, visit this group at
> > http://groups.google.com/group/snipersim?hl=en

> <http://groups.google.com/group/snipersim?hl=en>
>

--
dr. ir. Wim Heirman,
ELIS Department, Ghent University, Belgium
Phone: +32-9-264.34.56
E-mail: wim.h...@elis.UGent.be
http://www.elis.UGent.be/~wheirman/

[Alexandru Iordan]

The output of the execution is the following:

~/sniper$ ./run-sniper -n 4 -s markers --gdb -d ../sniper_output/wool/stress/ -c gainestown -- ~/bots/wool-tasks/stress.gcc.wool -p 4 -s 1000 -g 1000 -d 10 -i 1

[SNIPER] Start

Running /home/alexandru/sniper/pin_kit/intel64/bin/pinbin -mt -injection child -xyzzy -enable_vsm 0 -pause_tool 1 -t /home/alexandru/sniper/lib/pin_sim -c /home/alexandru/sniper/config/base.cfg --general/total_cores=4 --general/output_dir=../sniper_output/wool/stress/ --config=/home/alexandru/sniper/config/nehalem.cfg --config=/home/alexandru/sniper/config/gainestown.cfg -g --hooks/numscripts=1 -g --hooks/script0name=/home/alexandru/sniper/scripts/markers.py -g --hooks/script0args= -- /home/alexandru/bots/wool-tasks/stress.gcc.wool -p 4 -s 1000 -g 1000 -d 10 -i 1

Reading symbols from /home/alexandru/sniper/pin_kit/intel64/bin/pinbin...(no debugging symbols found)...done.

Error while reading shared library symbols:

Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /home/alexandru/sniper/pin_kit/intel64/runtime/libdwarf.so]

[Thread debugging using libthread_db enabled]

Error while reading shared library symbols:

Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /home/alexandru/sniper/pin_kit/intel64/runtime/libdwarf.so]

0x00007fdde312f680 in nanosleep () from /lib/libc.so.6

add symbol table from file "/home/alexandru/sniper/lib/pin_sim.so" at

.text_addr = 0x7fdde2a3f330

.data_addr = 0x7fdde30567e0

.bss_addr = 0x7fdde3058240

Resuming

terminate called after throwing an instance of 'std::logic_error'

  what():  __sso_string_base::_M_construct NULL not valid

Program received signal SIGABRT, Aborted.

0x00007fdde30b8a75 in raise () from /lib/libc.so.6

(gdb) quit

A debugging session is active.

Inferior 1 [process 24390] will be detached.

Quit anyway? (y or n) n

Not confirmed.

(gdb) ls

Undefined command: "ls".  Try "help".

(gdb) l

383 {

384   ScopedLock sl(Sim()->getThreadManager()->getLock());

385

386   printf("[SNIPER] Writing logmem allocations\n");

387   logmem_write_allocations();

388   return false;

389 }

390

391 int main(int argc, char *argv[])

392 {

(gdb) 

It looks like there is something wrong with the pin_kit. I downloaded version 2.11. Is that the problem?

Best regards,

Alexandru Iordan

[Wim Heirman]

The problem you're seeing with Pin is that it uses a new Dwarf format
for which your GDB version is too old. This shouldn't matter though.

Can you, once you get at the gdb prompt, give the "backtrace" command?
Also, if "info threads" lists more than one thread, switch into each
of them using "thread N", with N the thread number, and get a
backtrace for each of them.

Does the output directory ../sniper_output/wool/stress/ exist?

-Wim

[Alexandru Iordan]

Yes, the ../sniper_output/wool/stress/ directory exists.

There is only 1 thread and the backtrace of it is the following:

(gdb) bt

#0  0x00007fad5226ea75 in raise () from /lib/libc.so.6

#1  0x00007fad522725c0 in abort () from /lib/libc.so.6

#2  0x00007fad52b248c5 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/libstdc++.so.6

#3  0x00007fad52b22cf6 in ?? () from /usr/lib/libstdc++.so.6

#4  0x00007fad52b22d23 in std::terminate() () from /usr/lib/libstdc++.so.6

#5  0x00007fad52b22e1e in __cxa_throw () from /usr/lib/libstdc++.so.6

#6  0x00007fad52abe987 in std::__throw_logic_error(char const*) () from /usr/lib/libstdc++.so.6

#7  0x00007fad51e2d019 in __gnu_cxx::__sso_string_base<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*> (this=0x7fad4fe56000, __beg=0x0, __end=0x6 <Address 0x6 out of bounds>)

    at /usr/include/c++/4.4/ext/sso_string_base.h:432

#8  0x00007fad51ed2e85 in _M_construct_aux<char const*> () at /usr/include/c++/4.4/ext/sso_string_base.h:101

#9  _M_construct<char const*> () at /usr/include/c++/4.4/ext/sso_string_base.h:116

#10 __sso_string_base<char const*> () at /usr/include/c++/4.4/ext/sso_string_base.h:374

#11 __versa_string () at /usr/include/c++/4.4/ext/vstring.h:216

#12 HooksPy::setup () at /home/alexandru/sniper/common/scripting/hooks_py.cc:37

#13 0x00007fad51ed3205 in HooksPy::init () at /home/alexandru/sniper/common/scripting/hooks_py.cc:16

#14 0x00007fad51ed1ac9 in HooksManager::init (this=0x6477)

    at /home/alexandru/sniper/common/system/hooks_manager_init.cc:46

#15 0x00007fad51e6836c in Simulator::start (this=0x7fad3f64e2e0)

    at /home/alexandru/sniper/common/system/simulator.cc:100

#16 0x00007fad51bfb5fa in main (argc=<value optimized out>, argv=<value optimized out>)

    at /home/alexandru/sniper/pin/../pin/pin_sim.cc:425

#17 0x00000000307c3940 in LEVEL_INJECTOR::UNIX_INJECTEE::StartTool() ()

#18 0x00000000307c67ee in LEVEL_INJECTOR::UNIX_INJECTEE::RunMainThreadOnPinStack(LEVEL_INJECTOR::UNIX_INJECTEE*) ()

#19 0x000000003053d4bc in CallOnStack ()

#20 0x00000000307c7c66 in void LEVEL_INJECTOR::SwitchToPinStack<void (*)(LEVEL_INJECTOR::UNIX_INJECTEE*), LEVEL_INJECTOR::UNIX_INJECTEE*>(void (*)(LEVEL_INJECTOR::UNIX_INJECTEE*), LEVEL_INJECTOR::UNIX_INJECTEE*) ()

#21 0x00000000307c5dfc in LEVEL_INJECTOR::UNIX_INJECTEE::Run() ()

#22 0x00000000307c8366 in LEVEL_INJECTOR::PIN_UNIX_ENVIRONMENT::LaunchPin() ()

#23 0x00000000307b50ee in LEVEL_INJECTOR::PIN_ENVIRONMENT::Main() ()

#24 0x00000000307c21d1 in main ()

(gdb) 

The reason the execution fails can be found in sniper/common/scripting/hooks_py.cc line 37: the GRAPHITE_ROOT variable is not set. If I do an "export GRAPHITE_ROOT=/path_to_sniper" the execution succeeds. 

Because is rather inconvenient to run the export command every time I open a new terminal window, where do you think is the best place to define the GRAPHITE_ROOT variable?

Best regards,

Alexandru Iordan

[Wim Heirman]

Aha, this makes sense, thanks for figuring this out!
Usually we set GRAPHITE_ROOT in our ~/.bashrc
I'll add some code to the run-sniper script to define it in case it's
not set yet.

-Wim