Prev: class
Next: Intel fortran (em64t) very low-accuracy results on x86_64
From: dpb on 27 Dec 2009 10:51
Luka Djigas wrote:
> Upon translating some matlab code, I came across this :
>
> M1x(end+1,:) = (-h/c) * (A3*V2+A4*V1); %N
>
> (don't mind the right side, it was just copy pasted)
....

Luka, you need to be careful here on the RHS, too, perhaps. At least be
aware of the possibility.

What are the sizes of An and Vn here? In Matlab the "*" is matrix
multiply so if they're scalars then the RHS is scalar but otoh if
they're a row vector and array, respectively, then the RHS is a row vector.

I'd tend to assume that given the LHS is written w/ the ":" instead of
the single subscript of a single element as that would be more typical
Matlab idiomatic style.

As noted in response to Richard's comment on the topic or reallocation
and copy during the operation it's as true in Matlab as in Fortran (or,
I suspect, any other language w/ similar features) so if you can
possible determine the size of the final array a priori, I'd recommend
preallocating and then filling rather than appending/growing...

hth...

-duane

--

From: Luka Djigas on 29 Dec 2009 08:58
On Sun, 27 Dec 2009 09:51:55 -0600, dpb <none(a)non.net> wrote:

>Luka, you need to be careful here on the RHS, too, perhaps. At least be
>aware of the possibility.
>
>What are the sizes of An and Vn here? In Matlab the "*" is matrix
>multiply so if they're scalars then the RHS is scalar but otoh if
>they're a row vector and array, respectively, then the RHS is a row vector.
>
>I'd tend to assume that given the LHS is written w/ the ":" instead of
>the single subscript of a single element as that would be more typical
>Matlab idiomatic style.
>
>As noted in response to Richard's comment on the topic or reallocation
>and copy during the operation it's as true in Matlab as in Fortran (or,
>I suspect, any other language w/ similar features) so if you can
>possible determine the size of the final array a priori, I'd recommend
>preallocating and then filling rather than appending/growing...
>
>hth...
>
>-duane

duane,
thanks for answering.

These last few days I've been reading all the replies, and
experimented with some of the given samples. Although my case in this
example is always a simple one (the right side being a scalar ... An,
Vn etc. being just numeric coefficients) I've come to a conclusion
that I will probably reconstruct the loops in an "usual way" - with
predetermining the number of iterations, the sizes of arrays and
allocating them ...

To this also contributed strong points that yourself and Richard Maine
mentioned, as well as the fact, that one day, when I look at this
again, if I continue on this route, I'll probably be banging my head
thinking "what did you do here?", given how much it deviates from my
usual style.. This is expecially true for James Van Buskirk's example,
whose skills in combining intrinsics to get the desired result almost
always leave me completely stunned! :-) In a positive way, but stunned
nevertheless :-)

Matlab's syntax is not necessary bad, you can do some "quick and
weird" stuff in a hurry, but it leaves the question of what's the
point of it if you'll have to translate it to something else (for
matters of speed like in this case - btw, in case I haven't mentioned,
I'm rewriting this program since it just runs too slow for the number
of iterations it has to make), in which case you'll lose most of the
time gained.

In any case, another thanks to all that helped !

Luka
From: dpb on 29 Dec 2009 10:04
Luka Djigas wrote:
....
> ... expecially true for James Van Buskirk's example,
> whose skills in combining intrinsics to get the desired result almost
> always leave me completely stunned! :-) In a positive way, but stunned
> nevertheless :-)

Amen, brother... :)

> Matlab's syntax is not necessary bad, you can do some "quick and
> weird" stuff in a hurry, but it leaves the question of what's the
> point of it if you'll have to translate it to something else (for
> matters of speed like in this case - btw, in case I haven't mentioned,
> I'm rewriting this program since it just runs too slow for the number
> of iterations it has to make), in which case you'll lose most of the
> time gained.
....

OK, I didn't recognize it was your own ML code you were transporting and
thought you might be overlooking that the RHS was a vector in somebody
else's code.

There is, of course, the option of turning your ML function to a
MEX-file and seeing if it has "good enough" performance in the
bottlenecks. Also, of course, look at the profiler and see where the
time is being spent--perhaps there is some vectorization or other
optimization in ML to fix it more simply. Unless, of course, there is
simply a need/desire to move to compiled code anyway.

Certainly if you can figure out the loop iteration and preallocate in
Fortran you can do so in Matlab and that step should help. (Might even
be worth a quickie test of replacing the LHS ":" w/ "2"; I'm not sure
what the jit compilation in newer versions of ML than I have will do w/
it, but in my release : still translates to a function call every pass
it appears.)

--
From: glen herrmannsfeldt on 29 Dec 2009 13:46
Luka Djigas <ldigas@___gmail___.com> wrote:
(snip)

> These last few days I've been reading all the replies, and
> experimented with some of the given samples. Although my case in this
> example is always a simple one (the right side being a scalar ... An,
> Vn etc. being just numeric coefficients) I've come to a conclusion
> that I will probably reconstruct the loops in an "usual way" - with
> predetermining the number of iterations, the sizes of arrays and
> allocating them ...
(snip)

If you know the final size in advance, that is usually the best way.
That is true in Fortran, and also in interpreted languages like
Matlab, R, and Mathematica. While the interpreted languages make
it easy to build an array one element at a time, or build a matrix
one row or column at a time, the result can be slow as the resulting
array gets large.

> Matlab's syntax is not necessary bad, you can do some "quick and
> weird" stuff in a hurry, but it leaves the question of what's the
> point of it if you'll have to translate it to something else (for
> matters of speed like in this case - btw, in case I haven't mentioned,
> I'm rewriting this program since it just runs too slow for the number
> of iterations it has to make), in which case you'll lose most of the
> time gained.

In many cases the built-in features of languages like matlab, R,
and Mathematica simplify the initial programming and proof of
concept. Then later go back and make it fast enough.

-- glen
First  |  Prev  | 
Pages: 1 2
Prev: class
Next: Intel fortran (em64t) very low-accuracy results on x86_64