Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Try using precompiled headers to speed up tests #672

Closed
wants to merge 5 commits into from

Conversation

seantalts
Copy link
Member

Submission Checklist

  • Run unit tests: ./runTests.py test/unit
  • Run cpplint: make cpplint
  • Declare copyright holder and open-source license: see below

Copyright and Licensing

Please list the copyright holder for the work you are submitting (this will be you or your assignee, such as a university or company): Columbia University

By submitting this pull request, the copyright holder is agreeing to license the submitted work under the following licenses:

@seantalts seantalts force-pushed the build/precompiled-headers branch 4 times, most recently from 7a04063 to 5928743 Compare November 5, 2017 16:58
@seantalts
Copy link
Member Author

In my local tests, this speeds up some of the tests with heavier includes by about 25% :)

@bob-carpenter
Copy link
Contributor

bob-carpenter commented Nov 5, 2017 via email

@seantalts seantalts changed the title [WIP] Try using precompiled headers to speed up tests Try using precompiled headers to speed up tests Nov 6, 2017
@seantalts
Copy link
Member Author

I think this is ready for review - but it only saves 6 minutes from the new distribution tests (out of 103 minutes) and 12 minutes (out of 28 - down to 16 minutes) on the Unit tests.

@seantalts
Copy link
Member Author

Does @syclik or @sakrejda want to take a look at this for me? Still working on that PR triage system, haha.

Copy link
Member

@syclik syclik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So... I don't think it works. Here's what I tried from a clean build:

./runTests.py test/unit/math/rev/scal/fun/log2_test.cpp
touch stan/math/prim/scal/fun/log2.hpp 
./runTests.py test/unit/math/rev/scal/fun/log2_test.cpp

After that second time of trying to build the test, I see this (which is not what you see in the current develop branch):

make -j1 test/unit/math/rev/scal/fun/log2_test
clang++ -Wall -I . -isystem lib/eigen_3.3.3 -isystem lib/boost_1.64.0 -isystem lib/cvodes_2.9.0/include -std=c++1y -DBOOST_RESULT_OF_USE_TR1 -DBOOST_NO_DECLTYPE -DBOOST_DISABLE_ASSERTS -DBOOST_PHOENIX_NO_VARIADIC_EXPRESSION -Wno-unused-function -Wno-uninitialized -stdlib=libc++ -Wno-unknown-warning-option -Wno-tautological-compare -Wsign-compare -DGTEST_USE_OWN_TR1_TUPLE -isystem lib/gtest_1.7.0/include -isystem lib/gtest_1.7.0 -O3 -DGTEST_USE_OWN_TR1_TUPLE -isystem lib/gtest_1.7.0/include -isystem lib/gtest_1.7.0 -O3 -DNO_FPRINTF_OUTPUT -pipe  -c -include-pch stan/math/rev/scal.hpp.gch -o test/unit/math/rev/scal/fun/log2_test.o test/unit/math/rev/scal/fun/log2_test.cpp
fatal error: file 'stan/math/prim/scal/fun/log2.hpp' has been modified since the
      precompiled header 'stan/math/rev/scal.hpp.gch' was built
note: please rebuild precompiled header 'stan/math/rev/scal.hpp.gch'
1 error generated.
make: *** [test/unit/math/rev/scal/fun/log2_test.o] Error 1
make -j1 test/unit/math/rev/scal/fun/log2_test failed

@seantalts
Copy link
Member Author

Good call, I didn't test that because I usually just recompile everything anyway out of caution. Will fix.

@seantalts
Copy link
Member Author

Oh right, and here's the reason:

make: `test/unit/math/rev/scal/fun/log2_test' is up to date.

Make isn't set up to actually do proper dependency analysis. I would argue the current behavior is preferable as it lets you know when you're testing something that's out of date. Should we fix make's dependency resolution problems in this branch or start a new one?

@syclik
Copy link
Member

syclik commented Nov 7, 2017

can you clarify? I don't understand what you posted.

@syclik
Copy link
Member

syclik commented Nov 7, 2017

And here's the behavior, as expected, on develop:

$ ./runTests.py test/unit/math/rev/scal/fun/log2_test.cpp
------------------------------------------------------------
make -j1 test/unit/math/rev/scal/fun/log2_test
make: `test/unit/math/rev/scal/fun/log2_test' is up to date.
------------------------------------------------------------
test/unit/math/rev/scal/fun/log2_test --gtest_output="xml:test/unit/math/rev/scal/fun/log2_test.xml"
Running main() from gtest_main.cc
[==========] Running 3 tests from 1 test case.
[----------] Global test environment set-up.
[----------] 3 tests from AgradRev
[ RUN      ] AgradRev.log2
[       OK ] AgradRev.log2 (0 ms)
[ RUN      ] AgradRev.log2_NaN
[       OK ] AgradRev.log2_NaN (0 ms)
[ RUN      ] AgradRev.check_varis_on_stack
[       OK ] AgradRev.check_varis_on_stack (0 ms)
[----------] 3 tests from AgradRev (0 ms total)

