You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I set out this week to run (and then, of course, port) benchdnn/ timings.
executing the rdpmc instruction was always segfaulting for me on Ubuntu 16.04,
kernel 4.4.0-93-generic.
I worked around by following kernel tools "perf" code. After opening a fd and mmap,
the rdpmc instruction was OK to use, and gave reasonable timing values.
Q1: Is there a reason to avoid usual rdtsc (optionally w/ cpuid to flush pipeline)?
Q2: Is there simpler "magic" to get rdpmc to work? (after all, I do not really even have
to use the mmaped page, because you're using the 'magic number' approach in your
rdpmc routine.)
Note3: If you did want to use the mmap'ed perf page, it seems it gives you the wall-time
conversion algorithm for free.
The text was updated successfully, but these errors were encountered:
Well, benchdnn compiling but segfaulting on some linux systems might be a bug. Granted it is not critical, because it is in a tests/benchdnn/ subdirectory and can be fixed in several ways.
I set out this week to run (and then, of course, port) benchdnn/ timings.
executing the rdpmc instruction was always segfaulting for me on Ubuntu 16.04,
kernel 4.4.0-93-generic.
I worked around by following kernel tools "perf" code. After opening a fd and mmap,
the rdpmc instruction was OK to use, and gave reasonable timing values.
Q1: Is there a reason to avoid usual rdtsc (optionally w/ cpuid to flush pipeline)?
Q2: Is there simpler "magic" to get rdpmc to work? (after all, I do not really even have
to use the mmaped page, because you're using the 'magic number' approach in your
rdpmc routine.)
Note3: If you did want to use the mmap'ed perf page, it seems it gives you the wall-time
conversion algorithm for free.
The text was updated successfully, but these errors were encountered: