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 Mon, 10 Oct 2011 01:59:51 GMT
On 10/9/11 2:44 PM, Gilles Sadowski 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.
> 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.]
Even 50ms holding a class lock is bad if it can be avoided.  In web
applications, or anything multi-threaded, you have to worry about
concurrency. Holding an exclusive lock on a resource that lots of
threads need for 100ms can cause threads to pile up with the end
result being way longer than 100ms for unlucky threads and, yes,
causing noticeable problems for the application.   As has been
pointed out, there are workarounds to allow slow-starting web apps
not to get overwhelmed as they park threads waiting on locks; but
needlessly creating / contributing to this is not a good thing for a
library to do.  I can see we are getting nowhere in this discussion,
so I am not going to comment further.

Phil
>
>> 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).
>
>> 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"!
>
> In conclusion, with the current code in trunk, the difference between the
> "literal arrays" and "resources" alternatives is less than ~0.5 millisecond.
>
>
> Gilles
>
> [1] I also gained some 1-2 ms using "nio" and reducing the number of I/O
>     method calls.
> [2] Even when they were not used, e.g. when "LOAD_RESOURCES" was set to
>     "true" in order to use the resource loading alternative.
>
> ---------------------------------------------------------------------
> 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