I had some parallel build problems for particular combinations of tests targets so I took a really simple example to the CMake mailing list, and the upshot is parallel builds will not handle dependencies correctly if there are multiple targets mentioned on the "make" command-line that have common target dependencies. Those common dependencies will get multiply built meaning that at best you lose efficiency and at worst if the timing is right the multiple builds interfere with each other causing corruption in the results. So the recent timing result I posted here, i.e.,
> softw...@raven> time (make -j4 test_c_psc test_cxx_psc \ > test_f77_psc test_f95_psc> make_psc.out ; make test_some_diff_psc) > > real 0m27.556s > user 0m21.445s > sys 0m5.096s > > For this selection of languages, there is a factor of 1.6 improvement in > elapsed time due to the two cpu's on my platform. underestimates the efficiency improvement and may produce bogus or even completely corrupt results. As a result of the advice I got on the CMake list I have removed (as of revision 10496) the test_some_diff_psc target since it simply encourages incorrect parallel builds with multiple targets as above. Instead, I will encourage use of the test_diff_psc target (renamed from test_all_diff_psc) instead. That target tests every language with the psc device driver and compares the PostScript and stdout results. Here are some real timing comparisons between ctest and test_diff_psc. softw...@raven> time ctest -R '(examples_c|examples_cxx|examples_f77|examples_f95|examples_java|examples_octave|examples_python|examples_tcl|examples_pdl|examples_ada|examples_ocaml|examples_lua|examples_d|examples_compare)' >& ctest.out real 4m25.790s user 1m55.643s sys 0m13.637s softw...@raven> time make -j4 test_diff_psc >& make_test.out real 2m6.475s user 2m0.372s sys 0m16.989s Exactly the same tests are run in each case and "make all" was run before each so this is an honest timing comparison that demonstrates the expected factor of two+ improvement in speed for parallel builds and tests on my two-cpu PC. Note the test_diff_psc target has proper dependencies so re-runs of that target will re-run just the minimal test targets necessary to do the PostScript and stdin comparisons depending on what source code has been changed by a PLplot developer. That should be more convenient for developers than running "make all" and ctest with the appropriate -R option to redo the desired subset of tests. More later as I continue to develop the common (to both the build-tree when BUILD_TEST=ON and also the installed examples tree) testing framework for PLplot. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
