public class FindSolverThreadThreshold
extends java.lang.Object
DirectSolverBase subclass should be forced to one thread, and prints the
resulting ThreadLimit table entry -- see DirectSolverBase.maxThreadsNnz(int, int), DirectSolverBase.ThreadLimit and
DirectSolverBase.lookupMaxThreads(maspack.solvers.DirectSolverBase.ThreadLimit[], int) -- ready to paste into that
solver's override.
Some direct solvers incur a large, largely size-independent per-factor
cost to set up their thread team, so that for small matrices using more
than one thread is slower, often by several times, than staying
single-threaded; above some size that overhead becomes negligible against
the actual factorization cost, and more threads help (or at least stop
hurting). This finds that crossover size, expressed as the matrix nnz at
which it occurs, matching the convention DirectSolverBase.maxThreadsNnz(int, int) itself uses.
Unlike a full sweep that measures every thread count at every size,
this only needs to answer a yes/no question at each size it tries --
"does the solver's maximum thread count measurably beat one thread here?"
-- so it can locate the crossover by marching up an ascending list of
candidate sizes and stopping as soon as that answer flips from no to yes.
Since the threshold typically lies well below the largest realistic model
size, this usually finds it after testing only a handful of the smaller,
cheaper candidates, and never pays for the largest, slowest ones at all.
That, in turn, affords something a full sweep can't: re-measuring each
candidate several times (see TRIALS_PER_SIZE) to guard against
run-to-run timing noise before trusting a verdict -- a wrong verdict
partway through the search misguides everything after it, not just one
data point, so it's worth spending time saved elsewhere on making each
verdict it does reach more reliable.
The search assumes the underlying effect is a single step: sizes below
the threshold are all one-thread-only, sizes above it all benefit from
(or are at least not hurt by) more threads, with no size above the
threshold reverting back below it -- so the first "yes" the march
encounters can be trusted as the crossover, with no need to keep
checking larger sizes for a reversal. This matches the DirectSolverBase.ThreadLimit table format, whose entries are range upper
bounds and so cannot express such a reversal either.
Geometry and matrix generation are a cubic hex-element block with a
constrained (indefinite) boundary condition -- see FemMatrixGenerator -- matching the kind of system ArtiSynth's own solves
most often present.
Usage:
java maspack.solvers.FindSolverThreadThreshold -solver Mumps|Pardiso
[-maxThreads n] [-res n,n,...] [-verbose]
| Constructor and Description |
|---|
FindSolverThreadThreshold() |
| Modifier and Type | Method and Description |
|---|---|
static void |
main(java.lang.String[] args) |
void |
run() |