
Ublas : 
From: Gunter Winkler (guwi17_at_[hidden])
Date: 20050613 10:21:11
Am Montag, 13. Juni 2005 15:43 schrieb christopher diggins:
> 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
zero time for copy?
> benchmarking scalar_arithmetic(m1) 266 msec elapsed
> benchmarking matrix_arithmetic(m1, m2) 796 msec elapsed
> benchmarking multiply(m1, m2, m3) 3828 msec elapsed
what compiler did you use? The cvs head of ublas is _very_ slow with
gcc3.3 but fast as usual with gcc3.4. Can you post or mail the
benchmark program? I'd like to check the times.
> kmatrix is a matrix implementation where rows and columns are known
> at compiletime. ultiplication was done using axpy_prod.
Does that mean "everything constant"? Then the compiler could compute
the result and the execution time would be zero.
> 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).
I disagree. If you compare (peak) perfmance, you should use the best
code, not the shortest.
@all: Do you think, that it is possible to autodetect aliasing at
compile time via the container_reference class?
Should we add new overloads of += and co. to vector and matrix types:
self_type & operator += (const self_type& rhs) {
plus_assign(rhs);
return (*this);
}
mfg
Gunter