commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <gil...@harfang.homelinux.org>
Subject Re: [Math] Issues 650, 675, 676
Date Sun, 09 Oct 2011 17:16:12 GMT
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.

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


Mime
View raw message