Closed p5pRT closed 12 years ago
forthcoming patch alters make test.valgrind target and t/TEST so that it can also run linux perf stat on all the perl tests.
With it\, and following env\, make test.valgrind works:
VALGRIND=perf VG_TEST=--help VG_OPTS='stat -- '
$> make test.valgrind; PERL_VALGRIND=1 VALGRIND=perf ./runtests choose t/base/cond....................................................ok t/base/if......................................................ok t/base/lex.....................................................ok ...
[jimc@groucho perl]$ cat t/base/*.perf-stat
Performance counter stats for './perl base/cond.t':
5.882071 task-clock # 0.850 CPUs utilized
1 context-switches # 0.000 M/sec
1 CPU-migrations # 0.000 M/sec
483 page-faults # 0.082 M/sec
4\,688\,843 cycles # 0.797 GHz
\
0.006920536 seconds time elapsed
heres the patch.
On Fri Sep 09 12:50:37 2011\, yoduh wrote:
heres the patch.
Thank you. Applied as c7b956bbbaff0c4616c7bf80a5b723a58b55bbf6.
The RT System itself - Status changed from 'new' to 'open'
@cpansprout - Status changed from 'open' to 'resolved'
On Fri\, Sep 9\, 2011 at 10:42 PM\, Father Chrysostomos via RT \perlbug\-followup@​perl\.org wrote:
On Fri Sep 09 12:50:37 2011\, yoduh wrote:
heres the patch.
Thank you. Applied as c7b956bbbaff0c4616c7bf80a5b723a58b55bbf6.
Thank you.
Does this mean that ?= is portable to all unix make exes ?
Set VALGRIND var conditionally\, to allow cmdline override (this is probably non-portable\, will need review at least).
--- a/Makefile.SH +++ b/Makefile.SH @@ -333\,7 +333\,8 @@ $make_set_make
# If you're going to use valgrind and it can't be invoked as plain valgrind # then you'll need to change this\, or override it on the make command line. -VALGRIND=valgrind +VALGRIND ?= valgrind +VG_TEST ?= ./perl -e 1 2>/dev/null
Apologies for not noting this more LOUDLY\, ie in the email too.
On Fri Sep 09 23:37:26 2011\, yoduh wrote:
On Fri\, Sep 9\, 2011 at 10:42 PM\, Father Chrysostomos via RT \perlbug\-followup@​perl\.org wrote:
On Fri Sep 09 12:50:37 2011\, yoduh wrote:
heres the patch.
Thank you. �Applied as c7b956bbbaff0c4616c7bf80a5b723a58b55bbf6.
Thank you.
Does this mean that ?= is portable to all unix make exes ?
Er\, I *hope* so. It passed all tests for me. I didn’t think about it. We’ll see by tomorrow whether it causes smoke.
(I probably should have pushed this to a smoke-me branch first.)
Set VALGRIND var conditionally\, to allow cmdline override \(this is probably non\-portable\, will need review at least\)\.
--- a/Makefile.SH +++ b/Makefile.SH @@ -333\,7 +333\,8 @@ $make_set_make
# If you're going to use valgrind and it can't be invoked as plain valgrind # then you'll need to change this\, or override it on the make command line. -VALGRIND=valgrind +VALGRIND ?= valgrind +VG_TEST ?= ./perl -e 1 2>/dev/null
Apologies for not noting this more LOUDLY\, ie in the email too.
re-using this ticket\, since its the same topic. hope thats fine.
1. adds .gitignore entries for *.valgrind\, *.perf-stat\, *.cachegrind files 2. adds prose to perlhack.pod where test.valgrind target is discussed 3. cleans up cachegrind.out.$pid intermediate files not cleaned up by valgrind.
Ive considered creating test.perf and test.cachegrind targets; - easier invocation\, w/o fiddling w environment vars - test.valgrind needs -g\, test.perf would not.
If this makes sense\, perhaps patch 2 should wait.
On Sun Sep 11 22:54:15 2011\, yoduh wrote:
re-using this ticket\, since its the same topic. hope thats fine.
1. adds .gitignore entries for *.valgrind\, *.perf-stat\, *.cachegrind files 2. adds prose to perlhack.pod where test.valgrind target is discussed 3. cleans up cachegrind.out.$pid intermediate files not cleaned up by valgrind.
Ive considered creating test.perf and test.cachegrind targets; - easier invocation\, w/o fiddling w environment vars - test.valgrind needs -g\, test.perf would not.
If this makes sense\, perhaps patch 2 should wait.
That does make sense. I’ll wait.
I’ve applied 1 and 3 as 87dfd78cc5 and c96083ea\, respectively. Thank you.
@cpansprout - Status changed from 'resolved' to 'open'
Ive considered creating test.perf and test.cachegrind targets; - easier invocation\, w/o fiddling w environment vars - test.valgrind needs -g\, test.perf would not.
If this makes sense\, perhaps patch 2 should wait.
That does make sense. I’ll wait.
I’ve applied 1 and 3 as 87dfd78cc5 and c96083ea\, respectively. Thank you.
Ok\, heres those 2 new make targets.
a few new questions:
1- all the VALGRIND-ish envars are now used more generally\, perhaps they need a more general name. Suggestions / bikeshedding ?
PERL_DUT - (mnemonic - device under test (or really tool)) replaces PERL_VALGRIND\, which is just a flag (in t/TEST\, t/test.pl) since the tests run under some tool\, this seems to capture it.
PERL_DUTOOL - name/path of tool used when PERL_DUT is true.
VG_TEST - can go away\, hardcoded in each target. test.perf doesnt actually run that test anymore\, since I dropped its dependency on perl.valgrind.config
2- linux-perf tool version.
released perf doesnt understand --log-fd\, so patch above doesnt use it But it can\, if you have newer version\, and add it to VG_OPTS. Which future tense should I document for perlhack ?
3- PERL_DUT_DIR
Id like to add a new envar\, as a destination for all the *.{valgrind\,cachegrind\,perf-stat} files\, probably including a dated subdir to archive them automatically when set. Id also put the Storable file written if -d $ENV{HARNESS_TIMER} Sensible ? good name ?
uhm hold off on applying that patch. I think I botched some of the VG_OPTS defaults..
On Mon\, Sep 12\, 2011 at 1:02 PM\, Jim Cromie \jim\.cromie@​gmail\.com wrote:
Ive considered creating test.perf and test.cachegrind targets; - easier invocation\, w/o fiddling w environment vars - test.valgrind needs -g\, test.perf would not.
If this makes sense\, perhaps patch 2 should wait.
That does make sense. I’ll wait.
I’ve applied 1 and 3 as 87dfd78cc5 and c96083ea\, respectively. Thank you.
Ok\, heres those 2 new make targets.
a few new questions:
1- all the VALGRIND-ish envars are now used more generally\, perhaps they need a more general name. Suggestions / bikeshedding ?
PERL_DUT - (mnemonic - device under test (or really tool)) replaces PERL_VALGRIND\, which is just a flag (in t/TEST\, t/test.pl) since the tests run under some tool\, this seems to capture it.
PERL_DUTOOL - name/path of tool used when PERL_DUT is true.
VG_TEST - can go away\, hardcoded in each target. test.perf doesnt actually run that test anymore\, since I dropped its dependency on perl.valgrind.config
2- linux-perf tool version.
released perf doesnt understand --log-fd\, so patch above doesnt use it But it can\, if you have newer version\, and add it to VG_OPTS. Which future tense should I document for perlhack ?
3- PERL_DUT_DIR
Id like to add a new envar\, as a destination for all the *.{valgrind\,cachegrind\,perf-stat} files\, probably including a dated subdir to archive them automatically when set. Id also put the Storable file written if -d $ENV{HARNESS_TIMER} Sensible ? good name ?
1 - fixes gmake-isms by adding those ?= conditionals only on linux\, which uses gmake by default
2 - emit valgrind* targets only on linux.
On Wed\, Sep 28\, 2011 at 04:50:49PM -0600\, Jim Cromie wrote:
1 - fixes gmake-isms by adding those ?= conditionals only on linux\, which uses gmake by default
2 - emit valgrind* targets only on linux.
valgrind is available on darwin* too.
Why is the gmake-ism is needed? Variables set on the make command-line should override those set in the Makefile.
Tony
* though apparently not on Lion
On Wed\, Sep 28\, 2011 at 5:54 PM\, Tony Cook \tony@​develop\-help\.com wrote:
On Wed\, Sep 28\, 2011 at 04:50:49PM -0600\, Jim Cromie wrote:
1 - fixes gmake-isms by adding those ?= conditionals only on linux\, which uses gmake by default
2 - emit valgrind* targets only on linux.
valgrind is available on darwin* too.
whats the $osname:$osver value to use in the cases ?
Why is the gmake-ism is needed?
its not essential. I tried it\, it worked as Id hoped\, I moved on.
For the fix\, Nicholas outlined 3 choices\, I chose 1\, since that also moved towards supporting a test.perf target.
Variables set on the make command-line should override those set in the Makefile.
Id expect ?= to work that way\, however the var was previously set.
Tony
* though apparently not on Lion
On Wed\, Sep 28\, 2011 at 06:57:24PM -0600\, Jim Cromie wrote:
On Wed\, Sep 28\, 2011 at 5:54 PM\, Tony Cook \tony@​develop\-help\.com wrote:
On Wed\, Sep 28\, 2011 at 04:50:49PM -0600\, Jim Cromie wrote:
1 - fixes gmake-isms by adding those ?= conditionals only on linux\, which uses gmake by default
2 - emit valgrind* targets only on linux.
valgrind is available on darwin* too.
whats the $osname:$osver value to use in the cases ?
No need.
Thanks\, applied as cfe76a0a8e5b6f21601522c788686e820ba933dd and 45ed6be318926c8b79c4ab96ac82eac9f727de66.
I've added Darwin in 0961731461727bea7a75cf92326539ddb48cbfce.
I've updated the URL and platforms in perlhacktips.pod in 0061d4fab85ba13ecc6cb1c4657841dbb1b85efb.
Tony
@tonycoz - Status changed from 'open' to 'resolved'
Migrated from rt.perl.org#98788 (status was 'resolved')
Searchable as RT98788$