@@ -160,7 +160,8 @@ slice(0,0,2));
@@ -160,7 +160,8 @@ slice(0,0,2));
If you know for sure that the left hand expression and the right hand expression have no common storage, then assignment has no aliasing. A more efficient assignment can be specified diff --git a/doc/overview.htm b/doc/overview.htm index 93157469..fb01a0df 100644 --- a/doc/overview.htm +++ b/doc/overview.htm @@ -211,20 +211,25 @@ languages. The principle of this approach is to evaluate a complex expression element wise and to assign it directly to the target.
Two interesting and dangerous facts result.
+First one may get serious side effects using element wise evaluation on vectors or matrices. Consider the matrix vector product x = A x. Evaluation of A1x and assignment to x1 changes the right hand side, so that the evaluation of A2x -returns a wrong result. Our solution for this problem is to +returns a wrong result. In this case there are aliases of the elements +xn on both the left and right hand side of the assignment.
+Our solution for this problem is to
evaluate the right hand side of an assignment into a temporary and
then to assign this temporary to the left hand side. To allow
further optimizations, we provide a corresponding member function
-for every assignment operator. By using this member function a
-programmer can confirm, that the left and right hand sides of an
+for every assignment operator and also a
+ noalias syntax.
+By using this syntax a programmer can confirm, that the left and right hand sides of an
assignment are independent, so that element wise evaluation and
direct assignment to the target is safe.
Next one can get worse computational complexity under certain cirumstances. Consider the chained matrix vector product A (B x). Conventional evaluation of A (B x) is quadratic. @@ -590,23 +595,8 @@ FORTAN compatible data.
For compatibility reasons we provide array like indexing for -vectors and matrices, although this could be expensive for matrices -due to the needed temporary proxy objects.
-To support the most widely used C++ compilers our design and -implementation do not depend on partial template specialization -essentially.
-The library presumes standard compliant allocation through
-operator new and operator delete. So
-programs which are intended to run under MSVC 6.0 should set a
-correct new handler throwing a std::bad_alloc
-exception via _set_new_handler to detect out of memory
-conditions.
To get the most performance out of the box with MSVC 6.0, you
-should change the preprocessor definition of
-BOOST_UBLAS_INLINE to __forceinline in
-the header file config.hpp. But we suspect this optimization to be
-fragile.
For compatibility reasons we provide array like indexing for vectors and matrices. For some types (hermitian, sparse etc) this can be expensive for matrices due to the needed temporary proxy objects.
+uBLAS uses STL compatible allocators for the allocation of the storage required for it's containers.
The following tables contain results of one of our benchmarks. This benchmark compares a native C implementation ('C array') and @@ -624,10 +614,6 @@ respectively.
| Operation | -Implementation | -Elapsed [s] | -MFLOP/s | Comment |
|---|---|---|---|---|