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

Compute confidence intervals in DistributedTreeDriver #83

Closed

Conversation

masterleinad
Copy link
Collaborator

Based on #78, this pull requests improves DistributedTreeDriver further. The idea is as follows:

  • We first run the test a couple of time to have an estimate for mean and variance of the runtime for the individual sections (construction, knn, radius). (We take the maximum over all MPI processes in each iteration).
  • These statistics are used to estimate for each section the number of total iterations needed to get a confidence interval of specified width.
  • We run the maximum of these estimates number iterations (additionally) and output mean, variance and a new confidence interval at the end.

All this is based on CppCon 2015: Bryce Adelstein-Lelbach “Benchmarking C++ Code and Boost.Accumulators.

Sample output:

$ mpiexec -np 2 ./ArborX_DistributedTree.exe
ArborX version: 0.9 (dev)
ArborX hash   : 829b702

Running with arguments:
perform knn search      : true
perform radius search   : true
#points/MPI process     : 50000
#queries/MPI process    : 20000
size of shift           : 1
dimension               : 3


Sample lap 0:
contruction done
knn done
radius done

[...]

Sample lap 9:
contruction done
knn done
radius done

estimated 11 iterations

Total lap 10:
contruction done
knn done
radius done

[...]

Total lap 20:
contruction done
knn done
radius done
=========================================================================

TimeMonitor results over 2 processors

Timer Name   | mean         | variance     | confidence interval         
-------------------------------------------------------------------------
construction | 5.052878e-02 | 2.047170e-05 | [4.841836e-02, 5.263920e-02]
knn          | 1.172640e+00 | 2.565172e-02 | [1.097935e+00, 1.247345e+00]
radius       | 6.593428e-01 | 6.237161e-03 | [6.225057e-01, 6.961799e-01]
=========================================================================

Copy link
Contributor

@dalg24 dalg24 left a comment

Choose a reason for hiding this comment

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

I need more time to review the math but here are a few questions/comments:

  • I would probably want to merge Improve benchmark for distributed tree #78 first and rebase this onto master
  • As much as I like the idea of computing confidence intervals and your using Boost.Accumulators I feel like the way TimeMonitor changes here is quite a stretch and it makes me question some of the design choices. I am more tempted to keep responsibilities separated: (i) a utility that measure time in a distributed context and (ii) a tool for statistics. (Please note that I do not advocate for the current design of TimeMonitor but I am even more skeptic about its evolution)

@masterleinad
Copy link
Collaborator Author

I have no idea why compiling with nvcc_wrapper fails...

double const current_mean = ba::mean(_statistics);
auto const tmp =
z * current_stddev / (relative_error_margin * current_mean / 2.);
return static_cast<int>(std::ceil(tmp * tmp));
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

So far I couldn't find parameters for boost::math::students_t::find_degrees_of_freedom such that the returned value would match the one computed here.

boost::math::students_t::find_degrees_of_freedom(relative_error_margin*current_mean, confidence/2, .9999999, current_stddev)

is just 1.3 times larger though.

@masterleinad
Copy link
Collaborator Author

I have no idea why compiling with nvcc_wrapper fails...

Just having a

 boost::accumulators::accumulator_set<double, ba::stats<ba::tag::count>>;

member variable gives

/opt/boost/include/boost/fusion/iterator/mpl/convert_iterator.hpp(57): error: identifier "" is undefined in device code
/opt/boost/include/boost/fusion/iterator/mpl/convert_iterator.hpp(57): error: identifier "" is undefined in device code
/opt/boost/include/boost/fusion/view/filter_view/filter_view_iterator.hpp(60): error: identifier "" is undefined in device code
/opt/boost/include/boost/fusion/view/filter_view/filter_view_iterator.hpp(60): error: identifier "" is undefined in device code
/opt/boost/include/boost/fusion/algorithm/query/detail/find_if.hpp(208): error: identifier "" is undefined in device code
/opt/boost/include/boost/fusion/algorithm/query/detail/find_if.hpp(208): error: identifier "" is undefined in device code
/opt/boost/include/boost/fusion/algorithm/query/detail/find_if.hpp(208): error: identifier "" is undefined in device code
/opt/boost/include/boost/fusion/iterator/next.hpp(61): error: identifier "" is undefined in device code
/opt/boost/include/boost/fusion/algorithm/query/detail/find_if.hpp(208): error: identifier "" is undefined in device code
/opt/boost/include/boost/fusion/algorithm/query/detail/find_if.hpp(208): error: identifier "" is undefined in device code
/opt/boost/include/boost/fusion/algorithm/query/detail/find_if.hpp(208): error: identifier "" is undefined in device code
/opt/boost/include/boost/fusion/algorithm/iteration/detail/for_each.hpp(48): error: identifier "" is undefined in device code
/opt/boost/include/boost/fusion/algorithm/iteration/detail/for_each.hpp(36): error: identifier "" is undefined in device code
/opt/boost/include/boost/fusion/algorithm/iteration/detail/for_each.hpp(48): error: identifier "" is undefined in device code

when compiling with nvcc_wrapper.

@aprokop aprokop added the enhancement New feature or request label Sep 15, 2019
@aprokop
Copy link
Contributor

aprokop commented Jul 28, 2020

Anyone opposed to closing this? It was a nice attempt, but too complicated with little benefit in practice.

@aprokop aprokop marked this pull request as draft August 13, 2020 18:53
@masterleinad
Copy link
Collaborator Author

Yes, I think we won't do that.

@aprokop aprokop added the testing Anything to do with tests and CI label Sep 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request testing Anything to do with tests and CI
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

None yet

3 participants