Since DynamoRIO has just been re-released (DynamoRIO Dynamic Instrumentation Tool Platform, DynamoRIO Dynamic Instrumentation Tool Platform for Linux) let's re-evaluate where it stands performance-wise versus another popular dynamic instrumentation system, Pin.
Pin's 2005 PLDI paper (Pin: Building Customized Program Analysis Tools with Dynamic Instrumentation) gives performance numbers for DynamoRIO version 0.9.3 and Valgrind version 2.2.0 versus the latest Pin at the time. The paper shows base performance as well as performance with a simple basic block execution count tool. Let's model our experiments on those measurements.
I'm using DynamoRIO version 0.9.6 build 9601 and Pin pin-2.5-20751-gcc.4.0.0-ia32_intel64-linux. My compiler is:
gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) (GCC)
I ran the SPECCPU2000 integer benchmarks, just like the paper (also because I have yet to get a copy of SPECCPU2006 set up...). I used an Intel Core 2 Q9300 quad-core processor at 2.50GHz on a machine with 4GB RAM running Fedora 9. The benchmarks and tools were all 32-bit.
Here are the results with no tool (just measuring the base infrastructure):
DynamoRIO is consistently faster than Pin, with an average slowdown of 34% versus Pin's 71%.
And here are the results with the basic block execution count tools (source code displayed below):
For DynamoRIO, two different versions of the tool are shown. The first always saves the arithmetic flags, as was done in the Pin paper. The second performs a simple analysis and only saves the flags when necessary. Both outperform the Pin tool.
Pin Client
I followed the advice at http://rogue.colorado.edu/Pin/docs/20751/Pin/html/index.html#PERFORMANCE and used IPOINT_ANYWHERE and PIN_FAST_ANALYSIS_CALL. Note that both of these clients ignore racy increments to the counter from multiple threads.
#include "pin.H"
#include <iostream>
int bbcount;
VOID PIN_FAST_ANALYSIS_CALL docount() { bbcount++; }
VOID Trace(TRACE trace, VOID *v) {
for (BBL bbl = TRACE_BblHead(trace); BBL_Valid(bbl); bbl = BBL_Next(bbl)) {
BBL_InsertCall(bbl, IPOINT_ANYWHERE, AFUNPTR(docount),
IARG_FAST_ANALYSIS_CALL, IARG_END);
}
}
VOID Fini(int, VOID * v) {
#ifdef SHOW_RESULTS
cout << "Count is " << bbcount << endl;
#endif
}
int main(int argc, CHAR *argv[]) {
PIN_InitSymbols();
PIN_Init(argc, argv);
TRACE_AddInstrumentFunction(Trace, 0);
PIN_AddFiniFunction(Fini, 0);
PIN_StartProgram();
return 0;
}
DynamoRIO Client
Note that both of these clients ignore racy increments to the counter from multiple threads. For DynamoRIO, adding a LOCK prefix to the inc instruction is easy to do; however, it has a significant performance impact (a three times slowdown in a quick test). Using thread-private caches and aggregating the count at the end would be more performant.
#include "dr_api.h"
#define TESTALL(mask, var) (((mask) & (var)) == (mask))
#define TESTANY(mask, var) (((mask) & (var)) != 0)
static int global_count;
static dr_emit_flags_t
event_basic_block(void *drcontext, void *tag, instrlist_t *bb,
bool for_trace, bool translating)
{
instr_t *instr, *first = instrlist_first(bb);
uint flags;
/* Our inc can go anywhere, so find a spot where flags are dead. */
for (instr = first; instr != NULL; instr = instr_get_next(instr)) {
flags = instr_get_arith_flags(instr);
/* OP_inc doesn't write CF but not worth distinguishing */
if (TESTALL(EFLAGS_WRITE_6, flags) && !TESTANY(EFLAGS_READ_6, flags))
break;
}
if (instr == NULL)
dr_save_arith_flags(drcontext, bb, first, SPILL_SLOT_1);
instrlist_meta_preinsert
(bb, (instr == NULL) ? first : instr,
INSTR_CREATE_inc(drcontext, OPND_CREATE_ABSMEM
((byte *)&global_count, OPSZ_4)));
if (instr == NULL)
dr_restore_arith_flags(drcontext, bb, first, SPILL_SLOT_1);
return DR_EMIT_DEFAULT;
}
static void event_exit(void)
{
#ifdef SHOW_RESULTS
dr_printf("Count is %d\n", global_count);
#endif
}
DR_EXPORT void dr_init(client_id_t id)
{
dr_register_exit_event(event_exit);
dr_register_bb_event(event_basic_block);
}
