commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <Luc.Maison...@free.fr>
Subject Re: [math] Iterative linear solvers (MATH-581) again
Date Fri, 08 Jul 2011 12:28:56 GMT
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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message