commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sébastien Brisard <>
Subject Re: [math] Major speed improvement to 1D FFT (MATH-732)
Date Tue, 07 Feb 2012 09:47:06 GMT
Hello Luc,
> 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.

Actually, the more I work on commons-math, the more I like small,
immutable objects! What I wrote was just a "feeling", though. I
haven't done any proper monitoring. I plan to do that though, as this
could provide us with some guidelines on what we should and should not

>> 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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message