Le 08/07/2011 12:28, Sébastien Brisard a écrit :
I would go to the natural type we get when building the exception. If we may
build the exception from both types, then I would select RealVector. We do
not intend to perform large processing on elements, but we want to display
them and I think we do have formatting for vectors.
best regards,
Luc
I actually was not thinking of speed for --as you mentioned--
exceptional cases, but rather to ease of debugging. If several vectors
could have caused the exception, it's easier to identify the right one
if we have a reference rather than a deep copy (overwise all the
components must be tested).
Speaking of speed, I do have a performance issue, which I stated this
morning in MATH-581, but maybe it would be better to ask the question
here. Suppose I want to implement a method operate, which computes the
matrix-vector product. I read a long time ago that it was better to
have a method signature like
void operate(double[] x, double[] y)
where x is the vector to be multiplied, and y the result. Such a
choice avoids costly (so they said) memory allocations caused by a
signature like
double[] operate(double[] x)
I also used to do that a long time ago, but since about 3 or 5 years, I
changed my mind.
The thing is the first option is not frequently met in Commons-Math.
It still appears for example in the ODE interfaces. State vector y and
its derivatives yDot are allocated once and reused, but this is more an
historic special case than mainstream.
I've started to work with this option for iterative linear solvers,
but I do not like the inconsistent feel it has with the rest of CM.
Also, very crude monitoring on rather large linear systems (800,000 x
800,000) shows that memory allocations are not even measurable... As
Allocation is even less measurable for large data chunks than lots of
small ones. So what you observe is expected.
I said, I read that a long time ago, and someone already mentioned on
this forum that GC is getting pretty good those days... So is it
really worth worrying about memory allocation?
It should be considered only if problems are really observed, not
beforehand.
What is more important, especially for large data sets, is cache
behaviour, which may be a bottleneck. In fact, about 20 years ago,
algorithms were compared according to number of operations, then 10
years ago dynamic allocation became a problem, now that processors are
fast and memory is huge, cache is the problem.
I do not intend to do a thorough benchmarking, but I'd rather like to
get rid of operate(double[], double[]) and keep only the most natural
one.
I agree with you. Maintenance of the code, readability, testing are very
important too. We have a tendency (at least me) to set up too complex
algorithms for too small improvements, we must make a real effort to
build more straightforward and more robust code.
best regards,
Luc
Any thoughts on this ?
Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
