commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [Math] Issues 650, 675, 676
Date Sun, 09 Oct 2011 17:32:52 GMT
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
>> <gilles@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message