On Mon, Oct 10, 2011 at 02:03:26AM +0100, sebb wrote: > On 9 October 2011 22:44, 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. > > > > I don't understand whether you agree with my position i.e. that all > > alternatives having times below 100 ms can be considered sufficiently good. > > AIUI, the 100 ms was for loading time on the Android system, not a > desktop or laptop.
The numbers last posted by Alexis where of the order of 100 ms. AIUI this was already satisfactory to him, and with the current, there is an additional slight improvement. > > I recall that the sole worry clearly expressed by the original poster was > > the psychological effect of waiting "too long" for the result. [For an > > interactive application, waiting ~100 ms is not noticeable; it's far less > > than the time we routinely wait between a click on an icon, and the opening > > of the application window.] > > > >> Holding a static class lock for that long is in fact at *bad > >> thing*. > > > > I don't understand. What do you mean? Which class, which lock? Can you > > illustrate the items using the current issue? > > > >> 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. > > > > The point is that there are no delays anymore (solved by IOD). > > No, IOD only solves the delays for method calls that don't use the arrays. But *that* was the original issue; from the JIRA description: "[...] I've discovered that a simple FastMath.floor() takes about 4 to 5 secs [...]" > >> 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. > > > > [I guess that we are using the timings on my machine as a baseline.] > > There is no reduction of more than 50 ms by using literal arrays: at most 12 > > ms, with "FastMath" bloated with the literal arrays. > > > > A strange thing is that moving the arrays to their own class increased their > > loading time by ~6ms, while decreasing the resource loading time by about > > the same amount.[1] I mean that it is as if, somehow, the literal arrays[2] > > were incurring a penalty to other functionalities (the resource loading in > > this case) called from within "FastMath"! > > I don't think you can conclude that without further evidence. I state what I observed. I do not have an explanation for it but this is a fact. You are welcome to experiment, and I would be happy if you can extract the root of this seeming strangeness. > > > In conclusion, with the current code in trunk, the difference between the > > "literal arrays" and "resources" alternatives is less than ~0.5 millisecond. > > On your system. > > On an Android phone it will be a considerably bigger difference Numbers, please. Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