[----------] Global test environment tear-down
[==========] 3 tests from 1 test case ran. (0 ms total)
[  PASSED  ] 3 tests.
$ touch stan/math/prim/scal/fun/log2.hpp 
$ ./runTests.py test/unit/math/rev/scal/fun/log2_test.cpp
------------------------------------------------------------
make -j1 test/unit/math/rev/scal/fun/log2_test
clang++ -Wall -I . -isystem lib/eigen_3.3.3 -isystem lib/boost_1.64.0 -isystem lib/cvodes_2.9.0/include -std=c++1y -DBOOST_RESULT_OF_USE_TR1 -DBOOST_NO_DECLTYPE -DBOOST_DISABLE_ASSERTS -DBOOST_PHOENIX_NO_VARIADIC_EXPRESSION -Wno-unused-function -Wno-uninitialized -stdlib=libc++ -Wno-unknown-warning-option -Wno-tautological-compare -Wsign-compare -DGTEST_USE_OWN_TR1_TUPLE -isystem lib/gtest_1.7.0/include -isystem lib/gtest_1.7.0 -O3 -DGTEST_USE_OWN_TR1_TUPLE -isystem lib/gtest_1.7.0/include -isystem lib/gtest_1.7.0 -O3 -DNO_FPRINTF_OUTPUT -pipe  -c -o test/unit/math/rev/scal/fun/log2_test.o test/unit/math/rev/scal/fun/log2_test.cpp
clang++ -Wall -I . -isystem lib/eigen_3.3.3 -isystem lib/boost_1.64.0 -isystem lib/cvodes_2.9.0/include -std=c++1y -DBOOST_RESULT_OF_USE_TR1 -DBOOST_NO_DECLTYPE -DBOOST_DISABLE_ASSERTS -DBOOST_PHOENIX_NO_VARIADIC_EXPRESSION -Wno-unused-function -Wno-uninitialized -stdlib=libc++ -Wno-unknown-warning-option -Wno-tautological-compare -Wsign-compare -DGTEST_USE_OWN_TR1_TUPLE -isystem lib/gtest_1.7.0/include -isystem lib/gtest_1.7.0 -O3 -DNO_FPRINTF_OUTPUT -pipe   -o test/unit/math/rev/scal/fun/log2_test test/unit/math/rev/scal/fun/log2_test.o lib/gtest_1.7.0/src/gtest_main.cc lib/gtest_1.7.0/src/gtest-all.o
------------------------------------------------------------
test/unit/math/rev/scal/fun/log2_test --gtest_output="xml:test/unit/math/rev/scal/fun/log2_test.xml"
Running main() from gtest_main.cc
[==========] Running 3 tests from 1 test case.
[----------] Global test environment set-up.
[----------] 3 tests from AgradRev
[ RUN      ] AgradRev.log2
[       OK ] AgradRev.log2 (0 ms)
[ RUN      ] AgradRev.log2_NaN
[       OK ] AgradRev.log2_NaN (0 ms)
[ RUN      ] AgradRev.check_varis_on_stack
[       OK ] AgradRev.check_varis_on_stack (0 ms)
[----------] 3 tests from AgradRev (0 ms total)

[----------] Global test environment tear-down
[==========] 3 tests from 1 test case ran. (0 ms total)
[  PASSED  ] 3 tests.

@syclik
Copy link
Member

syclik commented Nov 7, 2017

Not easy to see in the output above, but what I'm showing is on develop, if I update the source file, it will automatically rebuild the test.

@seantalts
Copy link
Member Author

Interesting, apparently if I touch it soon enough after making it make considers that to be the same time. If I wait a second it does as you show! My bad. Still trying to fix...

@syclik
Copy link
Member

syclik commented Nov 7, 2017 via email

@seantalts
Copy link
Member Author

I'm not sure how to do that without repeating my logic for figuring out which header file to pre-compile, any suggestions? The commit I pushed generates a .d file for the 14 or so "end-user" includes (like prim/scal.hpp) and include those. It's not great.

@syclik
Copy link
Member

syclik commented Nov 14, 2017

I'll look into this later this week.

@seantalts
Copy link
Member Author

I think it might be best to fix it to do as you said above, I just haven't had time recently to work on it and might not for the next few weeks. Should I close the PR for now?

@syclik
Copy link
Member

syclik commented Nov 20, 2017

@seantalts, up to you. Or maybe mark this as "WIP" in the title?

@seantalts
Copy link
Member Author

Yeah let me just close this for now. Hope to get to it in the next few weeks.

@seantalts seantalts closed this Nov 22, 2017
@syclik syclik deleted the build/precompiled-headers branch September 15, 2022 14:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants