There is a test that tries to determine that the Invoke methods in
FunctionInterface do not add an unreasonable overhead. However, this
test is unreliable. Also, the most critical performance hit would be in
invoking a worklet operation, but that is now done elsewhere anyway.
The unit test for StorageBasic tested the StealArray feature and then
used the delete[] operator on the stolen array to deallocate it. For
many standard libraries the default implementation for delete[] is
the same as (or at least compatible with) std::allocator, but for
the PGI compiler they were not compatible and this resulted in a
run-time error. This change fixes the problem with the test by using
the same allocator as the StorageBasic test.
ICC can be pretty thorough about finding unused elements. In this case
it was picking up an unused method in instances of a templated class
in an anonymous namespace. It was a method that should be there due to
the nature of the class, but it happened to not be used (which was OK,
too). To get around the problem, I just added some use of that method
in another method.
It's easy to put accidently put something that is not a valid tag in a
ControlSignature or ExecutionSignature. Previously, when you did that
you got a weird error at the end of a very long template instantiation
chain that made it difficult to find the offending worklet.
This adds some type checks when the dispatcher is instantated to check
the signatures. It doesn't point directly to the signature or its
parameter, but it is much closer.
MSVC is picky about type conversions. To get it to shut up, explicitly
cast the worklet return value to the fetch value in the
WorkletInvokeFunctor. The good is that it will help with needing
explicit conversions on these return values. But that is also bad in
that it might make some unexpected conversions possible.
Instead of just checking that a dispatcher's Invoke input is an
ArrayHandle, also check that the ValueType of the ArrayHandle is
compatible with the types of the worklet operator. This is done by
adding a template argument to the ControlSignature tags that is a type
list tag that gets passed to the type check.
One fix is a simple (pointless) compiler warning about precision. The
other fix is an error in one of the test codes that did not clear out
the message string in an error message buffer like it was supposed to.
Also reduced the maximum list size to 15 (which is the current longest
single list we have). Trying to reduce the size of the generated code a
bit, which is getting a little long.
Previously, this script would create a file the same name as the desired
output, and then move it to a file with .save appended to it if the
check failed. This is problematic with parallel builds because there is
no dependency set up between the actual header file and the one being
created. Thus, it is possible for some compiles to pick up the created
file before it is moved or deleted.
Instead, just create the file with .save appended to it so that no
compile can every accidently pick it up.
This is a simple version of a dispatcher, but an important one.
Note that there is an issue brought up with UnitTestWorkletMapField in
that there needs to be better ways to specify worklet argument types.
These changes support the implementation of DispatcherBase. This class
provides the basic functionality for calling an Invoke method in the
control environment, transferring data to the execution environment,
scheduling threads in the execution environment, pulling data for each
calling of the worklet method, and actually calling the worklet.
The zip capability allows you to parameter-wise combine two
FunctionInterface objects. The result is another FunctionInterface with
each parameter a Pair containing the respective values of the two
inputs.
Being able to zip allows you to do transforms and invokes on data that
is divided among multiple function interface objects.
The Fetch class is responsible for moving data in and out of some
collection in the execution environment. The Fetch class is templated
with a pair of tags (the type of fetch and the aspect) that control the
mechanism used for the fetch.
The Transport class is responsible for moving data from the control
environment to the execution environment. (Actually, it might be more
accurate to say it gets the execution environment associated with a
given control object.) The Transport class is templated with a tag that
controls the mechanism used for the transport.
Lots of tests have to move values in and out of arrays and check them
against expected values. It is also often the case that these tests are
run on lots of different types. There is some repeated code for
generating known values for particular indices. This change unifies some
of that. This can probably also encourage making more generic tests.
The previous commits had TypeListTagAll containing a subset of Vec
types. This commit adds all possible vectors with 2 to 4 components
containing one of the basic C types.
Providing these types tends to "lock in" the precision of the algorithms
used in VTK-m. Since we are using templating anyway, our templates
should be generic enough to handle difference precision in the data.
Usually the appropriate type can be determined by the data provided. In
the case where there is no hint on the precision of data to use (for
example, in the code that provides coordinates for uniform data), there
is a vtkm::FloatDefault.
Before we assumed that we would only use the basic types specified by
the widths of vtkm::Scalar and vtkm::Id. We want to expand this to make
sure the code works on whatever data precision we need.
Since we want our code to generally handle data of different precision
(for example either float or double) expand the types in our list types
to include multiple precision.
Previously we just hand coded base lists up to 4 entries, which was fine
for what we were using it for. However, now that we want to support base
types of different sizes, we are going to need much longer lists.
There are multiple reasons for this name change:
* The name Tuple conflicts with the boost::Tuple class, which as a
different interface and feature set. This gets confusing, especially
since VTK-m uses boost quite a bit.
* The use of this class is usually (although not always) as a
mathematical vector.
* The vtkm::Scalar and vtkm::Vector* classes are going to go away soon
to better support multiple base data type widths. Having this
abbriviated name will hopefully make the code a bit nicer when these
types have to be explicitly specified.
Also modified the implementation a bit to consolidate some of the code.
In preparation for supporting base types with more widths, add typedefs
for the base types with explicit widths (number of bits).
Also added a IdComponent type that should be used for indices for
components into tuples and vectors. There now should be no reason to use
"int" inside of VTK-m code (especially for indexing). This change cleans
up many of the int types that were used throughout.
The previous behavior of the pyexpander check (in
VTKmCheckPyexpander.cmake) was to generate the file in the binary
directory and then remove it from there iff the check failed. This
caused two problems. The first is that if the check failed then the file
was deleted and there was no file to copy to the source as the
instructions suggested. The second is that if the check succeeded the
build would then use the files in the build directory rather than the
source directory, and if the programmer accidently modified the binary
files (because, for example, if a build error occured there), the
configure system would not catch that.
This change in behavior was that if the check failed, the file is
renamed to have a .save extension so that the file remains and can be
easily copied back to the source directory if that is appropriate. If
the check succeeds, the generated file is removed and a file with the
extension .check is touched. That .check file is used as a make target
to signal that the test has been performed.
We have a test for FunctionInterface to make sure that calling a function
indirectly through that is about as fast as directly. On MSVC we sometimes
observe that this timing fails in debug mode. This is probably the compiler
adding some code to each function invocation. That won't happen in production
compiles, so we don't care about it too much. Make an exception in this case.
When compiling with 32-bit Ids for a 64 bit machine (which is not
uncommon), it is possible that the distance between two iterators
is larger than the maximum value that can be stored in vtkm::Id.
If two such iterators were passed to ArrayPortalFromIterators, that
would cause problems.
This change checks for that condition and throws an out of memory
exception if it occurs. That would be a pretty darn big array and
is more likely to be the cause of an error somewhere else in the
code, but either way the check and error is good. This change also
fixes a warning we have been getting with MSVC.
The SystemInformation test always passes. It prints out the contents of
various configuration parameters. The intention is to capture this
information in dashboard reports. That way if a change causes a
dashboard failure and a developer does not have access to the dashboard,
she can look at the output of this test to see the configuration of the
build and that machine.
