| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
|
| |
innerStride(), outerStride(), and size()""
This reverts commit 5f0b4a4010af4cbf6161a0d1a03a747addc44a5d.
|
|
|
|
|
|
|
| |
innerStride(), outerStride(), and size()"
This reverts commit 6cbb3038ac48cb5fe17eba4dfbf26e3e798041f1 because it
breaks clang-10 builds on x86 and aarch64 when C++11 is enabled.
|
|
|
|
| |
outerStride(), and size()
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the current `dense_assignment_loop` implementations, if the
destination's inner or outer size is zero at compile time and if the kernel
involves a product, we currently get a compile error (#2080). This is
triggered by attempting to multiply a non-existent row by a column (or
vice-versa).
To address this, we add a specialization for zero-sized assignments
(`AllAtOnceTraversal`) which evaluates to a no-op. We also add a static
check to ensure the size is in-fact zero. This now seems to be the only
existing use of `AllAtOnceTraversal`.
Fixes #2080.
|
|
|
|
| |
accessors as STRONG_INLINE.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit aa110e681b8b2237757a652ba47da49e1fbd2cd6
optimised the multiplication of small dyanmically
sized matrices by restricting the packet size to a maximum of 4, increasing
the chances that SIMD instructions are used in the computation. However, it
introduced a mismatch between the packet size and the requestedAlignment. This
mismatch can lead to crashes when the destination is not aligned. This patch
fixes the issue by ensuring that the AssignmentTraits are correctly computed
when using a restricted packet size.
* * *
Bind LinearPacketType to MaxPacketSize
This commit applies any packet size limit specified when instantiating
copy_using_evaluator_traits to the LinearPacketType, providing that the
size of the destination is not known at compile time.
* * *
Add unit test for restricted packet assignment
A new unit test is added to check that multiplication of small dynamically
sized matrices works correctly when the packet size is restricted to 4 and
the destination is unaligned.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Packet16f, Packet8f and Packet8d types are too large to use with dynamically
sized matrices typically processed by the SliceVectorizedTraversal specialization of
the dense_assignment_loop. Using these types is likely to lead to little or no
vectorization. Significant slowdown in the multiplication of these small matrices can
be observed when building with AVX and AVX512 enabled.
This patch introduces a new dense_assignment_kernel that is used when
computing small products whose operands have dynamic dimensions. It ensures that the
PacketSize used is no larger than 4, thereby increasing the chance that vectorized
instructions will be used when computing the product.
I tested all 969 possible combinations of M, K, and N that are handled by the
dense_assignment_loop on x86 builds. Although a few combinations are slowed down
by this patch they are far outnumbered by the cases that are sped up, as the
following results demonstrate.
Disabling Packed8d on AVX512 builds:
Total Cases: 969
Better: 511
Worse: 85
Same: 373
Max Improvement: 169.00% (4 8 6)
Max Degradation: 36.50% (8 5 3)
Median Improvement: 35.46%
Median Degradation: 17.41%
Total FLOPs Improvement: 19.42%
Disabling Packet16f and Packed8f on AVX512 builds:
Total Cases: 969
Better: 658
Worse: 5
Same: 306
Max Improvement: 214.05% (8 6 5)
Max Degradation: 22.26% (16 2 1)
Median Improvement: 60.05%
Median Degradation: 13.32%
Total FLOPs Improvement: 59.58%
Disabling Packed8f on AVX builds:
Total Cases: 969
Better: 663
Worse: 96
Same: 210
Max Improvement: 155.29% (4 10 5)
Max Degradation: 35.12% (8 3 2)
Median Improvement: 34.28%
Median Degradation: 15.05%
Total FLOPs Improvement: 26.02%
|
| |
|
|
|
|
| |
Found using `codespell` and `grep` from downstream FreeCAD
|
| |
|
| |
|
|
|
|
|
| |
(grafted from 7962ac1a5855e8b7a60d5d90e61365b71f5501a5
)
|
| |
|
|
|
|
| |
operators (e.g., mat += mat.col(j))
|
|
|
|
|
|
| |
destination
by adding a dstDataPtr() member to the kernel. This fixes undefined behavior if dst is empty (nullptr).
|
|
|
|
|
|
| |
8193ffb3d38b56c9295f204dc57dc6bac74f58aa
)
|
|
|
|
| |
Generic EigenBase2EigenBase assignment was incomplete.
|
|
|
|
| |
resizing of the destination after the creation of the evaluator of the source expression.
|
| |
|
| |
|
|
|
|
|
| |
Additional CUDA necessary fixes in the Core (mostly usage of
EIGEN_USING_STD_MATH).
|
|
|
|
| |
allowed. For instance, this permits to vectorize 5x5 matrices (including product)
|
| |
|
| |
|
|
|
|
|
|
|
| |
"Scalar" to "SFINAE" only.
The previous "Scalar" semantic was obsolete since we allow for different scalar types in the source and destination expressions.
On can still specialize on scalar types through SFINAE and/or assignment functor.
|
|
|
|
| |
expression costing 0 like Constant)
|
|
|
|
|
|
|
|
|
|
| |
- Replace internal::scalar_product_traits<A,B> by Eigen::ScalarBinaryOpTraits<A,B,OP>
- Remove the "functor_is_product_like" helper (was pretty ugly)
- Currently, OP is not used, but it is available to the user for fine grained tuning
- Currently, only the following operators have been generalized: *,/,+,-,=,*=,/=,+=,-=
- TODO: generalize all other binray operators (comparisons,pow,etc.)
- TODO: handle "scalar op array" operators (currently only * is handled)
- TODO: move the handling of the "void" scalar type to ScalarBinaryOpTraits
|
| |
|
|
|
|
|
|
|
|
| |
conversions.
This fixes "conversion from pointer to same-sized integral type" warnings by ICC.
Ideally, we would use the std::[u]intptr_t types all the time, but since they are C99/C++11 only,
let's be safe.
|
|
|
|
|
| |
This concerns all architectures and all sizes.
This new behavior can be disabled by defining EIGEN_UNALIGNED_VECTORIZE=0
|
| |
|
| |
|
|
|
|
| |
of aligned ones for fixed size assignement.
|
|
|
|
| |
traversal modes.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
happier.
<g.gael@free.fr> HG: branch 'default' HG: changed Eigen/src/Core/ArrayBase.h HG: changed Eigen/src/Core/AssignEvaluator.h HG: changed
Eigen/src/Core/CoreEvaluators.h HG: changed Eigen/src/Core/CwiseUnaryOp.h HG: changed Eigen/src/Core/DenseBase.h HG: changed Eigen/src/Core/MatrixBase.h
|
|
|
|
| |
evaluator_traits::AssumeAliasing to evaluator_assume_aliasing.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
- Dynamic is now an invalid value
- introduce a HugeCost constant to be used for runtime-cost values or arbitrarily huge cost
- add sanity checks for cost values: must be >=0 and not too large
This change provides several benefits:
- it fixes shortcoming is some cost computation where the Dynamic case was not properly handled.
- it simplifies cost computation logic, and should avoid future similar shortcomings.
- it allows to distinguish between different level of dynamic/huge/infinite cost
- it should enable further simplifications in the computation of costs (save compilation time)
|
| |
|
| |
|
| |
|