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 do. >> >> 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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
