Overview

Sigil2 is a framework designed to help analyze the dynamic behavior of applications. We call this dynamic behavior, with its given inputs and state, the workload. Having this workload is very useful for debugging, performance profiling, and simulation on hardware. Sigil2 was born from the need to generate application traces for trace-driven simulation, so low-level, detailed traces are the primary use-case.

Workloads

One of the main goals behind Sigil2 is providing a straightforward interface to represent and analyze workloads. A workload can be represented in many ways, and each way has different requirements.

...you might represent a workload as a simple assembly instruction trace:

push   %rbp
push   %rbx
mov    %rsi,%rbp
mov    %edi,%ebx
sub    $0x8,%rsp
callq  4377b0 <_Z17myfuncv>
callq  4261e0 <_ZN5myotherfunc>
mov    %rbp,%rdx
mov    %ebx,%esi
mov    %rax,%rdi
callq  422460 <_ZN5GO>
add    $0x8,%rsp
xor    %eax,%eax
pop    %rbx
pop    %rbp
retq

...or you might represent a workload as a call graph:

...or you might represent a workload as a memory trace:

ADDR         BYTES
0xdeadbeef   8
0x12345678   4
0x00000000   1
...

...or more complex representations. Each of these representations are made up of the same event categories, albeit at different levels of granularity.

Event Primitives

Because of the variety of use-cases for analyzing workloads, Sigil2 decided to present workloads as a set of extensible primitives.

Event Primitive	Description
Compute	some transformation of data
Memory	some movement of data
Control Flow	divergence in an event stream
Synchronization	ordering between separate event streams
Context	grouping of events

The format of these events is not defined, but you can imagine that events would look like:

...
compute     FLOP,   add,   SIMD4
memory      write,  4B,    <addr1>
memory      read,   16B,   <addr2>
context     func,   enter, hello_world_thread
sync        create, <TID1>
...

Todo

More detail is discussed futher in ???

Event Generation

Many tools exist to capture workloads:

• static instrumentation tools
  • PEBIL
  • LLVM (e.g. Contech)
• dynamic binary instrumentation tools
  • Valgrind
  • DynamoRIO
  • PIN
  • GPGPU specific
• hardware performance counter sampling
  • architecture-specific
• simulation probes
  • gem5
  • SniperSim
  • Multi2Sim
• and others

Each tool has its merits depending on the desired granularity and source of the event trace. Execution-driven simulators are great for fine-grained, low-level traces, but may be impractical for a large workload. Most DBI tools do a good job of obvserving the instruction stream of general purpose CPU workloads, but may not be useful when looking at workloads that use peripheral devices like GPUs or third-party IP.

Sigil2 recognizes this and creates an abstraction to the underlying tool that observes the workload. Events are translated into Sigil2 event primitives that are then presented to the user for further processing. The tool used for event generation is a Sigil2 frontend, and the user-defined processing on those events is a Sigil2 backend. Currently, backends are written as C++ static plugins to Sigil2, although there is room for expansion, given enough interest.