On 10/9/11 10:16 AM, Gilles Sadowski wrote: > On Sun, Oct 09, 2011 at 12:56:30PM +0100, sebb wrote: >> On 30 September 2011 23:03, Gilles Sadowski >> <gil...@harfang.homelinux.org> wrote: >>>>> Referring to: >>>>> https://issues.apache.org/jira/browse/MATH-650 >>>>> https://issues.apache.org/jira/browse/MATH-675 >>>>> https://issues.apache.org/jira/browse/MATH-676 >>>>> >>>>> In the absence of additional comments I'm proposing to resolve those >>>>> issues. >>>>> Please let me know whether there are pending objections to my suggested >>>>> solutions. >>>> Regarding MATH-650 (FastMath) >>>> >>>> If the proposal is to use resources instead of static arrays, then I >>>> disagree, because resources are significantly slower than static >>>> arrays. >>>> >>>> I am opposed to storing the arrays in package protected classes, >>>> because that exposes the data unnecessarily. >>>> >>>> However, if you really cannot agree to the including the static arrays >>>> within the FastMath class itself, then I suggest using separate >>>> classes with private arrays and package-protected getters. >>> It has been shown that literal arrays are faster than resources in one >>> micro-benchmark instance: Namely, an application that consists of a single >>> function call. We still wait for a real use-case where the difference will >>> significantly matter. >> The original reason the JIRA was raised is probably solved by moving >> to on demand init. > I've been saying that same thing more than a few times, in various ways. > >> It's not clear if that alone is sufficient to deal with the OP's use case. > At one point, Alexis wrote (on JIRA): > "A response time with the magnitude of 100ms is really perfect !" > > Then I provided a test case, following Luc's indication of the typical > functions called in the original use case. > On my machine, the timing for all alternatives was below 100 ms.
100ms on a fast machine doing nothing else is not awe-inspiring. Holding a static class lock for that long is in fact at *bad thing*. People way smarter than me have come up with great ways to work around delays in app startup times. I prefer not to have to use those things, and, more importantly, not to force others using my code to use them. I favor the static arrays solution, IIUC what the timing tests have shown. Specifically, if static arrays can reduce class loading time by more than 50ms, I think we should use them. If there is some other workaround that allows the resource loading and does not increase loading time more than 50-100ms, I am OK with the resources approach as well. Phil > >>> Independently, I think that the right way to load this kind of data is >>> indeed via the "resources" functionality. If this is so, one should rather >>> ask whether the loading time can be improved. In fact, I wonder why loading >>> resources should be "so much" slower than arrays (18 ms vs 6 ms). >> I wonder too. If you can make it go as fast as the preset arrays, then >> I would be happy with that. > See my last comment on JIRA. > >>> Hence, if there is still no consensus on that issue, >> I think you are the only person who appears to be vetoing the local arrays. > Because, this is bad practice. In my opinion, the inconvenience is not worth > it because, in the first place, over-optimizing is bad (TM): There was no > _real_ use-case showing that initialization was still too slow after you > implemented IOD. At that point, we should have removed the unnecessary > over-optimization that was the literal arrays. > If we want to optimize, we should lokk for the places where it matters.[1] > I think of the matrix mulitplication issue, where the gain is additive, > potentially saving seconds, minutes, hours of computation time, whereas this > issue will at most gain a few dozen milliseconds. > >> I have yet to see a proper objection to leaving the arrays within the >> FastMath class. >> The code still generates the same results, and is proven faster in startup. >> What is wrong with that? > I think I've answered that in the above paragraphs. > [Nothing wrong with the speed-up, if it didn't come at the expense of mixing > code and data, increasing byte-code size, and other strange things that > probably happen because a class file should not be arbitrarily large.] > >>> you are welcome to >>> create the helper classes as you suggest (which, IIRC, is what I had also >>> suggested from the outset). >> This is slightly different from the original suggestion; IIRC that did >> not include using getters. > I put getters because you asked them. But, indeed, there is no difference > with direct accessing the arrays since the getters do not return a copy: it > is possible to modify the "original" array. > >>> That way, both alternatives will be on an equal footing for further testing. >> I don't follow that. > "resource" files are accessed from a helper class, and literal arrays are > also now accessed from a helper class. > When we want to suppress the arrays ;-), we just delete the class and 5 > lines in "FastMath" (instead of 6000+ lines). > > Regards, > Gilles > > [1] That's what I had proposed when suggesting that we establish a set of > benchmarks (real, not micro) using use-cases from the various users of > CM. > > --------------------------------------------------------------------- > 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
