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