GitLab

This performs roughly an order of magnitude better than the old
implementation on a quad core processor.

vtkm::Id could be just 32bits, which limits the number of values we
would be able to store for large arrays.

The assertion assumes that the RHS of the join operation has not been
yet reduced, which is not correct.

Rather than falling back to the parallel-oriented algorithm in
DeviceAdapterGeneral, use std::unique.

TBB's ReduceByKey was using the generic DeviceAdapterGeneral
implementation and was about 50x slower than the serial implementation,
which is very efficient.

This patch improves TBB's RBK implementation significantly, though it still
does not scale well. On a quad core processor, this implementation performs
comparably or slightly worse than the highly efficient serial algorithm.
More than 4 cores may be needed to see sufficient parallel speedup that
would overcome the TBB overhead, and grain size does not seem to affect the
performance significantly.

Previously, ConvertNumComponentsToOffsets always used TryCompile on the
global set of runtime devices. That is still the default behavior, but
now you are able to specify your own runtime tracker. Also, there are
now versions of ConvertNumComponentsToOffsets that take a device adapter
tag.

Add 'N-dimensional histogram, histogram marginalization and entropy calculation worklets and filters'

Merge branch 'streamline_returntype' of gitlab.kitware.com:dpugmire/vtk-m into streamline_returntype

Merge branch 'streamline_returntype' of gitlab.kitware.com:dpugmire/vtk-m into streamline_returntype

VTK-m is now able to run algorithms on structured points that require the
local point neighbors in a highly efficient manner.

Previously once an ArrayHandle was stolen it was placed in an invalid state
where it could not used again by VTK-m. Now instead after being stolen it
is placed into a state where it is identical to memory allocated outside
of VTK-m and passed in.

By using the auto keyword and decltype we can reduce the number of
complex typedefs that exist when writing device adapter algorithms.
The goal being that it is easier for developers to see the actual
algorithms being implemented, by reducing the amount of template
'noise'.

Previously ArrayHandleReverse would only work if it was provided an explicit
users array to map too. But this doesn't need to be so, if a user wants to
start by constructing an ArrayHandleReverse we should allow that.

The side effect of this, is that some very tricky code in the DeviceAdapters
can be removed, that explicitly was added to allow output to ArrayHandleReverse

1) Don't require a DeviceAdapter for the BuildConnectivity function (#131)
2) Explicitly instantiate default CellSetExplicit and CellSetSingleType

!861 (b0dba9a1) adds this functionality to basic ArrayHandles.

Now when printing ArrayHandles that contain vec's of UInt8/Int8 you see
the integer representation instead of the ascii representation.