
Ublas : 
From: christopher diggins (cdiggins_at_[hidden])
Date: 20050613 08:43:44
 Original Message 
From: "Gunter Winkler" <guwi17_at_[hidden]>
To: "ublas mailing list" <ublas_at_[hidden]>
Sent: Sunday, June 12, 2005 2:51 PM
Subject: Re: [ublas] Aliasing for += and =
> Am Sonntag, 12. Juni 2005 18:41 schrieb christopher diggins:
>> I mentioned this before, and I'll say it again: A straightforward
>> implementation of += and = is not affected by aliasing. This is
>> trivial to fix. I find it unacceptable that the library can not do
>> such a simple task correctly.
>
> Not for all types: For example
>
> r1 = project( x, range(0,4) )
> r2 = project( x, range(2,6) )
>
> r1 += r2 and r2 += r1 have both aliasing and should be evaluated in
> different directions.
So then I stand corrected, with the current design it is not trivial. Does
using aliasing as a default provide enough benefit to justify the
performance hit everywhere else? I find the highly improbable. What I have
checked: matrix copies, element access, addition, subtraction,
multiplication, scalar multipliciation. These are what I consider to be the
most important and common operations for any matrix/vector library.
Here are my benchmark results:
boost ublas performance, rows = 3, cols = 3, iters = 100000
benchmarking element_access(m1) 406 msec elapsed
benchmarking matrix_copy(m1, m2) 31 msec elapsed
benchmarking scalar_arithmetic(m1) 266 msec elapsed
benchmarking matrix_arithmetic(m1, m2) 2407 msec elapsed
benchmarking multiply(m1, m2, m3) 234 msec elapsed
boost ublas performance, rows = 100, cols = 100, iters = 100
benchmarking element_access(m1) 390 msec elapsed
benchmarking matrix_copy(m1, m2) 0 msec elapsed
benchmarking scalar_arithmetic(m1) 266 msec elapsed
benchmarking matrix_arithmetic(m1, m2) 796 msec elapsed
benchmarking multiply(m1, m2, m3) 3828 msec elapsed
dynamic matrix performance, rows = 3, cols = 3, iters = 100000
benchmarking matrix_element_access(m1) 109 msec elapsed
benchmarking matrix_copy(m1, m2) 47 msec elapsed
benchmarking scalar_arithmetic(m1) 109 msec elapsed
benchmarking matrix_arithmetic(m1, m2) 93 msec elapsed
benchmarking matrix_multiply(m1, m2, m3) 63 msec elapsed
dynamic matrix performance, rows = 100, cols = 100, iters = 100
benchmarking matrix_element_access(m1) 94 msec elapsed
benchmarking matrix_copy(m1, m2) 31 msec elapsed
benchmarking scalar_arithmetic(m1) 94 msec elapsed
benchmarking matrix_arithmetic(m1, m2) 78 msec elapsed
benchmarking matrix_multiply(m1, m2, m3) 2047 msec elapsed
kmatrix performance, rows = 3, cols = 3, iters = 100000
benchmarking kmatrix_element_access(m1) 63 msec elapsed
benchmarking matrix_copy(m1, m2) 31 msec elapsed
benchmarking scalar_arithmetic(m1) 63 msec elapsed
benchmarking matrix_arithmetic(m1, m2) 46 msec elapsed
benchmarking kmatrix_multiply(m1, m2, m3) 47 msec elapsed
kmatrix performance, rows = 100, cols = 100, iters = 100
benchmarking matrix_element_access(m1) 78 msec elapsed
benchmarking matrix_copy(m1, m2) 0 msec elapsed
benchmarking scalar_arithmetic(m1) 78 msec elapsed
benchmarking matrix_arithmetic(m1, m2) 47 msec elapsed
benchmarking matrix_multiply(m1, m2, m3) 922 msec elapsed
kmatrix is a matrix implementation where rows and columns are known at
compiletime. ultiplication was done using axpy_prod. Everything else was
done naively, just as we would expect a libary user to:
i.e.:
matrix<int> m;
m *= 2;
m += m;
m[i][j] = 0;
I can heare the chorus of screams, but you didn't using "noalias". In real
code whether something is aliased or not is not trivially known. So it is
not fair to use "noalias" in a straightforward comparion. Furthermore I am
comparing "outofthebox" performance for naive users (the most common
kind).
Christopher Diggins
http://www.cdiggins.com