|
|
Ublas : |
From: christopher diggins (cdiggins_at_[hidden])
Date: 2005-06-13 11:11:35
----- Original Message -----
From: "Gunter Winkler" <guwi17_at_[hidden]>
To: "ublas mailing list" <ublas_at_[hidden]>
Sent: Monday, June 13, 2005 11:21 AM
Subject: Re: [ublas] Aliasing for += and -=
> Am Montag, 13. Juni 2005 15:43 schrieb christopher diggins:
>
>> 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?
It means it was below the timer resolution of 31 msec.
>> 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?
Visual C++ 7.1.
> The cvs head of ublas is _very_ slow with
> gcc-3.3 but fast as usual with gcc-3.4. Can you post or mail the
> benchmark program? I'd like to check the times.
Attached.
>> k-matrix is a matrix implementation where rows and columns are known
>> at compile-time. 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.
Not everything was constant, but it is easy to prevent precomputation.
AFAICT Visual C++ 7.1 didn't bother to precompute anything otherwise we
would have seen much faster times.
>> 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 "out-of-the-box" performance for naive
>> users (the most common kind).
>
> I disagree. If you compare (peak) perfmance, you should use the best
> code, not the shortest.
It's not just about the "best" code. You can not know whether or not
something is aliased in the following context:
void test(const matrix1& m1, const matrix2& m2) { m1 += m2; }
Therefore assuming unaliased is not comparing "best code", it is being
unrealistic.
AFAICT this just goes to show aliasing doesn't apparently buy you anything
but complexity and poor performance. The fact that you are insisting that
the "best" code requires unaliasing, simply reinforcing my belief that the
design of ublas is flawed.
> @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);
> }
-Christopher Diggins
*****************************************************************************
** **
** WARNING: This email contains an attachment of a very suspicious type. **
** You are urged NOT to open this attachment unless you are absolutely **
** sure it is legitmate. Opening this attachment may cause irreparable **
** damage to your computer and your files. If you have any questions **
** about the validity of this message, PLEASE SEEK HELP BEFORE OPENING IT. **
** **
** This warning was added by the IU Computer Science Dept. mail scanner. **
*****************************************************************************