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] Major speed improvement to 1D FFT (MATH-732)
Date Tue, 07 Feb 2012 09:36:46 GMT
Le 07/02/2012 07:50, Sébastien Brisard a écrit :
> Hi,

Hello Sébastien,

> Kurt has recently proposed a patch for 1D-FFT which is much faster
> than our current impl, while still passing the tests (of course).
> Am I likely to hurt anyone's feelings if I replace the old impl by the new impl?

Please, go ahead, a faster implementation is always good, as long as it
can be maintained.

> 
> Also, I think that one of the reasons why our previous implementation
> was so slow is because it used internally Complex objects. Since these
> objects are immutable, we end up creating *a lot* of small objects.
> Apparently, the GC and JIT are not so good at that ;) (not being an
> expert, I'm not sure that the culprit is indeed the JIT or the GC...
> but surely someone is to be blamed).

This seems strange to me. Lots of improvements have been added to Java 5
and Java 6 about JVM optimization, and small objects are not really
costly now. I do trust JVM implementors here and really like using small
immutable objects.

> 
> I remember we recently had this conversation on the ML: one of Gilles
> or Luc argued that for very low-level algorithms, it didn't really
> matter if the parameters were passed as "very crude" objects, since it
> was most likely that the user would have to write an adapter to its
> own data format. So I would suggest we give up Complex[] altogether in
> the interface of FFT, and replace it with double[] arrays, with the
> following layout :
> data[2 * i] = real part
> data[2 * i + 1] = imaginary part.
> 
> What do you think?

I agree with this view (it may be me who expressed this). A double array
as an interface for our library seems good to me.

Luc

> Sébastien
> 
> 
> ---------------------------------------------------------------------
> 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