This commit is contained in:
Garry Boyer
2007-09-12 16:06:57 +00:00
parent c2e14554ef
commit d35da4232a
3 changed files with 98 additions and 3 deletions
+3 -1
View File
@@ -18,7 +18,8 @@ namespace math {
/**
* Computes the factorial of an integer.
*/
COMPILER_FUNCTIONAL double Factorial(int d);
COMPILER_FUNCTIONAL
double Factorial(int d);
/**
* Computes the binomial coefficient, n choose k for nonnegative integers
@@ -28,6 +29,7 @@ namespace math {
* @param k the second nonnegative integer argument
* @return the binomial coefficient n choose k
*/
COMPILER_FUNCTIONAL
double BinomialCoefficient(int n, int k);
/**
+4 -1
View File
@@ -447,6 +447,7 @@ class FdKde {
"delta density lo %f > hi %f",
delta->d_density.lo, delta->d_density.hi);
if (likely(delta->d_density.hi != 0)) {
return true;
} else {
@@ -469,8 +470,10 @@ class FdKde {
* r_node.count() / (param.count - q_summary_result.n_pruned);
/*allocated_width *= param.p_global;
allocated_width += param.rel_error_local * delta.d_density.lo * 2;*/
//fprintf(stderr, "%e..%e (%e, %e) %e (%e)\n", delta.d_density.lo, delta.d_density.hi, delta.d_density.width(), allocated_width, q_summary_result.density.lo,
// sqrt(q_node.bound().MaxDistanceSq(q_node.bound())));
if (delta.d_density.width() < allocated_width) {
if (delta.d_density.width() <= allocated_width) {
q_postponed->d_density += delta.d_density;
q_postponed->n_pruned += r_node.count();
return false;
+91 -1
View File
@@ -616,24 +616,114 @@ x \\
\begin{slide}{Experiments - Setup}
% algorithms and data-sets
Data:
\begin{itemize}
\itemt{Speech}
12-dimensional, frequency-domain, with manifold.
Nearest neighbors and KDE.
\itemt{Galaxy}
3-d positions of galactic halos ($\Lambda CDM$).
Two-point correlation.
\itemt{Redshift}
4-dimensional redshift data for quasar detection.
KDE.
\end{itemize}
We run KDE with Gaussian kernel and finite difference method.
\end{slide}
\begin{slide}{Experiments - Overhead}
Two sources of potential overhead studied.
\begin{itemize}
\itemt{Infrastructure} Does cache system cause slowdown?
\begin{itemize}
\itemt{Preliminary Auton Comparison}
THOR's KDE was faster than Auton's by about a factor of 2.
\itemt{FASTlib Comparison}
Compared to well-written FASTlib code, THOR is about 15\% slower.
\end{itemize}
\itemt{Decomposition} Breaking the query tree might result in redundant
work.
\begin{itemize}
\itemt{Experiment} Compare single-thread THOR code with different work granularities.
\itemt{Result} Virtually no degradation seen until query tasks become
small (circa 200 points).
\end{itemize}
\end{itemize}
\end{slide}
\begin{slide}{Experiments - Multithreaded}
Multiple processors on the same computer.
How does THOR scale?
\begin{itemize}
\itemt{Factors}
Multithreaded performance measures CPU cache utilization,
load balance, and lock contention.
\itemt{Experiments}
95\% or better utilization for up to 8 processors.
\itemt{Practice}
For months, we've used it on our dual-core machines, seeing
near-perfect usage every time. I don't have patience for single-threaded
runs anymore.
\end{itemize}
% range - galaxy simulation
% allnn - high-D
% nbc - quasar
\end{slide}
\begin{slide}{Experiments - Cluster}
Works on clusters of at {\it least} 92 CPU's (46 machines).
\begin{itemize}
\item Note: We compare 92 processors to a base case of 8 processors.
\end{itemize}
\begin{tabular}{|r|r|r|r|r|r|}
\hline
{\bf Algorithm} & {\bf Data} & \# Points & Degrad. & Time (s)
\\ \hline
KDE & Speech & 500,000 & 6\% & 124
\\ \hline
KDE & Redshift & 500,000 & 2\% & 82
\\ \hline
Neighbors & Speech & 2,000,000 & 12\% & 114
\\ \hline
Two-Point\footnote{First two-point correlation uses high bandwidth, second with low bandwidth.} & Galaxy & 3,000,000 & 11\% & 86
\\ \hline
Two-Point & Galaxy & 16,000,000 & 3\% & 151
\\ \hline
\end{tabular}
% range - galaxy simulation
% allnn - high-D
% nbc - quasar
\end{slide}
\begin{slide}{Discussion/Conclusion}
\begin{slide}{Experiments - Issues}
There are some pitfalls that need to be addressed.
\begin{itemize}
\itemt{Problem Size}
Small, easy tasks, like low-dimensionality nearest neighbors, scale poorly on multiple machines.
The serial algorithm is too fast to warrant parallelization.
\itemt{Tree Building}
Reading the data set and building the tree is currently on one processor.
However, parallel tree-building algorithms do exist.
\itemt{Communication Catch-22}
All test cases, except low-bandwidth two-point correlation, required
all machines to need almost all the data, but the serial algorithm
is slow enough to allow scalability. Low-dimension nearest neighbors
doesn't have this problem so much, but parallelizes poorly.
However, affinity propagation shows a nice balance.
\end{itemize}
\end{slide}
\begin{slide}{Conclusion}
In short,
\begin{itemize}
\item THOR solves all second-order GNP's, and is
inherently parallel.
\item THOR allows persons with some dual-tree knowledge
and virtually no parallelization knowledge to write parallel code.
\item THOR is quite efficient for the problems that need
the most parallelization, especially for a first-generation
implementation.
\end{itemize}
\end{slide}
\end{document}