drmemory exhibiting poor performance on SPEC2006

[Mahwish Arif]

Hi,

I am running drmemory on SPEC2006 benchmarks on two different machines with the specs given below. One Machine 1, the drmemory process will get killed after running out of memory. On Machine 2,it does not get killed, but exhibits very poor performance. As a reference, mcf had an overhead of 9x compared to native execution, bzip2 had 67x and perlbench has > 2000x. The benchmarks were compiled with gcc 5.5and -O2 flag. 

Any idea why this might be happening. The numbers in drmemory paper are very different from this. 

Machine 1

Intel(R) Xeon(R) W-2195 CPU @ 2.30GHz

total physical cores: 18 

L2 cache: 18MB

RAM: 256GB

Machine 2

Intel(R) Xeon(R) Gold 6230R CPU @ 2.10GHz

total sockets: 2

total physical cores per socket: 26

RAM: 792GB 

L2 cache: 52MB

[Derek Bruening]

Unfortunately there are not enough developers to add fast paths for new features enabled by more recent compilers on newer hardware and so some operations are on slow paths by default these days.  If you are interested in helping out that would be appreciated.

--

---
You received this message because you are subscribed to the Google Groups "Dr. Memory Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drmemory-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/drmemory-users/291ae7a4-9bed-46f5-ac6c-9be680c0e91fn%40googlegroups.com.

[Mahwish Arif]

Thank you. What type of features you think may not be supported in the current version? I see that the paper mentions 32-bit binaries, whereas I have been using 64-bit binaries? Could it be related to that, or something else? Thanks 

[Derek Bruening]

Key operations like stack shadowing are using slowpaths as the 64-bit versions of the fastpaths have not been created: https://github.com/DynamoRIO/drmemory/issues/111#issuecomment-325562859
SIMD operations are also on the slowpath when any undefined bits are set anywhere, which happens when just moving data around, so SIMD-heavy apps may not perform as well as we would like.
There are statistics on slowpaths broken down by reason in debug build logs ("Per-opcode slow path executions", "Per-size slow path executions", etc.).  That is where I would start.

To view this discussion on the web visit https://groups.google.com/d/msgid/drmemory-users/b4ba4fae-f20a-4a7c-85c8-1e8b83c437fbn%40googlegroups.com.