You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sirona.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2013/11/04 16:49:32 UTC
[math] Multithreaded performances
Hi,
ATM sirona (a java monitoring library in incubator) relies a lot on
Summary stats object from [math3] but it needed a lock to ensure
consistency. I know there is a synchronized version but this one
scales less then the locked one.
My question is quite simple then: will [math] add an implementation
with thread safety guarantee and good performances? I think for
instance to the LongAdder of Doug Lea which could be used as a good
base.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
Re: [math] Multithreaded performances
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Am 05.11.2013, 00:44 Uhr, schrieb Ted Dunning <te...@gmail.com>:
> The thread leak problem can be more serious.
What Thread Leak problem? TLS is cited to have that leak since ages, I am
not sure I ever have seen one triggered. So, who has details on that? Even
the JCL uses (more) thread local objects. For example in JDK8 the
BigInteger has a thread local SecureRandom instance.
One has to be carefull in regards to keeping classloaders alive, but that
can be worked around with an expire, weak references or simply by only
storing system classes (for example long[]!)
Greetings
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Multithreaded performances
Posted by Thomas Neidhart <th...@gmail.com>.
On 11/21/2013 11:14 AM, Romain Manni-Bucau wrote:
> Hi
>
> first maybe the thread should move over sirona list (I wouldn't bother
> commons ;)): http://sirona.incubator.apache.org/mail-lists.html
>
> about hot topics I think we have:
> 1) Gui enhancement (a jira is about using another js library to draw
> graphes and get an analysis/correlation view, another topic is the GUI
> configuration: how to make dashboard etc...)
> 2) Storage backends (we support mainly cassandra and in memory ATM but
> a rotating JDBC impl could be great too)
> 3) Alerting is not yet done and needs to be in final versions
> 4) Agent/Plugins enhancement (we have a few today)
> 5) Surely a better configuration
> 6) Counter implementation with less locks (even if thanks to the stat
> impl we use we reduced the lock duration we still rely too much on
> lock IMO and I'm sure we can do better).
> 7) etc.. ;)
>
>
> It is a new project so all help is welcomed!
Hi Romain,
thanks for the pointers, I will take a closer look, some of them would
really be interesting to work on.
Thanks,
Thomas
>
> PS: we have an IRC channel on freenode: #apache-sirona
>
>
>
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2013/11/21 Thomas Neidhart <th...@gmail.com>:
>> I did take a look at sirona, and it looks really nice.
>> Whats the best way to contribute to it? Any open issues you would like to
>> work somebody on?
>>
>> Thomas
>>
>>
>> On Wed, Nov 20, 2013 at 5:38 PM, Romain Manni-Bucau
>> <rm...@gmail.com>wrote:
>>
>>> yep but this is not enough, almost each "component" is doing n++. This
>>> is fast but since done under a lock if it can be removed it should.
>>> Romain Manni-Bucau
>>> Twitter: @rmannibucau
>>> Blog: http://rmannibucau.wordpress.com/
>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>> Github: https://github.com/rmannibucau
>>>
>>>
>>>
>>> 2013/11/20 Phil Steitz <ph...@gmail.com>:
>>>> On 11/20/13, 7:26 AM, Romain Manni-Bucau wrote:
>>>>> next version (rewrite/fork):
>>>>>
>>> https://svn.apache.org/repos/asf/incubator/sirona/trunk/core/src/main/java/org/apache/sirona/counters/OptimizedStatistics.java
>>>>>
>>>>> was easier to centralize everything in a single class
>>>>
>>>> That is exactly what I meant about the moment statistics. They can
>>>> share state. The problem is this approach eliminates the
>>>> pluggability and also cuts out the other stats. We can probably
>>>> have it both ways by allowing you to turn off stuff you don't want
>>>> and just having the moment stats share state.
>>>>
>>>> Phil
>>>>> Romain Manni-Bucau
>>>>> Twitter: @rmannibucau
>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>> Github: https://github.com/rmannibucau
>>>>>
>>>>>
>>>>>
>>>>> 2013/11/20 Phil Steitz <ph...@gmail.com>:
>>>>>> On 11/20/13, 12:43 AM, Romain Manni-Bucau wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>> A quick mail to give some feedbacks of my tests.
>>>>>>>
>>>>>>> I started to hack a bit to get rid of not used stats by sirona,
>>>>>>> typically I do ATM:
>>>>>>>
>>>>>>> setSumsqImpl(NoopStat.INSTANCE);
>>>>>>> setSumLogImpl(NoopStat.INSTANCE);
>>>>>>> setGeoMeanImpl(NoopStat.INSTANCE);
>>>>>>>
>>>>>>> (NoopStat is a mock of StorelessUnivariateStatistic doijg nothing)
>>>>>>>
>>>>>>> Another point which could be improoved is the duplication of info
>>>>>>> accross sub StorelessUnivariateStatistic (typically n computed several
>>>>>>> times for instance).
>>>>>> Good point. Its kind of funny that simplest way to solve the
>>>>>> problem you mention at the end is to remove the flexibility that you
>>>>>> use in the beginning - i.e., to no longer use separate stats
>>>>>> instances to compute the bundled statistics. The setup is the way
>>>>>> it is precisely so that you can plug in alternative impls. I had
>>>>>> never thought of no-op-ing instances to suppress things, but it does
>>>>>> work. Having stats share state data is a little tricky but in
>>>>>> theory possible. The moment stats at least are set up to support
>>>>>> this. Patches are welcome. If you don't mind opening a JIRA to
>>>>>> suggest eliminating repeated computations that would be great.
>>>>>>
>>>>>> Phil
>>>>>>> Romain Manni-Bucau
>>>>>>> Twitter: @rmannibucau
>>>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>>>> Github: https://github.com/rmannibucau
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2013/11/6 Phil Steitz <ph...@gmail.com>:
>>>>>>>> On 11/6/13 9:05 AM, Romain Manni-Bucau wrote:
>>>>>>>>> Great!
>>>>>>>>>
>>>>>>>>> Btw not sure for sirona we oculd use it. One constraint on
>>> sirona-core
>>>>>>>>> is to stay self contained. We already shade math3 so shading pool2
>>> too
>>>>>>>>> would start to create a big jar for this need. I'll try to bench
>>>>>>>>> deeper next week too.
>>>>>>>> OK - and any ideas you have about how to implement something
>>>>>>>> lightweight inside [math] much appreciated.
>>>>>>>>
>>>>>>>> Phil
>>>>>>>>> Romain Manni-Bucau
>>>>>>>>> Twitter: @rmannibucau
>>>>>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>>>>>> Github: https://github.com/rmannibucau
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2013/11/6 Phil Steitz <ph...@gmail.com>:
>>>>>>>>>> On 11/6/13 8:47 AM, Romain Manni-Bucau wrote:
>>>>>>>>>>> well pool are based on locks so I'm not sure (it would need deep
>>>>>>>>>>> benchs on a real app) it does worth it
>>>>>>>>>> Commons pool2 uses pretty lightweight locking and using a pool of
>>>>>>>>>> instances achieves the basic objective of reducing contention for
>>>>>>>>>> the single sync lock on one SummaryStatistics object. I bet it
>>>>>>>>>> would improve throughput over the single-instance approach if
>>>>>>>>>> maxActive, maxIdle were tuned. If I get some time to play with
>>>>>>>>>> this, I will report back with some benchmarks.
>>>>>>>>>>
>>>>>>>>>> Phil
>>>>>>>>>>> Romain Manni-Bucau
>>>>>>>>>>> Twitter: @rmannibucau
>>>>>>>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>>>>>>>> Github: https://github.com/rmannibucau
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2013/11/6 Phil Steitz <ph...@gmail.com>:
>>>>>>>>>>>> On 11/5/13 11:26 PM, Romain Manni-Bucau wrote:
>>>>>>>>>>>>> Hehe, right.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I looked a bit more today and LongAdder is only a part of the
>>>>>>>>>>>>> solution. The stat computation still needs to lock to get acces
>>> to
>>>>>>>>>>>>> previous values (N -> N+1). Basically the gain wouldn't be as
>>>>>>>>>>>>> important as I thought :(.
>>>>>>>>>>>> Right, but I think your original idea of maintaining a pool of
>>>>>>>>>>>> instances (fewer that one per thread) to be periodically
>>> aggregated
>>>>>>>>>>>> is a good one. See below.
>>>>>>>>>>>>> As I said before we'll wait a bit to gather feedbacks, if it
>>> blocks
>>>>>>>>>>>>> I'll come back trying to find + propose a solution.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks in all cases for your answers!
>>>>>>>>>>>> A workaround that I have started playing with (partly for other
>>>>>>>>>>>> benchmarking reasons) might be to actually use a pool for the
>>> stats
>>>>>>>>>>>> objects that the monitoring threads use. Using a pool would
>>> allow
>>>>>>>>>>>> you to monitor and tune the parameters. We now have (well, once
>>> the
>>>>>>>>>>>> VOTE in progress completes :) a decently performing pool
>>>>>>>>>>>> implementation. The tricky bit is locking the instances during
>>>>>>>>>>>> aggregation. One way to handle this would be to have the
>>> factory's
>>>>>>>>>>>> passivate method and the aggregation thread contend for locks on
>>> the
>>>>>>>>>>>> pooled stats instances. The only contention would be when
>>>>>>>>>>>> aggregation is copying individual instances and contention would
>>> be
>>>>>>>>>>>> with at most one client thread (waiting to proceed in passivate).
>>>>>>>>>>>>
>>>>>>>>>>>> Phil
>>>>>>>>>>>>> Romain Manni-Bucau
>>>>>>>>>>>>> Twitter: @rmannibucau
>>>>>>>>>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>>>>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>>>>>>>>>> Github: https://github.com/rmannibucau
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2013/11/5 Phil Steitz <ph...@gmail.com>:
>>>>>>>>>>>>>> On 11/5/13 9:57 AM, Romain Manni-Bucau wrote:
>>>>>>>>>>>>>>> @Phil: hmm can be but the framework would create its own
>>> overhead which
>>>>>>>>>>>>>>> would be avoided with a dedicated solution, no? Well thought
>>> gain was great
>>>>>>>>>>>>>>> for small investment but ok to postpone it
>>>>>>>>>>>>>> As I said, patches welcome. Go for it. My point about the
>>>>>>>>>>>>>> framework was that when you actually get this implemented
>>> inside,
>>>>>>>>>>>>>> e.g. SummaryStatistics, you will have built a mini-framework.
>>>>>>>>>>>>>> Whatever overhead it has, it will have ;)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Phil
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Le 5 nov. 2013 18:54, "Romain Manni-Bucau" <
>>> rmannibucau@gmail.com> a écrit :
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Well I didnt test sirona in prod but when using jamon (same
>>> kind of
>>>>>>>>>>>>>>>> framework) locks were creating a serious overhead on some
>>> benches. Not the
>>>>>>>>>>>>>>>> most important but enough to try to solve it.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That said we are not yet in 1.0 so Im ok to wait for more
>>> serious
>>>>>>>>>>>>>>>> feedbacks if you think it is better
>>>>>>>>>>>>>>>> Le 5 nov. 2013 18:48, "Ted Dunning" <te...@gmail.com>
>>> a écrit :
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Mon, Nov 4, 2013 at 10:09 PM, Romain Manni-Bucau
>>>>>>>>>>>>>>>>> <rm...@gmail.com>wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Oh sorry, that's what I said early, in a real app no or
>>> not enough to
>>>>>>>>>>>>>>>>> be an
>>>>>>>>>>>>>>>>>> issue buy on simple apps or very high thrououtput apps yes.
>>>>>>>>>>>>>>>>>> Le 5 nov. 2013 07:00, "Ted Dunning" <
>>> ted.dunning@gmail.com> a écrit :
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> That isn't what I meant.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Do you really think that more than one metric has to
>>> update
>>>>>>>>>>>>>>>>> (increment,
>>>>>>>>>>>>>>>>>>> say) at precisely the same time?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I realize that is what you said. Do you have any serious
>>> examples where
>>>>>>>>>>>>>>>>> metrics have to be updated all or nothing?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>
> ---------------------------------------------------------------------
> 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
Re: [math] Multithreaded performances
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi
first maybe the thread should move over sirona list (I wouldn't bother
commons ;)): http://sirona.incubator.apache.org/mail-lists.html
about hot topics I think we have:
1) Gui enhancement (a jira is about using another js library to draw
graphes and get an analysis/correlation view, another topic is the GUI
configuration: how to make dashboard etc...)
2) Storage backends (we support mainly cassandra and in memory ATM but
a rotating JDBC impl could be great too)
3) Alerting is not yet done and needs to be in final versions
4) Agent/Plugins enhancement (we have a few today)
5) Surely a better configuration
6) Counter implementation with less locks (even if thanks to the stat
impl we use we reduced the lock duration we still rely too much on
lock IMO and I'm sure we can do better).
7) etc.. ;)
It is a new project so all help is welcomed!
PS: we have an IRC channel on freenode: #apache-sirona
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2013/11/21 Thomas Neidhart <th...@gmail.com>:
> I did take a look at sirona, and it looks really nice.
> Whats the best way to contribute to it? Any open issues you would like to
> work somebody on?
>
> Thomas
>
>
> On Wed, Nov 20, 2013 at 5:38 PM, Romain Manni-Bucau
> <rm...@gmail.com>wrote:
>
>> yep but this is not enough, almost each "component" is doing n++. This
>> is fast but since done under a lock if it can be removed it should.
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>>
>>
>>
>> 2013/11/20 Phil Steitz <ph...@gmail.com>:
>> > On 11/20/13, 7:26 AM, Romain Manni-Bucau wrote:
>> >> next version (rewrite/fork):
>> >>
>> https://svn.apache.org/repos/asf/incubator/sirona/trunk/core/src/main/java/org/apache/sirona/counters/OptimizedStatistics.java
>> >>
>> >> was easier to centralize everything in a single class
>> >
>> > That is exactly what I meant about the moment statistics. They can
>> > share state. The problem is this approach eliminates the
>> > pluggability and also cuts out the other stats. We can probably
>> > have it both ways by allowing you to turn off stuff you don't want
>> > and just having the moment stats share state.
>> >
>> > Phil
>> >> Romain Manni-Bucau
>> >> Twitter: @rmannibucau
>> >> Blog: http://rmannibucau.wordpress.com/
>> >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> >> Github: https://github.com/rmannibucau
>> >>
>> >>
>> >>
>> >> 2013/11/20 Phil Steitz <ph...@gmail.com>:
>> >>> On 11/20/13, 12:43 AM, Romain Manni-Bucau wrote:
>> >>>> Hi
>> >>>>
>> >>>> A quick mail to give some feedbacks of my tests.
>> >>>>
>> >>>> I started to hack a bit to get rid of not used stats by sirona,
>> >>>> typically I do ATM:
>> >>>>
>> >>>> setSumsqImpl(NoopStat.INSTANCE);
>> >>>> setSumLogImpl(NoopStat.INSTANCE);
>> >>>> setGeoMeanImpl(NoopStat.INSTANCE);
>> >>>>
>> >>>> (NoopStat is a mock of StorelessUnivariateStatistic doijg nothing)
>> >>>>
>> >>>> Another point which could be improoved is the duplication of info
>> >>>> accross sub StorelessUnivariateStatistic (typically n computed several
>> >>>> times for instance).
>> >>> Good point. Its kind of funny that simplest way to solve the
>> >>> problem you mention at the end is to remove the flexibility that you
>> >>> use in the beginning - i.e., to no longer use separate stats
>> >>> instances to compute the bundled statistics. The setup is the way
>> >>> it is precisely so that you can plug in alternative impls. I had
>> >>> never thought of no-op-ing instances to suppress things, but it does
>> >>> work. Having stats share state data is a little tricky but in
>> >>> theory possible. The moment stats at least are set up to support
>> >>> this. Patches are welcome. If you don't mind opening a JIRA to
>> >>> suggest eliminating repeated computations that would be great.
>> >>>
>> >>> Phil
>> >>>> Romain Manni-Bucau
>> >>>> Twitter: @rmannibucau
>> >>>> Blog: http://rmannibucau.wordpress.com/
>> >>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> >>>> Github: https://github.com/rmannibucau
>> >>>>
>> >>>>
>> >>>>
>> >>>> 2013/11/6 Phil Steitz <ph...@gmail.com>:
>> >>>>> On 11/6/13 9:05 AM, Romain Manni-Bucau wrote:
>> >>>>>> Great!
>> >>>>>>
>> >>>>>> Btw not sure for sirona we oculd use it. One constraint on
>> sirona-core
>> >>>>>> is to stay self contained. We already shade math3 so shading pool2
>> too
>> >>>>>> would start to create a big jar for this need. I'll try to bench
>> >>>>>> deeper next week too.
>> >>>>> OK - and any ideas you have about how to implement something
>> >>>>> lightweight inside [math] much appreciated.
>> >>>>>
>> >>>>> Phil
>> >>>>>> Romain Manni-Bucau
>> >>>>>> Twitter: @rmannibucau
>> >>>>>> Blog: http://rmannibucau.wordpress.com/
>> >>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> >>>>>> Github: https://github.com/rmannibucau
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> 2013/11/6 Phil Steitz <ph...@gmail.com>:
>> >>>>>>> On 11/6/13 8:47 AM, Romain Manni-Bucau wrote:
>> >>>>>>>> well pool are based on locks so I'm not sure (it would need deep
>> >>>>>>>> benchs on a real app) it does worth it
>> >>>>>>> Commons pool2 uses pretty lightweight locking and using a pool of
>> >>>>>>> instances achieves the basic objective of reducing contention for
>> >>>>>>> the single sync lock on one SummaryStatistics object. I bet it
>> >>>>>>> would improve throughput over the single-instance approach if
>> >>>>>>> maxActive, maxIdle were tuned. If I get some time to play with
>> >>>>>>> this, I will report back with some benchmarks.
>> >>>>>>>
>> >>>>>>> Phil
>> >>>>>>>> Romain Manni-Bucau
>> >>>>>>>> Twitter: @rmannibucau
>> >>>>>>>> Blog: http://rmannibucau.wordpress.com/
>> >>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> >>>>>>>> Github: https://github.com/rmannibucau
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> 2013/11/6 Phil Steitz <ph...@gmail.com>:
>> >>>>>>>>> On 11/5/13 11:26 PM, Romain Manni-Bucau wrote:
>> >>>>>>>>>> Hehe, right.
>> >>>>>>>>>>
>> >>>>>>>>>> I looked a bit more today and LongAdder is only a part of the
>> >>>>>>>>>> solution. The stat computation still needs to lock to get acces
>> to
>> >>>>>>>>>> previous values (N -> N+1). Basically the gain wouldn't be as
>> >>>>>>>>>> important as I thought :(.
>> >>>>>>>>> Right, but I think your original idea of maintaining a pool of
>> >>>>>>>>> instances (fewer that one per thread) to be periodically
>> aggregated
>> >>>>>>>>> is a good one. See below.
>> >>>>>>>>>> As I said before we'll wait a bit to gather feedbacks, if it
>> blocks
>> >>>>>>>>>> I'll come back trying to find + propose a solution.
>> >>>>>>>>>>
>> >>>>>>>>>> Thanks in all cases for your answers!
>> >>>>>>>>> A workaround that I have started playing with (partly for other
>> >>>>>>>>> benchmarking reasons) might be to actually use a pool for the
>> stats
>> >>>>>>>>> objects that the monitoring threads use. Using a pool would
>> allow
>> >>>>>>>>> you to monitor and tune the parameters. We now have (well, once
>> the
>> >>>>>>>>> VOTE in progress completes :) a decently performing pool
>> >>>>>>>>> implementation. The tricky bit is locking the instances during
>> >>>>>>>>> aggregation. One way to handle this would be to have the
>> factory's
>> >>>>>>>>> passivate method and the aggregation thread contend for locks on
>> the
>> >>>>>>>>> pooled stats instances. The only contention would be when
>> >>>>>>>>> aggregation is copying individual instances and contention would
>> be
>> >>>>>>>>> with at most one client thread (waiting to proceed in passivate).
>> >>>>>>>>>
>> >>>>>>>>> Phil
>> >>>>>>>>>> Romain Manni-Bucau
>> >>>>>>>>>> Twitter: @rmannibucau
>> >>>>>>>>>> Blog: http://rmannibucau.wordpress.com/
>> >>>>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> >>>>>>>>>> Github: https://github.com/rmannibucau
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> 2013/11/5 Phil Steitz <ph...@gmail.com>:
>> >>>>>>>>>>> On 11/5/13 9:57 AM, Romain Manni-Bucau wrote:
>> >>>>>>>>>>>> @Phil: hmm can be but the framework would create its own
>> overhead which
>> >>>>>>>>>>>> would be avoided with a dedicated solution, no? Well thought
>> gain was great
>> >>>>>>>>>>>> for small investment but ok to postpone it
>> >>>>>>>>>>> As I said, patches welcome. Go for it. My point about the
>> >>>>>>>>>>> framework was that when you actually get this implemented
>> inside,
>> >>>>>>>>>>> e.g. SummaryStatistics, you will have built a mini-framework.
>> >>>>>>>>>>> Whatever overhead it has, it will have ;)
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> Phil
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>> Le 5 nov. 2013 18:54, "Romain Manni-Bucau" <
>> rmannibucau@gmail.com> a écrit :
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>> Well I didnt test sirona in prod but when using jamon (same
>> kind of
>> >>>>>>>>>>>>> framework) locks were creating a serious overhead on some
>> benches. Not the
>> >>>>>>>>>>>>> most important but enough to try to solve it.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> That said we are not yet in 1.0 so Im ok to wait for more
>> serious
>> >>>>>>>>>>>>> feedbacks if you think it is better
>> >>>>>>>>>>>>> Le 5 nov. 2013 18:48, "Ted Dunning" <te...@gmail.com>
>> a écrit :
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> On Mon, Nov 4, 2013 at 10:09 PM, Romain Manni-Bucau
>> >>>>>>>>>>>>>> <rm...@gmail.com>wrote:
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> Oh sorry, that's what I said early, in a real app no or
>> not enough to
>> >>>>>>>>>>>>>> be an
>> >>>>>>>>>>>>>>> issue buy on simple apps or very high thrououtput apps yes.
>> >>>>>>>>>>>>>>> Le 5 nov. 2013 07:00, "Ted Dunning" <
>> ted.dunning@gmail.com> a écrit :
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> That isn't what I meant.
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> Do you really think that more than one metric has to
>> update
>> >>>>>>>>>>>>>> (increment,
>> >>>>>>>>>>>>>>>> say) at precisely the same time?
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> I realize that is what you said. Do you have any serious
>> examples where
>> >>>>>>>>>>>>>> metrics have to be updated all or nothing?
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>
>> ---------------------------------------------------------------------
>> >>>>>>>>>>> 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
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>
>> ---------------------------------------------------------------------
>> >>>>>>>>> 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
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> ---------------------------------------------------------------------
>> >>>>>>> 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
>> >>>>>>
>> >>>>>>
>> >>>>> ---------------------------------------------------------------------
>> >>>>> 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
>> >>>>
>> >>>>
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> 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
>> >>
>> >>
>> >
>> >
>> > ---------------------------------------------------------------------
>> > 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
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Multithreaded performances
Posted by Thomas Neidhart <th...@gmail.com>.
I did take a look at sirona, and it looks really nice.
Whats the best way to contribute to it? Any open issues you would like to
work somebody on?
Thomas
On Wed, Nov 20, 2013 at 5:38 PM, Romain Manni-Bucau
<rm...@gmail.com>wrote:
> yep but this is not enough, almost each "component" is doing n++. This
> is fast but since done under a lock if it can be removed it should.
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2013/11/20 Phil Steitz <ph...@gmail.com>:
> > On 11/20/13, 7:26 AM, Romain Manni-Bucau wrote:
> >> next version (rewrite/fork):
> >>
> https://svn.apache.org/repos/asf/incubator/sirona/trunk/core/src/main/java/org/apache/sirona/counters/OptimizedStatistics.java
> >>
> >> was easier to centralize everything in a single class
> >
> > That is exactly what I meant about the moment statistics. They can
> > share state. The problem is this approach eliminates the
> > pluggability and also cuts out the other stats. We can probably
> > have it both ways by allowing you to turn off stuff you don't want
> > and just having the moment stats share state.
> >
> > Phil
> >> Romain Manni-Bucau
> >> Twitter: @rmannibucau
> >> Blog: http://rmannibucau.wordpress.com/
> >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >> Github: https://github.com/rmannibucau
> >>
> >>
> >>
> >> 2013/11/20 Phil Steitz <ph...@gmail.com>:
> >>> On 11/20/13, 12:43 AM, Romain Manni-Bucau wrote:
> >>>> Hi
> >>>>
> >>>> A quick mail to give some feedbacks of my tests.
> >>>>
> >>>> I started to hack a bit to get rid of not used stats by sirona,
> >>>> typically I do ATM:
> >>>>
> >>>> setSumsqImpl(NoopStat.INSTANCE);
> >>>> setSumLogImpl(NoopStat.INSTANCE);
> >>>> setGeoMeanImpl(NoopStat.INSTANCE);
> >>>>
> >>>> (NoopStat is a mock of StorelessUnivariateStatistic doijg nothing)
> >>>>
> >>>> Another point which could be improoved is the duplication of info
> >>>> accross sub StorelessUnivariateStatistic (typically n computed several
> >>>> times for instance).
> >>> Good point. Its kind of funny that simplest way to solve the
> >>> problem you mention at the end is to remove the flexibility that you
> >>> use in the beginning - i.e., to no longer use separate stats
> >>> instances to compute the bundled statistics. The setup is the way
> >>> it is precisely so that you can plug in alternative impls. I had
> >>> never thought of no-op-ing instances to suppress things, but it does
> >>> work. Having stats share state data is a little tricky but in
> >>> theory possible. The moment stats at least are set up to support
> >>> this. Patches are welcome. If you don't mind opening a JIRA to
> >>> suggest eliminating repeated computations that would be great.
> >>>
> >>> Phil
> >>>> Romain Manni-Bucau
> >>>> Twitter: @rmannibucau
> >>>> Blog: http://rmannibucau.wordpress.com/
> >>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >>>> Github: https://github.com/rmannibucau
> >>>>
> >>>>
> >>>>
> >>>> 2013/11/6 Phil Steitz <ph...@gmail.com>:
> >>>>> On 11/6/13 9:05 AM, Romain Manni-Bucau wrote:
> >>>>>> Great!
> >>>>>>
> >>>>>> Btw not sure for sirona we oculd use it. One constraint on
> sirona-core
> >>>>>> is to stay self contained. We already shade math3 so shading pool2
> too
> >>>>>> would start to create a big jar for this need. I'll try to bench
> >>>>>> deeper next week too.
> >>>>> OK - and any ideas you have about how to implement something
> >>>>> lightweight inside [math] much appreciated.
> >>>>>
> >>>>> Phil
> >>>>>> Romain Manni-Bucau
> >>>>>> Twitter: @rmannibucau
> >>>>>> Blog: http://rmannibucau.wordpress.com/
> >>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >>>>>> Github: https://github.com/rmannibucau
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> 2013/11/6 Phil Steitz <ph...@gmail.com>:
> >>>>>>> On 11/6/13 8:47 AM, Romain Manni-Bucau wrote:
> >>>>>>>> well pool are based on locks so I'm not sure (it would need deep
> >>>>>>>> benchs on a real app) it does worth it
> >>>>>>> Commons pool2 uses pretty lightweight locking and using a pool of
> >>>>>>> instances achieves the basic objective of reducing contention for
> >>>>>>> the single sync lock on one SummaryStatistics object. I bet it
> >>>>>>> would improve throughput over the single-instance approach if
> >>>>>>> maxActive, maxIdle were tuned. If I get some time to play with
> >>>>>>> this, I will report back with some benchmarks.
> >>>>>>>
> >>>>>>> Phil
> >>>>>>>> Romain Manni-Bucau
> >>>>>>>> Twitter: @rmannibucau
> >>>>>>>> Blog: http://rmannibucau.wordpress.com/
> >>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >>>>>>>> Github: https://github.com/rmannibucau
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 2013/11/6 Phil Steitz <ph...@gmail.com>:
> >>>>>>>>> On 11/5/13 11:26 PM, Romain Manni-Bucau wrote:
> >>>>>>>>>> Hehe, right.
> >>>>>>>>>>
> >>>>>>>>>> I looked a bit more today and LongAdder is only a part of the
> >>>>>>>>>> solution. The stat computation still needs to lock to get acces
> to
> >>>>>>>>>> previous values (N -> N+1). Basically the gain wouldn't be as
> >>>>>>>>>> important as I thought :(.
> >>>>>>>>> Right, but I think your original idea of maintaining a pool of
> >>>>>>>>> instances (fewer that one per thread) to be periodically
> aggregated
> >>>>>>>>> is a good one. See below.
> >>>>>>>>>> As I said before we'll wait a bit to gather feedbacks, if it
> blocks
> >>>>>>>>>> I'll come back trying to find + propose a solution.
> >>>>>>>>>>
> >>>>>>>>>> Thanks in all cases for your answers!
> >>>>>>>>> A workaround that I have started playing with (partly for other
> >>>>>>>>> benchmarking reasons) might be to actually use a pool for the
> stats
> >>>>>>>>> objects that the monitoring threads use. Using a pool would
> allow
> >>>>>>>>> you to monitor and tune the parameters. We now have (well, once
> the
> >>>>>>>>> VOTE in progress completes :) a decently performing pool
> >>>>>>>>> implementation. The tricky bit is locking the instances during
> >>>>>>>>> aggregation. One way to handle this would be to have the
> factory's
> >>>>>>>>> passivate method and the aggregation thread contend for locks on
> the
> >>>>>>>>> pooled stats instances. The only contention would be when
> >>>>>>>>> aggregation is copying individual instances and contention would
> be
> >>>>>>>>> with at most one client thread (waiting to proceed in passivate).
> >>>>>>>>>
> >>>>>>>>> Phil
> >>>>>>>>>> Romain Manni-Bucau
> >>>>>>>>>> Twitter: @rmannibucau
> >>>>>>>>>> Blog: http://rmannibucau.wordpress.com/
> >>>>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >>>>>>>>>> Github: https://github.com/rmannibucau
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 2013/11/5 Phil Steitz <ph...@gmail.com>:
> >>>>>>>>>>> On 11/5/13 9:57 AM, Romain Manni-Bucau wrote:
> >>>>>>>>>>>> @Phil: hmm can be but the framework would create its own
> overhead which
> >>>>>>>>>>>> would be avoided with a dedicated solution, no? Well thought
> gain was great
> >>>>>>>>>>>> for small investment but ok to postpone it
> >>>>>>>>>>> As I said, patches welcome. Go for it. My point about the
> >>>>>>>>>>> framework was that when you actually get this implemented
> inside,
> >>>>>>>>>>> e.g. SummaryStatistics, you will have built a mini-framework.
> >>>>>>>>>>> Whatever overhead it has, it will have ;)
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Phil
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> Le 5 nov. 2013 18:54, "Romain Manni-Bucau" <
> rmannibucau@gmail.com> a écrit :
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Well I didnt test sirona in prod but when using jamon (same
> kind of
> >>>>>>>>>>>>> framework) locks were creating a serious overhead on some
> benches. Not the
> >>>>>>>>>>>>> most important but enough to try to solve it.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> That said we are not yet in 1.0 so Im ok to wait for more
> serious
> >>>>>>>>>>>>> feedbacks if you think it is better
> >>>>>>>>>>>>> Le 5 nov. 2013 18:48, "Ted Dunning" <te...@gmail.com>
> a écrit :
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Mon, Nov 4, 2013 at 10:09 PM, Romain Manni-Bucau
> >>>>>>>>>>>>>> <rm...@gmail.com>wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Oh sorry, that's what I said early, in a real app no or
> not enough to
> >>>>>>>>>>>>>> be an
> >>>>>>>>>>>>>>> issue buy on simple apps or very high thrououtput apps yes.
> >>>>>>>>>>>>>>> Le 5 nov. 2013 07:00, "Ted Dunning" <
> ted.dunning@gmail.com> a écrit :
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> That isn't what I meant.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Do you really think that more than one metric has to
> update
> >>>>>>>>>>>>>> (increment,
> >>>>>>>>>>>>>>>> say) at precisely the same time?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I realize that is what you said. Do you have any serious
> examples where
> >>>>>>>>>>>>>> metrics have to be updated all or nothing?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>
> ---------------------------------------------------------------------
> >>>>>>>>>>> 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
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> ---------------------------------------------------------------------
> >>>>>>>>> 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
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>> 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
> >>>>>>
> >>>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> 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
> >>>>
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> 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
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
Re: [math] Multithreaded performances
Posted by Romain Manni-Bucau <rm...@gmail.com>.
yep but this is not enough, almost each "component" is doing n++. This
is fast but since done under a lock if it can be removed it should.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2013/11/20 Phil Steitz <ph...@gmail.com>:
> On 11/20/13, 7:26 AM, Romain Manni-Bucau wrote:
>> next version (rewrite/fork):
>> https://svn.apache.org/repos/asf/incubator/sirona/trunk/core/src/main/java/org/apache/sirona/counters/OptimizedStatistics.java
>>
>> was easier to centralize everything in a single class
>
> That is exactly what I meant about the moment statistics. They can
> share state. The problem is this approach eliminates the
> pluggability and also cuts out the other stats. We can probably
> have it both ways by allowing you to turn off stuff you don't want
> and just having the moment stats share state.
>
> Phil
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>>
>>
>>
>> 2013/11/20 Phil Steitz <ph...@gmail.com>:
>>> On 11/20/13, 12:43 AM, Romain Manni-Bucau wrote:
>>>> Hi
>>>>
>>>> A quick mail to give some feedbacks of my tests.
>>>>
>>>> I started to hack a bit to get rid of not used stats by sirona,
>>>> typically I do ATM:
>>>>
>>>> setSumsqImpl(NoopStat.INSTANCE);
>>>> setSumLogImpl(NoopStat.INSTANCE);
>>>> setGeoMeanImpl(NoopStat.INSTANCE);
>>>>
>>>> (NoopStat is a mock of StorelessUnivariateStatistic doijg nothing)
>>>>
>>>> Another point which could be improoved is the duplication of info
>>>> accross sub StorelessUnivariateStatistic (typically n computed several
>>>> times for instance).
>>> Good point. Its kind of funny that simplest way to solve the
>>> problem you mention at the end is to remove the flexibility that you
>>> use in the beginning - i.e., to no longer use separate stats
>>> instances to compute the bundled statistics. The setup is the way
>>> it is precisely so that you can plug in alternative impls. I had
>>> never thought of no-op-ing instances to suppress things, but it does
>>> work. Having stats share state data is a little tricky but in
>>> theory possible. The moment stats at least are set up to support
>>> this. Patches are welcome. If you don't mind opening a JIRA to
>>> suggest eliminating repeated computations that would be great.
>>>
>>> Phil
>>>> Romain Manni-Bucau
>>>> Twitter: @rmannibucau
>>>> Blog: http://rmannibucau.wordpress.com/
>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>> Github: https://github.com/rmannibucau
>>>>
>>>>
>>>>
>>>> 2013/11/6 Phil Steitz <ph...@gmail.com>:
>>>>> On 11/6/13 9:05 AM, Romain Manni-Bucau wrote:
>>>>>> Great!
>>>>>>
>>>>>> Btw not sure for sirona we oculd use it. One constraint on sirona-core
>>>>>> is to stay self contained. We already shade math3 so shading pool2 too
>>>>>> would start to create a big jar for this need. I'll try to bench
>>>>>> deeper next week too.
>>>>> OK - and any ideas you have about how to implement something
>>>>> lightweight inside [math] much appreciated.
>>>>>
>>>>> Phil
>>>>>> Romain Manni-Bucau
>>>>>> Twitter: @rmannibucau
>>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>>> Github: https://github.com/rmannibucau
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2013/11/6 Phil Steitz <ph...@gmail.com>:
>>>>>>> On 11/6/13 8:47 AM, Romain Manni-Bucau wrote:
>>>>>>>> well pool are based on locks so I'm not sure (it would need deep
>>>>>>>> benchs on a real app) it does worth it
>>>>>>> Commons pool2 uses pretty lightweight locking and using a pool of
>>>>>>> instances achieves the basic objective of reducing contention for
>>>>>>> the single sync lock on one SummaryStatistics object. I bet it
>>>>>>> would improve throughput over the single-instance approach if
>>>>>>> maxActive, maxIdle were tuned. If I get some time to play with
>>>>>>> this, I will report back with some benchmarks.
>>>>>>>
>>>>>>> Phil
>>>>>>>> Romain Manni-Bucau
>>>>>>>> Twitter: @rmannibucau
>>>>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>>>>> Github: https://github.com/rmannibucau
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2013/11/6 Phil Steitz <ph...@gmail.com>:
>>>>>>>>> On 11/5/13 11:26 PM, Romain Manni-Bucau wrote:
>>>>>>>>>> Hehe, right.
>>>>>>>>>>
>>>>>>>>>> I looked a bit more today and LongAdder is only a part of the
>>>>>>>>>> solution. The stat computation still needs to lock to get acces to
>>>>>>>>>> previous values (N -> N+1). Basically the gain wouldn't be as
>>>>>>>>>> important as I thought :(.
>>>>>>>>> Right, but I think your original idea of maintaining a pool of
>>>>>>>>> instances (fewer that one per thread) to be periodically aggregated
>>>>>>>>> is a good one. See below.
>>>>>>>>>> As I said before we'll wait a bit to gather feedbacks, if it blocks
>>>>>>>>>> I'll come back trying to find + propose a solution.
>>>>>>>>>>
>>>>>>>>>> Thanks in all cases for your answers!
>>>>>>>>> A workaround that I have started playing with (partly for other
>>>>>>>>> benchmarking reasons) might be to actually use a pool for the stats
>>>>>>>>> objects that the monitoring threads use. Using a pool would allow
>>>>>>>>> you to monitor and tune the parameters. We now have (well, once the
>>>>>>>>> VOTE in progress completes :) a decently performing pool
>>>>>>>>> implementation. The tricky bit is locking the instances during
>>>>>>>>> aggregation. One way to handle this would be to have the factory's
>>>>>>>>> passivate method and the aggregation thread contend for locks on the
>>>>>>>>> pooled stats instances. The only contention would be when
>>>>>>>>> aggregation is copying individual instances and contention would be
>>>>>>>>> with at most one client thread (waiting to proceed in passivate).
>>>>>>>>>
>>>>>>>>> Phil
>>>>>>>>>> Romain Manni-Bucau
>>>>>>>>>> Twitter: @rmannibucau
>>>>>>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>>>>>>> Github: https://github.com/rmannibucau
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2013/11/5 Phil Steitz <ph...@gmail.com>:
>>>>>>>>>>> On 11/5/13 9:57 AM, Romain Manni-Bucau wrote:
>>>>>>>>>>>> @Phil: hmm can be but the framework would create its own overhead which
>>>>>>>>>>>> would be avoided with a dedicated solution, no? Well thought gain was great
>>>>>>>>>>>> for small investment but ok to postpone it
>>>>>>>>>>> As I said, patches welcome. Go for it. My point about the
>>>>>>>>>>> framework was that when you actually get this implemented inside,
>>>>>>>>>>> e.g. SummaryStatistics, you will have built a mini-framework.
>>>>>>>>>>> Whatever overhead it has, it will have ;)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Phil
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Le 5 nov. 2013 18:54, "Romain Manni-Bucau" <rm...@gmail.com> a écrit :
>>>>>>>>>>>>
>>>>>>>>>>>>> Well I didnt test sirona in prod but when using jamon (same kind of
>>>>>>>>>>>>> framework) locks were creating a serious overhead on some benches. Not the
>>>>>>>>>>>>> most important but enough to try to solve it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> That said we are not yet in 1.0 so Im ok to wait for more serious
>>>>>>>>>>>>> feedbacks if you think it is better
>>>>>>>>>>>>> Le 5 nov. 2013 18:48, "Ted Dunning" <te...@gmail.com> a écrit :
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Nov 4, 2013 at 10:09 PM, Romain Manni-Bucau
>>>>>>>>>>>>>> <rm...@gmail.com>wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Oh sorry, that's what I said early, in a real app no or not enough to
>>>>>>>>>>>>>> be an
>>>>>>>>>>>>>>> issue buy on simple apps or very high thrououtput apps yes.
>>>>>>>>>>>>>>> Le 5 nov. 2013 07:00, "Ted Dunning" <te...@gmail.com> a écrit :
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That isn't what I meant.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Do you really think that more than one metric has to update
>>>>>>>>>>>>>> (increment,
>>>>>>>>>>>>>>>> say) at precisely the same time?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I realize that is what you said. Do you have any serious examples where
>>>>>>>>>>>>>> metrics have to be updated all or nothing?
>>>>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
>
> ---------------------------------------------------------------------
> 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
Re: [math] Multithreaded performances
Posted by Phil Steitz <ph...@gmail.com>.
On 11/20/13, 7:26 AM, Romain Manni-Bucau wrote:
> next version (rewrite/fork):
> https://svn.apache.org/repos/asf/incubator/sirona/trunk/core/src/main/java/org/apache/sirona/counters/OptimizedStatistics.java
>
> was easier to centralize everything in a single class
That is exactly what I meant about the moment statistics. They can
share state. The problem is this approach eliminates the
pluggability and also cuts out the other stats. We can probably
have it both ways by allowing you to turn off stuff you don't want
and just having the moment stats share state.
Phil
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2013/11/20 Phil Steitz <ph...@gmail.com>:
>> On 11/20/13, 12:43 AM, Romain Manni-Bucau wrote:
>>> Hi
>>>
>>> A quick mail to give some feedbacks of my tests.
>>>
>>> I started to hack a bit to get rid of not used stats by sirona,
>>> typically I do ATM:
>>>
>>> setSumsqImpl(NoopStat.INSTANCE);
>>> setSumLogImpl(NoopStat.INSTANCE);
>>> setGeoMeanImpl(NoopStat.INSTANCE);
>>>
>>> (NoopStat is a mock of StorelessUnivariateStatistic doijg nothing)
>>>
>>> Another point which could be improoved is the duplication of info
>>> accross sub StorelessUnivariateStatistic (typically n computed several
>>> times for instance).
>> Good point. Its kind of funny that simplest way to solve the
>> problem you mention at the end is to remove the flexibility that you
>> use in the beginning - i.e., to no longer use separate stats
>> instances to compute the bundled statistics. The setup is the way
>> it is precisely so that you can plug in alternative impls. I had
>> never thought of no-op-ing instances to suppress things, but it does
>> work. Having stats share state data is a little tricky but in
>> theory possible. The moment stats at least are set up to support
>> this. Patches are welcome. If you don't mind opening a JIRA to
>> suggest eliminating repeated computations that would be great.
>>
>> Phil
>>> Romain Manni-Bucau
>>> Twitter: @rmannibucau
>>> Blog: http://rmannibucau.wordpress.com/
>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>> Github: https://github.com/rmannibucau
>>>
>>>
>>>
>>> 2013/11/6 Phil Steitz <ph...@gmail.com>:
>>>> On 11/6/13 9:05 AM, Romain Manni-Bucau wrote:
>>>>> Great!
>>>>>
>>>>> Btw not sure for sirona we oculd use it. One constraint on sirona-core
>>>>> is to stay self contained. We already shade math3 so shading pool2 too
>>>>> would start to create a big jar for this need. I'll try to bench
>>>>> deeper next week too.
>>>> OK - and any ideas you have about how to implement something
>>>> lightweight inside [math] much appreciated.
>>>>
>>>> Phil
>>>>> Romain Manni-Bucau
>>>>> Twitter: @rmannibucau
>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>> Github: https://github.com/rmannibucau
>>>>>
>>>>>
>>>>>
>>>>> 2013/11/6 Phil Steitz <ph...@gmail.com>:
>>>>>> On 11/6/13 8:47 AM, Romain Manni-Bucau wrote:
>>>>>>> well pool are based on locks so I'm not sure (it would need deep
>>>>>>> benchs on a real app) it does worth it
>>>>>> Commons pool2 uses pretty lightweight locking and using a pool of
>>>>>> instances achieves the basic objective of reducing contention for
>>>>>> the single sync lock on one SummaryStatistics object. I bet it
>>>>>> would improve throughput over the single-instance approach if
>>>>>> maxActive, maxIdle were tuned. If I get some time to play with
>>>>>> this, I will report back with some benchmarks.
>>>>>>
>>>>>> Phil
>>>>>>> Romain Manni-Bucau
>>>>>>> Twitter: @rmannibucau
>>>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>>>> Github: https://github.com/rmannibucau
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2013/11/6 Phil Steitz <ph...@gmail.com>:
>>>>>>>> On 11/5/13 11:26 PM, Romain Manni-Bucau wrote:
>>>>>>>>> Hehe, right.
>>>>>>>>>
>>>>>>>>> I looked a bit more today and LongAdder is only a part of the
>>>>>>>>> solution. The stat computation still needs to lock to get acces to
>>>>>>>>> previous values (N -> N+1). Basically the gain wouldn't be as
>>>>>>>>> important as I thought :(.
>>>>>>>> Right, but I think your original idea of maintaining a pool of
>>>>>>>> instances (fewer that one per thread) to be periodically aggregated
>>>>>>>> is a good one. See below.
>>>>>>>>> As I said before we'll wait a bit to gather feedbacks, if it blocks
>>>>>>>>> I'll come back trying to find + propose a solution.
>>>>>>>>>
>>>>>>>>> Thanks in all cases for your answers!
>>>>>>>> A workaround that I have started playing with (partly for other
>>>>>>>> benchmarking reasons) might be to actually use a pool for the stats
>>>>>>>> objects that the monitoring threads use. Using a pool would allow
>>>>>>>> you to monitor and tune the parameters. We now have (well, once the
>>>>>>>> VOTE in progress completes :) a decently performing pool
>>>>>>>> implementation. The tricky bit is locking the instances during
>>>>>>>> aggregation. One way to handle this would be to have the factory's
>>>>>>>> passivate method and the aggregation thread contend for locks on the
>>>>>>>> pooled stats instances. The only contention would be when
>>>>>>>> aggregation is copying individual instances and contention would be
>>>>>>>> with at most one client thread (waiting to proceed in passivate).
>>>>>>>>
>>>>>>>> Phil
>>>>>>>>> Romain Manni-Bucau
>>>>>>>>> Twitter: @rmannibucau
>>>>>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>>>>>> Github: https://github.com/rmannibucau
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2013/11/5 Phil Steitz <ph...@gmail.com>:
>>>>>>>>>> On 11/5/13 9:57 AM, Romain Manni-Bucau wrote:
>>>>>>>>>>> @Phil: hmm can be but the framework would create its own overhead which
>>>>>>>>>>> would be avoided with a dedicated solution, no? Well thought gain was great
>>>>>>>>>>> for small investment but ok to postpone it
>>>>>>>>>> As I said, patches welcome. Go for it. My point about the
>>>>>>>>>> framework was that when you actually get this implemented inside,
>>>>>>>>>> e.g. SummaryStatistics, you will have built a mini-framework.
>>>>>>>>>> Whatever overhead it has, it will have ;)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Phil
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Le 5 nov. 2013 18:54, "Romain Manni-Bucau" <rm...@gmail.com> a écrit :
>>>>>>>>>>>
>>>>>>>>>>>> Well I didnt test sirona in prod but when using jamon (same kind of
>>>>>>>>>>>> framework) locks were creating a serious overhead on some benches. Not the
>>>>>>>>>>>> most important but enough to try to solve it.
>>>>>>>>>>>>
>>>>>>>>>>>> That said we are not yet in 1.0 so Im ok to wait for more serious
>>>>>>>>>>>> feedbacks if you think it is better
>>>>>>>>>>>> Le 5 nov. 2013 18:48, "Ted Dunning" <te...@gmail.com> a écrit :
>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Nov 4, 2013 at 10:09 PM, Romain Manni-Bucau
>>>>>>>>>>>>> <rm...@gmail.com>wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Oh sorry, that's what I said early, in a real app no or not enough to
>>>>>>>>>>>>> be an
>>>>>>>>>>>>>> issue buy on simple apps or very high thrououtput apps yes.
>>>>>>>>>>>>>> Le 5 nov. 2013 07:00, "Ted Dunning" <te...@gmail.com> a écrit :
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That isn't what I meant.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Do you really think that more than one metric has to update
>>>>>>>>>>>>> (increment,
>>>>>>>>>>>>>>> say) at precisely the same time?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>> I realize that is what you said. Do you have any serious examples where
>>>>>>>>>>>>> metrics have to be updated all or nothing?
>>>>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Multithreaded performances
Posted by Romain Manni-Bucau <rm...@gmail.com>.
next version (rewrite/fork):
https://svn.apache.org/repos/asf/incubator/sirona/trunk/core/src/main/java/org/apache/sirona/counters/OptimizedStatistics.java
was easier to centralize everything in a single class
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2013/11/20 Phil Steitz <ph...@gmail.com>:
> On 11/20/13, 12:43 AM, Romain Manni-Bucau wrote:
>> Hi
>>
>> A quick mail to give some feedbacks of my tests.
>>
>> I started to hack a bit to get rid of not used stats by sirona,
>> typically I do ATM:
>>
>> setSumsqImpl(NoopStat.INSTANCE);
>> setSumLogImpl(NoopStat.INSTANCE);
>> setGeoMeanImpl(NoopStat.INSTANCE);
>>
>> (NoopStat is a mock of StorelessUnivariateStatistic doijg nothing)
>>
>> Another point which could be improoved is the duplication of info
>> accross sub StorelessUnivariateStatistic (typically n computed several
>> times for instance).
>
> Good point. Its kind of funny that simplest way to solve the
> problem you mention at the end is to remove the flexibility that you
> use in the beginning - i.e., to no longer use separate stats
> instances to compute the bundled statistics. The setup is the way
> it is precisely so that you can plug in alternative impls. I had
> never thought of no-op-ing instances to suppress things, but it does
> work. Having stats share state data is a little tricky but in
> theory possible. The moment stats at least are set up to support
> this. Patches are welcome. If you don't mind opening a JIRA to
> suggest eliminating repeated computations that would be great.
>
> Phil
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>>
>>
>>
>> 2013/11/6 Phil Steitz <ph...@gmail.com>:
>>> On 11/6/13 9:05 AM, Romain Manni-Bucau wrote:
>>>> Great!
>>>>
>>>> Btw not sure for sirona we oculd use it. One constraint on sirona-core
>>>> is to stay self contained. We already shade math3 so shading pool2 too
>>>> would start to create a big jar for this need. I'll try to bench
>>>> deeper next week too.
>>> OK - and any ideas you have about how to implement something
>>> lightweight inside [math] much appreciated.
>>>
>>> Phil
>>>> Romain Manni-Bucau
>>>> Twitter: @rmannibucau
>>>> Blog: http://rmannibucau.wordpress.com/
>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>> Github: https://github.com/rmannibucau
>>>>
>>>>
>>>>
>>>> 2013/11/6 Phil Steitz <ph...@gmail.com>:
>>>>> On 11/6/13 8:47 AM, Romain Manni-Bucau wrote:
>>>>>> well pool are based on locks so I'm not sure (it would need deep
>>>>>> benchs on a real app) it does worth it
>>>>> Commons pool2 uses pretty lightweight locking and using a pool of
>>>>> instances achieves the basic objective of reducing contention for
>>>>> the single sync lock on one SummaryStatistics object. I bet it
>>>>> would improve throughput over the single-instance approach if
>>>>> maxActive, maxIdle were tuned. If I get some time to play with
>>>>> this, I will report back with some benchmarks.
>>>>>
>>>>> Phil
>>>>>> Romain Manni-Bucau
>>>>>> Twitter: @rmannibucau
>>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>>> Github: https://github.com/rmannibucau
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2013/11/6 Phil Steitz <ph...@gmail.com>:
>>>>>>> On 11/5/13 11:26 PM, Romain Manni-Bucau wrote:
>>>>>>>> Hehe, right.
>>>>>>>>
>>>>>>>> I looked a bit more today and LongAdder is only a part of the
>>>>>>>> solution. The stat computation still needs to lock to get acces to
>>>>>>>> previous values (N -> N+1). Basically the gain wouldn't be as
>>>>>>>> important as I thought :(.
>>>>>>> Right, but I think your original idea of maintaining a pool of
>>>>>>> instances (fewer that one per thread) to be periodically aggregated
>>>>>>> is a good one. See below.
>>>>>>>> As I said before we'll wait a bit to gather feedbacks, if it blocks
>>>>>>>> I'll come back trying to find + propose a solution.
>>>>>>>>
>>>>>>>> Thanks in all cases for your answers!
>>>>>>> A workaround that I have started playing with (partly for other
>>>>>>> benchmarking reasons) might be to actually use a pool for the stats
>>>>>>> objects that the monitoring threads use. Using a pool would allow
>>>>>>> you to monitor and tune the parameters. We now have (well, once the
>>>>>>> VOTE in progress completes :) a decently performing pool
>>>>>>> implementation. The tricky bit is locking the instances during
>>>>>>> aggregation. One way to handle this would be to have the factory's
>>>>>>> passivate method and the aggregation thread contend for locks on the
>>>>>>> pooled stats instances. The only contention would be when
>>>>>>> aggregation is copying individual instances and contention would be
>>>>>>> with at most one client thread (waiting to proceed in passivate).
>>>>>>>
>>>>>>> Phil
>>>>>>>> Romain Manni-Bucau
>>>>>>>> Twitter: @rmannibucau
>>>>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>>>>> Github: https://github.com/rmannibucau
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2013/11/5 Phil Steitz <ph...@gmail.com>:
>>>>>>>>> On 11/5/13 9:57 AM, Romain Manni-Bucau wrote:
>>>>>>>>>> @Phil: hmm can be but the framework would create its own overhead which
>>>>>>>>>> would be avoided with a dedicated solution, no? Well thought gain was great
>>>>>>>>>> for small investment but ok to postpone it
>>>>>>>>> As I said, patches welcome. Go for it. My point about the
>>>>>>>>> framework was that when you actually get this implemented inside,
>>>>>>>>> e.g. SummaryStatistics, you will have built a mini-framework.
>>>>>>>>> Whatever overhead it has, it will have ;)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Phil
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Le 5 nov. 2013 18:54, "Romain Manni-Bucau" <rm...@gmail.com> a écrit :
>>>>>>>>>>
>>>>>>>>>>> Well I didnt test sirona in prod but when using jamon (same kind of
>>>>>>>>>>> framework) locks were creating a serious overhead on some benches. Not the
>>>>>>>>>>> most important but enough to try to solve it.
>>>>>>>>>>>
>>>>>>>>>>> That said we are not yet in 1.0 so Im ok to wait for more serious
>>>>>>>>>>> feedbacks if you think it is better
>>>>>>>>>>> Le 5 nov. 2013 18:48, "Ted Dunning" <te...@gmail.com> a écrit :
>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Nov 4, 2013 at 10:09 PM, Romain Manni-Bucau
>>>>>>>>>>>> <rm...@gmail.com>wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Oh sorry, that's what I said early, in a real app no or not enough to
>>>>>>>>>>>> be an
>>>>>>>>>>>>> issue buy on simple apps or very high thrououtput apps yes.
>>>>>>>>>>>>> Le 5 nov. 2013 07:00, "Ted Dunning" <te...@gmail.com> a écrit :
>>>>>>>>>>>>>
>>>>>>>>>>>>>> That isn't what I meant.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Do you really think that more than one metric has to update
>>>>>>>>>>>> (increment,
>>>>>>>>>>>>>> say) at precisely the same time?
>>>>>>>>>>>>>>
>>>>>>>>>>>> I realize that is what you said. Do you have any serious examples where
>>>>>>>>>>>> metrics have to be updated all or nothing?
>>>>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
>
> ---------------------------------------------------------------------
> 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
Re: [math] Multithreaded performances
Posted by Phil Steitz <ph...@gmail.com>.
On 11/20/13, 12:43 AM, Romain Manni-Bucau wrote:
> Hi
>
> A quick mail to give some feedbacks of my tests.
>
> I started to hack a bit to get rid of not used stats by sirona,
> typically I do ATM:
>
> setSumsqImpl(NoopStat.INSTANCE);
> setSumLogImpl(NoopStat.INSTANCE);
> setGeoMeanImpl(NoopStat.INSTANCE);
>
> (NoopStat is a mock of StorelessUnivariateStatistic doijg nothing)
>
> Another point which could be improoved is the duplication of info
> accross sub StorelessUnivariateStatistic (typically n computed several
> times for instance).
Good point. Its kind of funny that simplest way to solve the
problem you mention at the end is to remove the flexibility that you
use in the beginning - i.e., to no longer use separate stats
instances to compute the bundled statistics. The setup is the way
it is precisely so that you can plug in alternative impls. I had
never thought of no-op-ing instances to suppress things, but it does
work. Having stats share state data is a little tricky but in
theory possible. The moment stats at least are set up to support
this. Patches are welcome. If you don't mind opening a JIRA to
suggest eliminating repeated computations that would be great.
Phil
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2013/11/6 Phil Steitz <ph...@gmail.com>:
>> On 11/6/13 9:05 AM, Romain Manni-Bucau wrote:
>>> Great!
>>>
>>> Btw not sure for sirona we oculd use it. One constraint on sirona-core
>>> is to stay self contained. We already shade math3 so shading pool2 too
>>> would start to create a big jar for this need. I'll try to bench
>>> deeper next week too.
>> OK - and any ideas you have about how to implement something
>> lightweight inside [math] much appreciated.
>>
>> Phil
>>> Romain Manni-Bucau
>>> Twitter: @rmannibucau
>>> Blog: http://rmannibucau.wordpress.com/
>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>> Github: https://github.com/rmannibucau
>>>
>>>
>>>
>>> 2013/11/6 Phil Steitz <ph...@gmail.com>:
>>>> On 11/6/13 8:47 AM, Romain Manni-Bucau wrote:
>>>>> well pool are based on locks so I'm not sure (it would need deep
>>>>> benchs on a real app) it does worth it
>>>> Commons pool2 uses pretty lightweight locking and using a pool of
>>>> instances achieves the basic objective of reducing contention for
>>>> the single sync lock on one SummaryStatistics object. I bet it
>>>> would improve throughput over the single-instance approach if
>>>> maxActive, maxIdle were tuned. If I get some time to play with
>>>> this, I will report back with some benchmarks.
>>>>
>>>> Phil
>>>>> Romain Manni-Bucau
>>>>> Twitter: @rmannibucau
>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>> Github: https://github.com/rmannibucau
>>>>>
>>>>>
>>>>>
>>>>> 2013/11/6 Phil Steitz <ph...@gmail.com>:
>>>>>> On 11/5/13 11:26 PM, Romain Manni-Bucau wrote:
>>>>>>> Hehe, right.
>>>>>>>
>>>>>>> I looked a bit more today and LongAdder is only a part of the
>>>>>>> solution. The stat computation still needs to lock to get acces to
>>>>>>> previous values (N -> N+1). Basically the gain wouldn't be as
>>>>>>> important as I thought :(.
>>>>>> Right, but I think your original idea of maintaining a pool of
>>>>>> instances (fewer that one per thread) to be periodically aggregated
>>>>>> is a good one. See below.
>>>>>>> As I said before we'll wait a bit to gather feedbacks, if it blocks
>>>>>>> I'll come back trying to find + propose a solution.
>>>>>>>
>>>>>>> Thanks in all cases for your answers!
>>>>>> A workaround that I have started playing with (partly for other
>>>>>> benchmarking reasons) might be to actually use a pool for the stats
>>>>>> objects that the monitoring threads use. Using a pool would allow
>>>>>> you to monitor and tune the parameters. We now have (well, once the
>>>>>> VOTE in progress completes :) a decently performing pool
>>>>>> implementation. The tricky bit is locking the instances during
>>>>>> aggregation. One way to handle this would be to have the factory's
>>>>>> passivate method and the aggregation thread contend for locks on the
>>>>>> pooled stats instances. The only contention would be when
>>>>>> aggregation is copying individual instances and contention would be
>>>>>> with at most one client thread (waiting to proceed in passivate).
>>>>>>
>>>>>> Phil
>>>>>>> Romain Manni-Bucau
>>>>>>> Twitter: @rmannibucau
>>>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>>>> Github: https://github.com/rmannibucau
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2013/11/5 Phil Steitz <ph...@gmail.com>:
>>>>>>>> On 11/5/13 9:57 AM, Romain Manni-Bucau wrote:
>>>>>>>>> @Phil: hmm can be but the framework would create its own overhead which
>>>>>>>>> would be avoided with a dedicated solution, no? Well thought gain was great
>>>>>>>>> for small investment but ok to postpone it
>>>>>>>> As I said, patches welcome. Go for it. My point about the
>>>>>>>> framework was that when you actually get this implemented inside,
>>>>>>>> e.g. SummaryStatistics, you will have built a mini-framework.
>>>>>>>> Whatever overhead it has, it will have ;)
>>>>>>>>
>>>>>>>>
>>>>>>>> Phil
>>>>>>>>
>>>>>>>>
>>>>>>>>> Le 5 nov. 2013 18:54, "Romain Manni-Bucau" <rm...@gmail.com> a écrit :
>>>>>>>>>
>>>>>>>>>> Well I didnt test sirona in prod but when using jamon (same kind of
>>>>>>>>>> framework) locks were creating a serious overhead on some benches. Not the
>>>>>>>>>> most important but enough to try to solve it.
>>>>>>>>>>
>>>>>>>>>> That said we are not yet in 1.0 so Im ok to wait for more serious
>>>>>>>>>> feedbacks if you think it is better
>>>>>>>>>> Le 5 nov. 2013 18:48, "Ted Dunning" <te...@gmail.com> a écrit :
>>>>>>>>>>
>>>>>>>>>>> On Mon, Nov 4, 2013 at 10:09 PM, Romain Manni-Bucau
>>>>>>>>>>> <rm...@gmail.com>wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Oh sorry, that's what I said early, in a real app no or not enough to
>>>>>>>>>>> be an
>>>>>>>>>>>> issue buy on simple apps or very high thrououtput apps yes.
>>>>>>>>>>>> Le 5 nov. 2013 07:00, "Ted Dunning" <te...@gmail.com> a écrit :
>>>>>>>>>>>>
>>>>>>>>>>>>> That isn't what I meant.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Do you really think that more than one metric has to update
>>>>>>>>>>> (increment,
>>>>>>>>>>>>> say) at precisely the same time?
>>>>>>>>>>>>>
>>>>>>>>>>> I realize that is what you said. Do you have any serious examples where
>>>>>>>>>>> metrics have to be updated all or nothing?
>>>>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Multithreaded performances
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi
A quick mail to give some feedbacks of my tests.
I started to hack a bit to get rid of not used stats by sirona,
typically I do ATM:
setSumsqImpl(NoopStat.INSTANCE);
setSumLogImpl(NoopStat.INSTANCE);
setGeoMeanImpl(NoopStat.INSTANCE);
(NoopStat is a mock of StorelessUnivariateStatistic doijg nothing)
Another point which could be improoved is the duplication of info
accross sub StorelessUnivariateStatistic (typically n computed several
times for instance).
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2013/11/6 Phil Steitz <ph...@gmail.com>:
> On 11/6/13 9:05 AM, Romain Manni-Bucau wrote:
>> Great!
>>
>> Btw not sure for sirona we oculd use it. One constraint on sirona-core
>> is to stay self contained. We already shade math3 so shading pool2 too
>> would start to create a big jar for this need. I'll try to bench
>> deeper next week too.
>
> OK - and any ideas you have about how to implement something
> lightweight inside [math] much appreciated.
>
> Phil
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>>
>>
>>
>> 2013/11/6 Phil Steitz <ph...@gmail.com>:
>>> On 11/6/13 8:47 AM, Romain Manni-Bucau wrote:
>>>> well pool are based on locks so I'm not sure (it would need deep
>>>> benchs on a real app) it does worth it
>>> Commons pool2 uses pretty lightweight locking and using a pool of
>>> instances achieves the basic objective of reducing contention for
>>> the single sync lock on one SummaryStatistics object. I bet it
>>> would improve throughput over the single-instance approach if
>>> maxActive, maxIdle were tuned. If I get some time to play with
>>> this, I will report back with some benchmarks.
>>>
>>> Phil
>>>> Romain Manni-Bucau
>>>> Twitter: @rmannibucau
>>>> Blog: http://rmannibucau.wordpress.com/
>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>> Github: https://github.com/rmannibucau
>>>>
>>>>
>>>>
>>>> 2013/11/6 Phil Steitz <ph...@gmail.com>:
>>>>> On 11/5/13 11:26 PM, Romain Manni-Bucau wrote:
>>>>>> Hehe, right.
>>>>>>
>>>>>> I looked a bit more today and LongAdder is only a part of the
>>>>>> solution. The stat computation still needs to lock to get acces to
>>>>>> previous values (N -> N+1). Basically the gain wouldn't be as
>>>>>> important as I thought :(.
>>>>> Right, but I think your original idea of maintaining a pool of
>>>>> instances (fewer that one per thread) to be periodically aggregated
>>>>> is a good one. See below.
>>>>>> As I said before we'll wait a bit to gather feedbacks, if it blocks
>>>>>> I'll come back trying to find + propose a solution.
>>>>>>
>>>>>> Thanks in all cases for your answers!
>>>>> A workaround that I have started playing with (partly for other
>>>>> benchmarking reasons) might be to actually use a pool for the stats
>>>>> objects that the monitoring threads use. Using a pool would allow
>>>>> you to monitor and tune the parameters. We now have (well, once the
>>>>> VOTE in progress completes :) a decently performing pool
>>>>> implementation. The tricky bit is locking the instances during
>>>>> aggregation. One way to handle this would be to have the factory's
>>>>> passivate method and the aggregation thread contend for locks on the
>>>>> pooled stats instances. The only contention would be when
>>>>> aggregation is copying individual instances and contention would be
>>>>> with at most one client thread (waiting to proceed in passivate).
>>>>>
>>>>> Phil
>>>>>> Romain Manni-Bucau
>>>>>> Twitter: @rmannibucau
>>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>>> Github: https://github.com/rmannibucau
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2013/11/5 Phil Steitz <ph...@gmail.com>:
>>>>>>> On 11/5/13 9:57 AM, Romain Manni-Bucau wrote:
>>>>>>>> @Phil: hmm can be but the framework would create its own overhead which
>>>>>>>> would be avoided with a dedicated solution, no? Well thought gain was great
>>>>>>>> for small investment but ok to postpone it
>>>>>>> As I said, patches welcome. Go for it. My point about the
>>>>>>> framework was that when you actually get this implemented inside,
>>>>>>> e.g. SummaryStatistics, you will have built a mini-framework.
>>>>>>> Whatever overhead it has, it will have ;)
>>>>>>>
>>>>>>>
>>>>>>> Phil
>>>>>>>
>>>>>>>
>>>>>>>> Le 5 nov. 2013 18:54, "Romain Manni-Bucau" <rm...@gmail.com> a écrit :
>>>>>>>>
>>>>>>>>> Well I didnt test sirona in prod but when using jamon (same kind of
>>>>>>>>> framework) locks were creating a serious overhead on some benches. Not the
>>>>>>>>> most important but enough to try to solve it.
>>>>>>>>>
>>>>>>>>> That said we are not yet in 1.0 so Im ok to wait for more serious
>>>>>>>>> feedbacks if you think it is better
>>>>>>>>> Le 5 nov. 2013 18:48, "Ted Dunning" <te...@gmail.com> a écrit :
>>>>>>>>>
>>>>>>>>>> On Mon, Nov 4, 2013 at 10:09 PM, Romain Manni-Bucau
>>>>>>>>>> <rm...@gmail.com>wrote:
>>>>>>>>>>
>>>>>>>>>>> Oh sorry, that's what I said early, in a real app no or not enough to
>>>>>>>>>> be an
>>>>>>>>>>> issue buy on simple apps or very high thrououtput apps yes.
>>>>>>>>>>> Le 5 nov. 2013 07:00, "Ted Dunning" <te...@gmail.com> a écrit :
>>>>>>>>>>>
>>>>>>>>>>>> That isn't what I meant.
>>>>>>>>>>>>
>>>>>>>>>>>> Do you really think that more than one metric has to update
>>>>>>>>>> (increment,
>>>>>>>>>>>> say) at precisely the same time?
>>>>>>>>>>>>
>>>>>>>>>> I realize that is what you said. Do you have any serious examples where
>>>>>>>>>> metrics have to be updated all or nothing?
>>>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
>
> ---------------------------------------------------------------------
> 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
Re: [math] Multithreaded performances
Posted by Phil Steitz <ph...@gmail.com>.
On 11/6/13 9:05 AM, Romain Manni-Bucau wrote:
> Great!
>
> Btw not sure for sirona we oculd use it. One constraint on sirona-core
> is to stay self contained. We already shade math3 so shading pool2 too
> would start to create a big jar for this need. I'll try to bench
> deeper next week too.
OK - and any ideas you have about how to implement something
lightweight inside [math] much appreciated.
Phil
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2013/11/6 Phil Steitz <ph...@gmail.com>:
>> On 11/6/13 8:47 AM, Romain Manni-Bucau wrote:
>>> well pool are based on locks so I'm not sure (it would need deep
>>> benchs on a real app) it does worth it
>> Commons pool2 uses pretty lightweight locking and using a pool of
>> instances achieves the basic objective of reducing contention for
>> the single sync lock on one SummaryStatistics object. I bet it
>> would improve throughput over the single-instance approach if
>> maxActive, maxIdle were tuned. If I get some time to play with
>> this, I will report back with some benchmarks.
>>
>> Phil
>>> Romain Manni-Bucau
>>> Twitter: @rmannibucau
>>> Blog: http://rmannibucau.wordpress.com/
>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>> Github: https://github.com/rmannibucau
>>>
>>>
>>>
>>> 2013/11/6 Phil Steitz <ph...@gmail.com>:
>>>> On 11/5/13 11:26 PM, Romain Manni-Bucau wrote:
>>>>> Hehe, right.
>>>>>
>>>>> I looked a bit more today and LongAdder is only a part of the
>>>>> solution. The stat computation still needs to lock to get acces to
>>>>> previous values (N -> N+1). Basically the gain wouldn't be as
>>>>> important as I thought :(.
>>>> Right, but I think your original idea of maintaining a pool of
>>>> instances (fewer that one per thread) to be periodically aggregated
>>>> is a good one. See below.
>>>>> As I said before we'll wait a bit to gather feedbacks, if it blocks
>>>>> I'll come back trying to find + propose a solution.
>>>>>
>>>>> Thanks in all cases for your answers!
>>>> A workaround that I have started playing with (partly for other
>>>> benchmarking reasons) might be to actually use a pool for the stats
>>>> objects that the monitoring threads use. Using a pool would allow
>>>> you to monitor and tune the parameters. We now have (well, once the
>>>> VOTE in progress completes :) a decently performing pool
>>>> implementation. The tricky bit is locking the instances during
>>>> aggregation. One way to handle this would be to have the factory's
>>>> passivate method and the aggregation thread contend for locks on the
>>>> pooled stats instances. The only contention would be when
>>>> aggregation is copying individual instances and contention would be
>>>> with at most one client thread (waiting to proceed in passivate).
>>>>
>>>> Phil
>>>>> Romain Manni-Bucau
>>>>> Twitter: @rmannibucau
>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>> Github: https://github.com/rmannibucau
>>>>>
>>>>>
>>>>>
>>>>> 2013/11/5 Phil Steitz <ph...@gmail.com>:
>>>>>> On 11/5/13 9:57 AM, Romain Manni-Bucau wrote:
>>>>>>> @Phil: hmm can be but the framework would create its own overhead which
>>>>>>> would be avoided with a dedicated solution, no? Well thought gain was great
>>>>>>> for small investment but ok to postpone it
>>>>>> As I said, patches welcome. Go for it. My point about the
>>>>>> framework was that when you actually get this implemented inside,
>>>>>> e.g. SummaryStatistics, you will have built a mini-framework.
>>>>>> Whatever overhead it has, it will have ;)
>>>>>>
>>>>>>
>>>>>> Phil
>>>>>>
>>>>>>
>>>>>>> Le 5 nov. 2013 18:54, "Romain Manni-Bucau" <rm...@gmail.com> a écrit :
>>>>>>>
>>>>>>>> Well I didnt test sirona in prod but when using jamon (same kind of
>>>>>>>> framework) locks were creating a serious overhead on some benches. Not the
>>>>>>>> most important but enough to try to solve it.
>>>>>>>>
>>>>>>>> That said we are not yet in 1.0 so Im ok to wait for more serious
>>>>>>>> feedbacks if you think it is better
>>>>>>>> Le 5 nov. 2013 18:48, "Ted Dunning" <te...@gmail.com> a écrit :
>>>>>>>>
>>>>>>>>> On Mon, Nov 4, 2013 at 10:09 PM, Romain Manni-Bucau
>>>>>>>>> <rm...@gmail.com>wrote:
>>>>>>>>>
>>>>>>>>>> Oh sorry, that's what I said early, in a real app no or not enough to
>>>>>>>>> be an
>>>>>>>>>> issue buy on simple apps or very high thrououtput apps yes.
>>>>>>>>>> Le 5 nov. 2013 07:00, "Ted Dunning" <te...@gmail.com> a écrit :
>>>>>>>>>>
>>>>>>>>>>> That isn't what I meant.
>>>>>>>>>>>
>>>>>>>>>>> Do you really think that more than one metric has to update
>>>>>>>>> (increment,
>>>>>>>>>>> say) at precisely the same time?
>>>>>>>>>>>
>>>>>>>>> I realize that is what you said. Do you have any serious examples where
>>>>>>>>> metrics have to be updated all or nothing?
>>>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Multithreaded performances
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Great!
Btw not sure for sirona we oculd use it. One constraint on sirona-core
is to stay self contained. We already shade math3 so shading pool2 too
would start to create a big jar for this need. I'll try to bench
deeper next week too.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2013/11/6 Phil Steitz <ph...@gmail.com>:
> On 11/6/13 8:47 AM, Romain Manni-Bucau wrote:
>> well pool are based on locks so I'm not sure (it would need deep
>> benchs on a real app) it does worth it
>
> Commons pool2 uses pretty lightweight locking and using a pool of
> instances achieves the basic objective of reducing contention for
> the single sync lock on one SummaryStatistics object. I bet it
> would improve throughput over the single-instance approach if
> maxActive, maxIdle were tuned. If I get some time to play with
> this, I will report back with some benchmarks.
>
> Phil
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>>
>>
>>
>> 2013/11/6 Phil Steitz <ph...@gmail.com>:
>>> On 11/5/13 11:26 PM, Romain Manni-Bucau wrote:
>>>> Hehe, right.
>>>>
>>>> I looked a bit more today and LongAdder is only a part of the
>>>> solution. The stat computation still needs to lock to get acces to
>>>> previous values (N -> N+1). Basically the gain wouldn't be as
>>>> important as I thought :(.
>>> Right, but I think your original idea of maintaining a pool of
>>> instances (fewer that one per thread) to be periodically aggregated
>>> is a good one. See below.
>>>> As I said before we'll wait a bit to gather feedbacks, if it blocks
>>>> I'll come back trying to find + propose a solution.
>>>>
>>>> Thanks in all cases for your answers!
>>> A workaround that I have started playing with (partly for other
>>> benchmarking reasons) might be to actually use a pool for the stats
>>> objects that the monitoring threads use. Using a pool would allow
>>> you to monitor and tune the parameters. We now have (well, once the
>>> VOTE in progress completes :) a decently performing pool
>>> implementation. The tricky bit is locking the instances during
>>> aggregation. One way to handle this would be to have the factory's
>>> passivate method and the aggregation thread contend for locks on the
>>> pooled stats instances. The only contention would be when
>>> aggregation is copying individual instances and contention would be
>>> with at most one client thread (waiting to proceed in passivate).
>>>
>>> Phil
>>>> Romain Manni-Bucau
>>>> Twitter: @rmannibucau
>>>> Blog: http://rmannibucau.wordpress.com/
>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>> Github: https://github.com/rmannibucau
>>>>
>>>>
>>>>
>>>> 2013/11/5 Phil Steitz <ph...@gmail.com>:
>>>>> On 11/5/13 9:57 AM, Romain Manni-Bucau wrote:
>>>>>> @Phil: hmm can be but the framework would create its own overhead which
>>>>>> would be avoided with a dedicated solution, no? Well thought gain was great
>>>>>> for small investment but ok to postpone it
>>>>> As I said, patches welcome. Go for it. My point about the
>>>>> framework was that when you actually get this implemented inside,
>>>>> e.g. SummaryStatistics, you will have built a mini-framework.
>>>>> Whatever overhead it has, it will have ;)
>>>>>
>>>>>
>>>>> Phil
>>>>>
>>>>>
>>>>>> Le 5 nov. 2013 18:54, "Romain Manni-Bucau" <rm...@gmail.com> a écrit :
>>>>>>
>>>>>>> Well I didnt test sirona in prod but when using jamon (same kind of
>>>>>>> framework) locks were creating a serious overhead on some benches. Not the
>>>>>>> most important but enough to try to solve it.
>>>>>>>
>>>>>>> That said we are not yet in 1.0 so Im ok to wait for more serious
>>>>>>> feedbacks if you think it is better
>>>>>>> Le 5 nov. 2013 18:48, "Ted Dunning" <te...@gmail.com> a écrit :
>>>>>>>
>>>>>>>> On Mon, Nov 4, 2013 at 10:09 PM, Romain Manni-Bucau
>>>>>>>> <rm...@gmail.com>wrote:
>>>>>>>>
>>>>>>>>> Oh sorry, that's what I said early, in a real app no or not enough to
>>>>>>>> be an
>>>>>>>>> issue buy on simple apps or very high thrououtput apps yes.
>>>>>>>>> Le 5 nov. 2013 07:00, "Ted Dunning" <te...@gmail.com> a écrit :
>>>>>>>>>
>>>>>>>>>> That isn't what I meant.
>>>>>>>>>>
>>>>>>>>>> Do you really think that more than one metric has to update
>>>>>>>> (increment,
>>>>>>>>>> say) at precisely the same time?
>>>>>>>>>>
>>>>>>>> I realize that is what you said. Do you have any serious examples where
>>>>>>>> metrics have to be updated all or nothing?
>>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
>
> ---------------------------------------------------------------------
> 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
Re: [math] Multithreaded performances
Posted by Phil Steitz <ph...@gmail.com>.
On 11/6/13 8:47 AM, Romain Manni-Bucau wrote:
> well pool are based on locks so I'm not sure (it would need deep
> benchs on a real app) it does worth it
Commons pool2 uses pretty lightweight locking and using a pool of
instances achieves the basic objective of reducing contention for
the single sync lock on one SummaryStatistics object. I bet it
would improve throughput over the single-instance approach if
maxActive, maxIdle were tuned. If I get some time to play with
this, I will report back with some benchmarks.
Phil
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2013/11/6 Phil Steitz <ph...@gmail.com>:
>> On 11/5/13 11:26 PM, Romain Manni-Bucau wrote:
>>> Hehe, right.
>>>
>>> I looked a bit more today and LongAdder is only a part of the
>>> solution. The stat computation still needs to lock to get acces to
>>> previous values (N -> N+1). Basically the gain wouldn't be as
>>> important as I thought :(.
>> Right, but I think your original idea of maintaining a pool of
>> instances (fewer that one per thread) to be periodically aggregated
>> is a good one. See below.
>>> As I said before we'll wait a bit to gather feedbacks, if it blocks
>>> I'll come back trying to find + propose a solution.
>>>
>>> Thanks in all cases for your answers!
>> A workaround that I have started playing with (partly for other
>> benchmarking reasons) might be to actually use a pool for the stats
>> objects that the monitoring threads use. Using a pool would allow
>> you to monitor and tune the parameters. We now have (well, once the
>> VOTE in progress completes :) a decently performing pool
>> implementation. The tricky bit is locking the instances during
>> aggregation. One way to handle this would be to have the factory's
>> passivate method and the aggregation thread contend for locks on the
>> pooled stats instances. The only contention would be when
>> aggregation is copying individual instances and contention would be
>> with at most one client thread (waiting to proceed in passivate).
>>
>> Phil
>>> Romain Manni-Bucau
>>> Twitter: @rmannibucau
>>> Blog: http://rmannibucau.wordpress.com/
>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>> Github: https://github.com/rmannibucau
>>>
>>>
>>>
>>> 2013/11/5 Phil Steitz <ph...@gmail.com>:
>>>> On 11/5/13 9:57 AM, Romain Manni-Bucau wrote:
>>>>> @Phil: hmm can be but the framework would create its own overhead which
>>>>> would be avoided with a dedicated solution, no? Well thought gain was great
>>>>> for small investment but ok to postpone it
>>>> As I said, patches welcome. Go for it. My point about the
>>>> framework was that when you actually get this implemented inside,
>>>> e.g. SummaryStatistics, you will have built a mini-framework.
>>>> Whatever overhead it has, it will have ;)
>>>>
>>>>
>>>> Phil
>>>>
>>>>
>>>>> Le 5 nov. 2013 18:54, "Romain Manni-Bucau" <rm...@gmail.com> a écrit :
>>>>>
>>>>>> Well I didnt test sirona in prod but when using jamon (same kind of
>>>>>> framework) locks were creating a serious overhead on some benches. Not the
>>>>>> most important but enough to try to solve it.
>>>>>>
>>>>>> That said we are not yet in 1.0 so Im ok to wait for more serious
>>>>>> feedbacks if you think it is better
>>>>>> Le 5 nov. 2013 18:48, "Ted Dunning" <te...@gmail.com> a écrit :
>>>>>>
>>>>>>> On Mon, Nov 4, 2013 at 10:09 PM, Romain Manni-Bucau
>>>>>>> <rm...@gmail.com>wrote:
>>>>>>>
>>>>>>>> Oh sorry, that's what I said early, in a real app no or not enough to
>>>>>>> be an
>>>>>>>> issue buy on simple apps or very high thrououtput apps yes.
>>>>>>>> Le 5 nov. 2013 07:00, "Ted Dunning" <te...@gmail.com> a écrit :
>>>>>>>>
>>>>>>>>> That isn't what I meant.
>>>>>>>>>
>>>>>>>>> Do you really think that more than one metric has to update
>>>>>>> (increment,
>>>>>>>>> say) at precisely the same time?
>>>>>>>>>
>>>>>>> I realize that is what you said. Do you have any serious examples where
>>>>>>> metrics have to be updated all or nothing?
>>>>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Multithreaded performances
Posted by Romain Manni-Bucau <rm...@gmail.com>.
well pool are based on locks so I'm not sure (it would need deep
benchs on a real app) it does worth it
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2013/11/6 Phil Steitz <ph...@gmail.com>:
> On 11/5/13 11:26 PM, Romain Manni-Bucau wrote:
>> Hehe, right.
>>
>> I looked a bit more today and LongAdder is only a part of the
>> solution. The stat computation still needs to lock to get acces to
>> previous values (N -> N+1). Basically the gain wouldn't be as
>> important as I thought :(.
>
> Right, but I think your original idea of maintaining a pool of
> instances (fewer that one per thread) to be periodically aggregated
> is a good one. See below.
>>
>> As I said before we'll wait a bit to gather feedbacks, if it blocks
>> I'll come back trying to find + propose a solution.
>>
>> Thanks in all cases for your answers!
>
> A workaround that I have started playing with (partly for other
> benchmarking reasons) might be to actually use a pool for the stats
> objects that the monitoring threads use. Using a pool would allow
> you to monitor and tune the parameters. We now have (well, once the
> VOTE in progress completes :) a decently performing pool
> implementation. The tricky bit is locking the instances during
> aggregation. One way to handle this would be to have the factory's
> passivate method and the aggregation thread contend for locks on the
> pooled stats instances. The only contention would be when
> aggregation is copying individual instances and contention would be
> with at most one client thread (waiting to proceed in passivate).
>
> Phil
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>>
>>
>>
>> 2013/11/5 Phil Steitz <ph...@gmail.com>:
>>> On 11/5/13 9:57 AM, Romain Manni-Bucau wrote:
>>>> @Phil: hmm can be but the framework would create its own overhead which
>>>> would be avoided with a dedicated solution, no? Well thought gain was great
>>>> for small investment but ok to postpone it
>>> As I said, patches welcome. Go for it. My point about the
>>> framework was that when you actually get this implemented inside,
>>> e.g. SummaryStatistics, you will have built a mini-framework.
>>> Whatever overhead it has, it will have ;)
>>>
>>>
>>> Phil
>>>
>>>
>>>> Le 5 nov. 2013 18:54, "Romain Manni-Bucau" <rm...@gmail.com> a écrit :
>>>>
>>>>> Well I didnt test sirona in prod but when using jamon (same kind of
>>>>> framework) locks were creating a serious overhead on some benches. Not the
>>>>> most important but enough to try to solve it.
>>>>>
>>>>> That said we are not yet in 1.0 so Im ok to wait for more serious
>>>>> feedbacks if you think it is better
>>>>> Le 5 nov. 2013 18:48, "Ted Dunning" <te...@gmail.com> a écrit :
>>>>>
>>>>>> On Mon, Nov 4, 2013 at 10:09 PM, Romain Manni-Bucau
>>>>>> <rm...@gmail.com>wrote:
>>>>>>
>>>>>>> Oh sorry, that's what I said early, in a real app no or not enough to
>>>>>> be an
>>>>>>> issue buy on simple apps or very high thrououtput apps yes.
>>>>>>> Le 5 nov. 2013 07:00, "Ted Dunning" <te...@gmail.com> a écrit :
>>>>>>>
>>>>>>>> That isn't what I meant.
>>>>>>>>
>>>>>>>> Do you really think that more than one metric has to update
>>>>>> (increment,
>>>>>>>> say) at precisely the same time?
>>>>>>>>
>>>>>> I realize that is what you said. Do you have any serious examples where
>>>>>> metrics have to be updated all or nothing?
>>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
>
> ---------------------------------------------------------------------
> 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
Re: [math] Multithreaded performances
Posted by Phil Steitz <ph...@gmail.com>.
On 11/5/13 11:26 PM, Romain Manni-Bucau wrote:
> Hehe, right.
>
> I looked a bit more today and LongAdder is only a part of the
> solution. The stat computation still needs to lock to get acces to
> previous values (N -> N+1). Basically the gain wouldn't be as
> important as I thought :(.
Right, but I think your original idea of maintaining a pool of
instances (fewer that one per thread) to be periodically aggregated
is a good one. See below.
>
> As I said before we'll wait a bit to gather feedbacks, if it blocks
> I'll come back trying to find + propose a solution.
>
> Thanks in all cases for your answers!
A workaround that I have started playing with (partly for other
benchmarking reasons) might be to actually use a pool for the stats
objects that the monitoring threads use. Using a pool would allow
you to monitor and tune the parameters. We now have (well, once the
VOTE in progress completes :) a decently performing pool
implementation. The tricky bit is locking the instances during
aggregation. One way to handle this would be to have the factory's
passivate method and the aggregation thread contend for locks on the
pooled stats instances. The only contention would be when
aggregation is copying individual instances and contention would be
with at most one client thread (waiting to proceed in passivate).
Phil
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2013/11/5 Phil Steitz <ph...@gmail.com>:
>> On 11/5/13 9:57 AM, Romain Manni-Bucau wrote:
>>> @Phil: hmm can be but the framework would create its own overhead which
>>> would be avoided with a dedicated solution, no? Well thought gain was great
>>> for small investment but ok to postpone it
>> As I said, patches welcome. Go for it. My point about the
>> framework was that when you actually get this implemented inside,
>> e.g. SummaryStatistics, you will have built a mini-framework.
>> Whatever overhead it has, it will have ;)
>>
>>
>> Phil
>>
>>
>>> Le 5 nov. 2013 18:54, "Romain Manni-Bucau" <rm...@gmail.com> a écrit :
>>>
>>>> Well I didnt test sirona in prod but when using jamon (same kind of
>>>> framework) locks were creating a serious overhead on some benches. Not the
>>>> most important but enough to try to solve it.
>>>>
>>>> That said we are not yet in 1.0 so Im ok to wait for more serious
>>>> feedbacks if you think it is better
>>>> Le 5 nov. 2013 18:48, "Ted Dunning" <te...@gmail.com> a écrit :
>>>>
>>>>> On Mon, Nov 4, 2013 at 10:09 PM, Romain Manni-Bucau
>>>>> <rm...@gmail.com>wrote:
>>>>>
>>>>>> Oh sorry, that's what I said early, in a real app no or not enough to
>>>>> be an
>>>>>> issue buy on simple apps or very high thrououtput apps yes.
>>>>>> Le 5 nov. 2013 07:00, "Ted Dunning" <te...@gmail.com> a écrit :
>>>>>>
>>>>>>> That isn't what I meant.
>>>>>>>
>>>>>>> Do you really think that more than one metric has to update
>>>>> (increment,
>>>>>>> say) at precisely the same time?
>>>>>>>
>>>>> I realize that is what you said. Do you have any serious examples where
>>>>> metrics have to be updated all or nothing?
>>>>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Multithreaded performances
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hehe, right.
I looked a bit more today and LongAdder is only a part of the
solution. The stat computation still needs to lock to get acces to
previous values (N -> N+1). Basically the gain wouldn't be as
important as I thought :(.
As I said before we'll wait a bit to gather feedbacks, if it blocks
I'll come back trying to find + propose a solution.
Thanks in all cases for your answers!
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2013/11/5 Phil Steitz <ph...@gmail.com>:
> On 11/5/13 9:57 AM, Romain Manni-Bucau wrote:
>> @Phil: hmm can be but the framework would create its own overhead which
>> would be avoided with a dedicated solution, no? Well thought gain was great
>> for small investment but ok to postpone it
>
> As I said, patches welcome. Go for it. My point about the
> framework was that when you actually get this implemented inside,
> e.g. SummaryStatistics, you will have built a mini-framework.
> Whatever overhead it has, it will have ;)
>
>
> Phil
>
>
>> Le 5 nov. 2013 18:54, "Romain Manni-Bucau" <rm...@gmail.com> a écrit :
>>
>>> Well I didnt test sirona in prod but when using jamon (same kind of
>>> framework) locks were creating a serious overhead on some benches. Not the
>>> most important but enough to try to solve it.
>>>
>>> That said we are not yet in 1.0 so Im ok to wait for more serious
>>> feedbacks if you think it is better
>>> Le 5 nov. 2013 18:48, "Ted Dunning" <te...@gmail.com> a écrit :
>>>
>>>> On Mon, Nov 4, 2013 at 10:09 PM, Romain Manni-Bucau
>>>> <rm...@gmail.com>wrote:
>>>>
>>>>> Oh sorry, that's what I said early, in a real app no or not enough to
>>>> be an
>>>>> issue buy on simple apps or very high thrououtput apps yes.
>>>>> Le 5 nov. 2013 07:00, "Ted Dunning" <te...@gmail.com> a écrit :
>>>>>
>>>>>> That isn't what I meant.
>>>>>>
>>>>>> Do you really think that more than one metric has to update
>>>> (increment,
>>>>>> say) at precisely the same time?
>>>>>>
>>>> I realize that is what you said. Do you have any serious examples where
>>>> metrics have to be updated all or nothing?
>>>>
>
>
> ---------------------------------------------------------------------
> 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
Re: [math] Multithreaded performances
Posted by Phil Steitz <ph...@gmail.com>.
On 11/5/13 9:57 AM, Romain Manni-Bucau wrote:
> @Phil: hmm can be but the framework would create its own overhead which
> would be avoided with a dedicated solution, no? Well thought gain was great
> for small investment but ok to postpone it
As I said, patches welcome. Go for it. My point about the
framework was that when you actually get this implemented inside,
e.g. SummaryStatistics, you will have built a mini-framework.
Whatever overhead it has, it will have ;)
Phil
> Le 5 nov. 2013 18:54, "Romain Manni-Bucau" <rm...@gmail.com> a écrit :
>
>> Well I didnt test sirona in prod but when using jamon (same kind of
>> framework) locks were creating a serious overhead on some benches. Not the
>> most important but enough to try to solve it.
>>
>> That said we are not yet in 1.0 so Im ok to wait for more serious
>> feedbacks if you think it is better
>> Le 5 nov. 2013 18:48, "Ted Dunning" <te...@gmail.com> a écrit :
>>
>>> On Mon, Nov 4, 2013 at 10:09 PM, Romain Manni-Bucau
>>> <rm...@gmail.com>wrote:
>>>
>>>> Oh sorry, that's what I said early, in a real app no or not enough to
>>> be an
>>>> issue buy on simple apps or very high thrououtput apps yes.
>>>> Le 5 nov. 2013 07:00, "Ted Dunning" <te...@gmail.com> a écrit :
>>>>
>>>>> That isn't what I meant.
>>>>>
>>>>> Do you really think that more than one metric has to update
>>> (increment,
>>>>> say) at precisely the same time?
>>>>>
>>> I realize that is what you said. Do you have any serious examples where
>>> metrics have to be updated all or nothing?
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Multithreaded performances
Posted by Romain Manni-Bucau <rm...@gmail.com>.
@Phil: hmm can be but the framework would create its own overhead which
would be avoided with a dedicated solution, no? Well thought gain was great
for small investment but ok to postpone it
Le 5 nov. 2013 18:54, "Romain Manni-Bucau" <rm...@gmail.com> a écrit :
> Well I didnt test sirona in prod but when using jamon (same kind of
> framework) locks were creating a serious overhead on some benches. Not the
> most important but enough to try to solve it.
>
> That said we are not yet in 1.0 so Im ok to wait for more serious
> feedbacks if you think it is better
> Le 5 nov. 2013 18:48, "Ted Dunning" <te...@gmail.com> a écrit :
>
>> On Mon, Nov 4, 2013 at 10:09 PM, Romain Manni-Bucau
>> <rm...@gmail.com>wrote:
>>
>> > Oh sorry, that's what I said early, in a real app no or not enough to
>> be an
>> > issue buy on simple apps or very high thrououtput apps yes.
>> > Le 5 nov. 2013 07:00, "Ted Dunning" <te...@gmail.com> a écrit :
>> >
>> > > That isn't what I meant.
>> > >
>> > > Do you really think that more than one metric has to update
>> (increment,
>> > > say) at precisely the same time?
>> > >
>> >
>>
>> I realize that is what you said. Do you have any serious examples where
>> metrics have to be updated all or nothing?
>>
>
Re: [math] Multithreaded performances
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Well I didnt test sirona in prod but when using jamon (same kind of
framework) locks were creating a serious overhead on some benches. Not the
most important but enough to try to solve it.
That said we are not yet in 1.0 so Im ok to wait for more serious feedbacks
if you think it is better
Le 5 nov. 2013 18:48, "Ted Dunning" <te...@gmail.com> a écrit :
> On Mon, Nov 4, 2013 at 10:09 PM, Romain Manni-Bucau
> <rm...@gmail.com>wrote:
>
> > Oh sorry, that's what I said early, in a real app no or not enough to be
> an
> > issue buy on simple apps or very high thrououtput apps yes.
> > Le 5 nov. 2013 07:00, "Ted Dunning" <te...@gmail.com> a écrit :
> >
> > > That isn't what I meant.
> > >
> > > Do you really think that more than one metric has to update (increment,
> > > say) at precisely the same time?
> > >
> >
>
> I realize that is what you said. Do you have any serious examples where
> metrics have to be updated all or nothing?
>
Re: [math] Multithreaded performances
Posted by Ted Dunning <te...@gmail.com>.
On Mon, Nov 4, 2013 at 10:09 PM, Romain Manni-Bucau
<rm...@gmail.com>wrote:
> Oh sorry, that's what I said early, in a real app no or not enough to be an
> issue buy on simple apps or very high thrououtput apps yes.
> Le 5 nov. 2013 07:00, "Ted Dunning" <te...@gmail.com> a écrit :
>
> > That isn't what I meant.
> >
> > Do you really think that more than one metric has to update (increment,
> > say) at precisely the same time?
> >
>
I realize that is what you said. Do you have any serious examples where
metrics have to be updated all or nothing?
Re: [math] Multithreaded performances
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Oh sorry, that's what I said early, in a real app no or not enough to be an
issue buy on simple apps or very high thrououtput apps yes.
Le 5 nov. 2013 07:00, "Ted Dunning" <te...@gmail.com> a écrit :
> That isn't what I meant.
>
> Do you really think that more than one metric has to update (increment,
> say) at precisely the same time?
>
>
> On Mon, Nov 4, 2013 at 9:49 PM, Romain Manni-Bucau <rmannibucau@gmail.com
> >wrote:
>
> > You cant stop the app cause you take a snapshot of the monitoring metrics
> > so yes
> > Le 5 nov. 2013 06:46, "Ted Dunning" <te...@gmail.com> a écrit :
> >
> > > On Mon, Nov 4, 2013 at 8:23 PM, Phil Steitz <ph...@gmail.com>
> > wrote:
> > >
> > > > On 11/4/13 3:44 PM, Ted Dunning wrote:
> > > > > The copy doesn't have to lock if you build the right data
> structure.
> > > >
> > > > The individual stats objects need to update multiple quantities
> > > > atomically when new values come in. Consistency in the copy
> > > > requires that you suppress updates while the copy is in progress
> > > > unless you implement some kind of update queue internally. What
> > > > exactly do you mean by "the right data structure?"
> > > >
> > >
> > > I was talking about lockless data structures in general.
> > >
> > > Are you sure that real transactions are a requirement here?
> > >
> >
>
Re: [math] Multithreaded performances
Posted by Phil Steitz <ph...@gmail.com>.
On 11/4/13 9:59 PM, Ted Dunning wrote:
> That isn't what I meant.
>
> Do you really think that more than one metric has to update (increment,
> say) at precisely the same time?
Yes, that is the problem. For consistency, you need multiple
quantities atomically updated for any of the moment-based stats.
The sum or count requires just one; but in general you need more
than one. Also, obviously if what you are interested is a
consistent statistical summary (like one of the aggregates
provides), you need to update all the different stats atomically.
I like the LongAddr idea; but to generalize it you basically end up
creating a mini M/R framework inside one of the statistical
aggregates. Could be done, I guess, but I wonder if what is being
built in this case is a more general execution framework for
concurrent update of aggregation-friendly objects.
Phil
>
>
> On Mon, Nov 4, 2013 at 9:49 PM, Romain Manni-Bucau <rm...@gmail.com>wrote:
>
>> You cant stop the app cause you take a snapshot of the monitoring metrics
>> so yes
>> Le 5 nov. 2013 06:46, "Ted Dunning" <te...@gmail.com> a écrit :
>>
>>> On Mon, Nov 4, 2013 at 8:23 PM, Phil Steitz <ph...@gmail.com>
>> wrote:
>>>> On 11/4/13 3:44 PM, Ted Dunning wrote:
>>>>> The copy doesn't have to lock if you build the right data structure.
>>>> The individual stats objects need to update multiple quantities
>>>> atomically when new values come in. Consistency in the copy
>>>> requires that you suppress updates while the copy is in progress
>>>> unless you implement some kind of update queue internally. What
>>>> exactly do you mean by "the right data structure?"
>>>>
>>> I was talking about lockless data structures in general.
>>>
>>> Are you sure that real transactions are a requirement here?
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Multithreaded performances
Posted by Ted Dunning <te...@gmail.com>.
That isn't what I meant.
Do you really think that more than one metric has to update (increment,
say) at precisely the same time?
On Mon, Nov 4, 2013 at 9:49 PM, Romain Manni-Bucau <rm...@gmail.com>wrote:
> You cant stop the app cause you take a snapshot of the monitoring metrics
> so yes
> Le 5 nov. 2013 06:46, "Ted Dunning" <te...@gmail.com> a écrit :
>
> > On Mon, Nov 4, 2013 at 8:23 PM, Phil Steitz <ph...@gmail.com>
> wrote:
> >
> > > On 11/4/13 3:44 PM, Ted Dunning wrote:
> > > > The copy doesn't have to lock if you build the right data structure.
> > >
> > > The individual stats objects need to update multiple quantities
> > > atomically when new values come in. Consistency in the copy
> > > requires that you suppress updates while the copy is in progress
> > > unless you implement some kind of update queue internally. What
> > > exactly do you mean by "the right data structure?"
> > >
> >
> > I was talking about lockless data structures in general.
> >
> > Are you sure that real transactions are a requirement here?
> >
>
Re: [math] Multithreaded performances
Posted by Romain Manni-Bucau <rm...@gmail.com>.
You cant stop the app cause you take a snapshot of the monitoring metrics
so yes
Le 5 nov. 2013 06:46, "Ted Dunning" <te...@gmail.com> a écrit :
> On Mon, Nov 4, 2013 at 8:23 PM, Phil Steitz <ph...@gmail.com> wrote:
>
> > On 11/4/13 3:44 PM, Ted Dunning wrote:
> > > The copy doesn't have to lock if you build the right data structure.
> >
> > The individual stats objects need to update multiple quantities
> > atomically when new values come in. Consistency in the copy
> > requires that you suppress updates while the copy is in progress
> > unless you implement some kind of update queue internally. What
> > exactly do you mean by "the right data structure?"
> >
>
> I was talking about lockless data structures in general.
>
> Are you sure that real transactions are a requirement here?
>
Re: [math] Multithreaded performances
Posted by Ted Dunning <te...@gmail.com>.
On Mon, Nov 4, 2013 at 8:23 PM, Phil Steitz <ph...@gmail.com> wrote:
> On 11/4/13 3:44 PM, Ted Dunning wrote:
> > The copy doesn't have to lock if you build the right data structure.
>
> The individual stats objects need to update multiple quantities
> atomically when new values come in. Consistency in the copy
> requires that you suppress updates while the copy is in progress
> unless you implement some kind of update queue internally. What
> exactly do you mean by "the right data structure?"
>
I was talking about lockless data structures in general.
Are you sure that real transactions are a requirement here?
Re: [math] Multithreaded performances
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Well before patching a consistent solution needs to be found.
Sorry to go back to LongAdder but the idea is to add instances but not as
much as thread. Just what is needed. It means you decrease the number of
instance to aggregate so the lock time.
The queue solution sounds worse since a queue is either empty or full ;)
Le 5 nov. 2013 05:23, "Phil Steitz" <ph...@gmail.com> a écrit :
> On 11/4/13 3:44 PM, Ted Dunning wrote:
> > The copy doesn't have to lock if you build the right data structure.
>
> The individual stats objects need to update multiple quantities
> atomically when new values come in. Consistency in the copy
> requires that you suppress updates while the copy is in progress
> unless you implement some kind of update queue internally. What
> exactly do you mean by "the right data structure?"
>
> This discussion is bringing me back to the view that we had before
> we did anything to support synchronization - clients are better
> situated to manage the supporting infrastructure. As long as we
> support aggregation, clients should be able to do what they need to do.
>
> If the use case here, for example, is that lots of client threads
> need to contribute to aggregate stats and you can't pause any of
> them ever to aggregate, there is no free lunch, you are going to
> have to queue somewhere. The primitive solution of queuing on the
> sync lock for a single stats object is heavy and bad. Trying to
> build more lightweight queueing into the stat object itself is
> interesting, but I wonder if there is other stuff from these threads
> that should also be queued, or in general there is always going to
> be stuff about the application's execution environment unknown to us
> that make whatever we do less than optimal.
>
> All that said, patches welcome for lighter weight locking or
> explicit update queue management inside the stats objects.
>
> Phil
> >
> > The thread leak problem can be more serious.
> >
> >
> >
> >
> > On Mon, Nov 4, 2013 at 2:47 PM, Phil Steitz <ph...@gmail.com>
> wrote:
> >
> >> On 11/4/13 2:31 PM, Romain Manni-Bucau wrote:
> >>> The copy will lock too.
> >> Right. That is why I asked exactly how things work. If you can't
> >> lock during aggregation, we need something different.
> >>
> >>> And it doesnt solve leak issue of the one instance
> >>> by thread solution, no?
> >> Correct, again depends on the setup how big a problem that is / what
> >> can be done to manage it.
> >>
> >> Phil
> >>> Le 4 nov. 2013 23:27, "Phil Steitz" <ph...@gmail.com> a écrit :
> >>>
> >>>> On 11/4/13 2:22 PM, Ted Dunning wrote:
> >>>>> I still think that what you need is a thread-safe copy rather than a
> >>>>> thread-safe mutate.
> >>>> I was just thinking the same thing. Patches welcome.
> >>>>
> >>>> Phil
> >>>>> Even if you force every thread to do the copy, the
> >>>>> aggregation still still wins on complexity/correctness/performance
> >> ideas.
> >>>>>
> >>>>> On Mon, Nov 4, 2013 at 12:58 PM, Romain Manni-Bucau
> >>>>> <rm...@gmail.com>wrote:
> >>>>>
> >>>>>> In sirona we collect (aggregate) data each N ms and we can still use
> >>>> stats
> >>>>>> during aggregation (worse case surely)
> >>>>>> Le 4 nov. 2013 21:48, "Phil Steitz" <ph...@gmail.com> a
> écrit :
> >>>>>>
> >>>>>>> On 11/4/13 12:12 PM, Romain Manni-Bucau wrote:
> >>>>>>>> But aggregation needs to lock so not a real solution. Lock is fine
> >> on
> >>>>>>> real
> >>>>>>>> cases but not in simple/light ones. ThreadLocal leaks...so a trade
> >> off
> >>>>>>>> should be found
> >>>>>>> Depends on the use case. If the use case is
> >>>>>>>
> >>>>>>> 0) launch a bunch of threads and let them gather stats individually
> >>>>>>> 1) aggregate results
> >>>>>>>
> >>>>>>> Then the static aggregate method in AggregateSummaryStatistics that
> >>>>>>> takes a collection as input will work with no locking required.
> >>>>>>>
> >>>>>>> Phil
> >>>>>>>> Le 4 nov. 2013 18:42, "Phil Steitz" <ph...@gmail.com> a
> >> écrit :
> >>>>>>>>> On 11/4/13 8:49 AM, Romain Manni-Bucau wrote:
> >>>>>>>>>> Hi,
> >>>>>>>>>>
> >>>>>>>>>> ATM sirona (a java monitoring library in incubator) relies a lot
> >> on
> >>>>>>>>>> Summary stats object from [math3] but it needed a lock to ensure
> >>>>>>>>>> consistency. I know there is a synchronized version but this one
> >>>>>>>>>> scales less then the locked one.
> >>>>>>>>>>
> >>>>>>>>>> My question is quite simple then: will [math] add an
> >> implementation
> >>>>>>>>>> with thread safety guarantee and good performances? I think for
> >>>>>>>>>> instance to the LongAdder of Doug Lea which could be used as a
> >> good
> >>>>>>>>>> base.
> >>>>>>>>> The short answer is yes, patches welcome.
> >>>>>>>>>
> >>>>>>>>> Ted makes a good point, though; and there is already some support
> >>>>>>>>> for aggregation in the stats classes in [math] (i.e., you can
> >>>>>>>>> aggregate the results of per-thread stats by using, e.g.
> >>>>>>>>> AggregateSummaryStatistics#aggregate). See MATH-1016 re
> extending
> >>>>>>>>> this to more stats.
> >>>>>>>>>
> >>>>>>>>> Phil
> >>>>>>>>>
> >>>>>>>>>> Romain Manni-Bucau
> >>>>>>>>>> Twitter: @rmannibucau
> >>>>>>>>>> Blog: http://rmannibucau.wordpress.com/
> >>>>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >>>>>>>>>> Github: https://github.com/rmannibucau
> >>>>>>>>>>
> >>>>>>>>>>
> >>>> ---------------------------------------------------------------------
> >>>>>>>>>> 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
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>> 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
> >>>>
> >>>>
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
>
Re: [math] Multithreaded performances
Posted by Phil Steitz <ph...@gmail.com>.
On 11/4/13 3:44 PM, Ted Dunning wrote:
> The copy doesn't have to lock if you build the right data structure.
The individual stats objects need to update multiple quantities
atomically when new values come in. Consistency in the copy
requires that you suppress updates while the copy is in progress
unless you implement some kind of update queue internally. What
exactly do you mean by "the right data structure?"
This discussion is bringing me back to the view that we had before
we did anything to support synchronization - clients are better
situated to manage the supporting infrastructure. As long as we
support aggregation, clients should be able to do what they need to do.
If the use case here, for example, is that lots of client threads
need to contribute to aggregate stats and you can't pause any of
them ever to aggregate, there is no free lunch, you are going to
have to queue somewhere. The primitive solution of queuing on the
sync lock for a single stats object is heavy and bad. Trying to
build more lightweight queueing into the stat object itself is
interesting, but I wonder if there is other stuff from these threads
that should also be queued, or in general there is always going to
be stuff about the application's execution environment unknown to us
that make whatever we do less than optimal.
All that said, patches welcome for lighter weight locking or
explicit update queue management inside the stats objects.
Phil
>
> The thread leak problem can be more serious.
>
>
>
>
> On Mon, Nov 4, 2013 at 2:47 PM, Phil Steitz <ph...@gmail.com> wrote:
>
>> On 11/4/13 2:31 PM, Romain Manni-Bucau wrote:
>>> The copy will lock too.
>> Right. That is why I asked exactly how things work. If you can't
>> lock during aggregation, we need something different.
>>
>>> And it doesnt solve leak issue of the one instance
>>> by thread solution, no?
>> Correct, again depends on the setup how big a problem that is / what
>> can be done to manage it.
>>
>> Phil
>>> Le 4 nov. 2013 23:27, "Phil Steitz" <ph...@gmail.com> a écrit :
>>>
>>>> On 11/4/13 2:22 PM, Ted Dunning wrote:
>>>>> I still think that what you need is a thread-safe copy rather than a
>>>>> thread-safe mutate.
>>>> I was just thinking the same thing. Patches welcome.
>>>>
>>>> Phil
>>>>> Even if you force every thread to do the copy, the
>>>>> aggregation still still wins on complexity/correctness/performance
>> ideas.
>>>>>
>>>>> On Mon, Nov 4, 2013 at 12:58 PM, Romain Manni-Bucau
>>>>> <rm...@gmail.com>wrote:
>>>>>
>>>>>> In sirona we collect (aggregate) data each N ms and we can still use
>>>> stats
>>>>>> during aggregation (worse case surely)
>>>>>> Le 4 nov. 2013 21:48, "Phil Steitz" <ph...@gmail.com> a écrit :
>>>>>>
>>>>>>> On 11/4/13 12:12 PM, Romain Manni-Bucau wrote:
>>>>>>>> But aggregation needs to lock so not a real solution. Lock is fine
>> on
>>>>>>> real
>>>>>>>> cases but not in simple/light ones. ThreadLocal leaks...so a trade
>> off
>>>>>>>> should be found
>>>>>>> Depends on the use case. If the use case is
>>>>>>>
>>>>>>> 0) launch a bunch of threads and let them gather stats individually
>>>>>>> 1) aggregate results
>>>>>>>
>>>>>>> Then the static aggregate method in AggregateSummaryStatistics that
>>>>>>> takes a collection as input will work with no locking required.
>>>>>>>
>>>>>>> Phil
>>>>>>>> Le 4 nov. 2013 18:42, "Phil Steitz" <ph...@gmail.com> a
>> écrit :
>>>>>>>>> On 11/4/13 8:49 AM, Romain Manni-Bucau wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> ATM sirona (a java monitoring library in incubator) relies a lot
>> on
>>>>>>>>>> Summary stats object from [math3] but it needed a lock to ensure
>>>>>>>>>> consistency. I know there is a synchronized version but this one
>>>>>>>>>> scales less then the locked one.
>>>>>>>>>>
>>>>>>>>>> My question is quite simple then: will [math] add an
>> implementation
>>>>>>>>>> with thread safety guarantee and good performances? I think for
>>>>>>>>>> instance to the LongAdder of Doug Lea which could be used as a
>> good
>>>>>>>>>> base.
>>>>>>>>> The short answer is yes, patches welcome.
>>>>>>>>>
>>>>>>>>> Ted makes a good point, though; and there is already some support
>>>>>>>>> for aggregation in the stats classes in [math] (i.e., you can
>>>>>>>>> aggregate the results of per-thread stats by using, e.g.
>>>>>>>>> AggregateSummaryStatistics#aggregate). See MATH-1016 re extending
>>>>>>>>> this to more stats.
>>>>>>>>>
>>>>>>>>> Phil
>>>>>>>>>
>>>>>>>>>> Romain Manni-Bucau
>>>>>>>>>> Twitter: @rmannibucau
>>>>>>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>>>>>>> Github: https://github.com/rmannibucau
>>>>>>>>>>
>>>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> 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
Re: [math] Multithreaded performances
Posted by Ted Dunning <te...@gmail.com>.
The copy doesn't have to lock if you build the right data structure.
The thread leak problem can be more serious.
On Mon, Nov 4, 2013 at 2:47 PM, Phil Steitz <ph...@gmail.com> wrote:
> On 11/4/13 2:31 PM, Romain Manni-Bucau wrote:
> > The copy will lock too.
>
> Right. That is why I asked exactly how things work. If you can't
> lock during aggregation, we need something different.
>
> > And it doesnt solve leak issue of the one instance
> > by thread solution, no?
>
> Correct, again depends on the setup how big a problem that is / what
> can be done to manage it.
>
> Phil
> > Le 4 nov. 2013 23:27, "Phil Steitz" <ph...@gmail.com> a écrit :
> >
> >> On 11/4/13 2:22 PM, Ted Dunning wrote:
> >>> I still think that what you need is a thread-safe copy rather than a
> >>> thread-safe mutate.
> >> I was just thinking the same thing. Patches welcome.
> >>
> >> Phil
> >>> Even if you force every thread to do the copy, the
> >>> aggregation still still wins on complexity/correctness/performance
> ideas.
> >>>
> >>>
> >>> On Mon, Nov 4, 2013 at 12:58 PM, Romain Manni-Bucau
> >>> <rm...@gmail.com>wrote:
> >>>
> >>>> In sirona we collect (aggregate) data each N ms and we can still use
> >> stats
> >>>> during aggregation (worse case surely)
> >>>> Le 4 nov. 2013 21:48, "Phil Steitz" <ph...@gmail.com> a écrit :
> >>>>
> >>>>> On 11/4/13 12:12 PM, Romain Manni-Bucau wrote:
> >>>>>> But aggregation needs to lock so not a real solution. Lock is fine
> on
> >>>>> real
> >>>>>> cases but not in simple/light ones. ThreadLocal leaks...so a trade
> off
> >>>>>> should be found
> >>>>> Depends on the use case. If the use case is
> >>>>>
> >>>>> 0) launch a bunch of threads and let them gather stats individually
> >>>>> 1) aggregate results
> >>>>>
> >>>>> Then the static aggregate method in AggregateSummaryStatistics that
> >>>>> takes a collection as input will work with no locking required.
> >>>>>
> >>>>> Phil
> >>>>>> Le 4 nov. 2013 18:42, "Phil Steitz" <ph...@gmail.com> a
> écrit :
> >>>>>>
> >>>>>>> On 11/4/13 8:49 AM, Romain Manni-Bucau wrote:
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> ATM sirona (a java monitoring library in incubator) relies a lot
> on
> >>>>>>>> Summary stats object from [math3] but it needed a lock to ensure
> >>>>>>>> consistency. I know there is a synchronized version but this one
> >>>>>>>> scales less then the locked one.
> >>>>>>>>
> >>>>>>>> My question is quite simple then: will [math] add an
> implementation
> >>>>>>>> with thread safety guarantee and good performances? I think for
> >>>>>>>> instance to the LongAdder of Doug Lea which could be used as a
> good
> >>>>>>>> base.
> >>>>>>> The short answer is yes, patches welcome.
> >>>>>>>
> >>>>>>> Ted makes a good point, though; and there is already some support
> >>>>>>> for aggregation in the stats classes in [math] (i.e., you can
> >>>>>>> aggregate the results of per-thread stats by using, e.g.
> >>>>>>> AggregateSummaryStatistics#aggregate). See MATH-1016 re extending
> >>>>>>> this to more stats.
> >>>>>>>
> >>>>>>> Phil
> >>>>>>>
> >>>>>>>> Romain Manni-Bucau
> >>>>>>>> Twitter: @rmannibucau
> >>>>>>>> Blog: http://rmannibucau.wordpress.com/
> >>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >>>>>>>> Github: https://github.com/rmannibucau
> >>>>>>>>
> >>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>> 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
> >>>>>>>
> >>>>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> 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
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [math] Multithreaded performances
Posted by Phil Steitz <ph...@gmail.com>.
On 11/4/13 2:31 PM, Romain Manni-Bucau wrote:
> The copy will lock too.
Right. That is why I asked exactly how things work. If you can't
lock during aggregation, we need something different.
> And it doesnt solve leak issue of the one instance
> by thread solution, no?
Correct, again depends on the setup how big a problem that is / what
can be done to manage it.
Phil
> Le 4 nov. 2013 23:27, "Phil Steitz" <ph...@gmail.com> a écrit :
>
>> On 11/4/13 2:22 PM, Ted Dunning wrote:
>>> I still think that what you need is a thread-safe copy rather than a
>>> thread-safe mutate.
>> I was just thinking the same thing. Patches welcome.
>>
>> Phil
>>> Even if you force every thread to do the copy, the
>>> aggregation still still wins on complexity/correctness/performance ideas.
>>>
>>>
>>> On Mon, Nov 4, 2013 at 12:58 PM, Romain Manni-Bucau
>>> <rm...@gmail.com>wrote:
>>>
>>>> In sirona we collect (aggregate) data each N ms and we can still use
>> stats
>>>> during aggregation (worse case surely)
>>>> Le 4 nov. 2013 21:48, "Phil Steitz" <ph...@gmail.com> a écrit :
>>>>
>>>>> On 11/4/13 12:12 PM, Romain Manni-Bucau wrote:
>>>>>> But aggregation needs to lock so not a real solution. Lock is fine on
>>>>> real
>>>>>> cases but not in simple/light ones. ThreadLocal leaks...so a trade off
>>>>>> should be found
>>>>> Depends on the use case. If the use case is
>>>>>
>>>>> 0) launch a bunch of threads and let them gather stats individually
>>>>> 1) aggregate results
>>>>>
>>>>> Then the static aggregate method in AggregateSummaryStatistics that
>>>>> takes a collection as input will work with no locking required.
>>>>>
>>>>> Phil
>>>>>> Le 4 nov. 2013 18:42, "Phil Steitz" <ph...@gmail.com> a écrit :
>>>>>>
>>>>>>> On 11/4/13 8:49 AM, Romain Manni-Bucau wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> ATM sirona (a java monitoring library in incubator) relies a lot on
>>>>>>>> Summary stats object from [math3] but it needed a lock to ensure
>>>>>>>> consistency. I know there is a synchronized version but this one
>>>>>>>> scales less then the locked one.
>>>>>>>>
>>>>>>>> My question is quite simple then: will [math] add an implementation
>>>>>>>> with thread safety guarantee and good performances? I think for
>>>>>>>> instance to the LongAdder of Doug Lea which could be used as a good
>>>>>>>> base.
>>>>>>> The short answer is yes, patches welcome.
>>>>>>>
>>>>>>> Ted makes a good point, though; and there is already some support
>>>>>>> for aggregation in the stats classes in [math] (i.e., you can
>>>>>>> aggregate the results of per-thread stats by using, e.g.
>>>>>>> AggregateSummaryStatistics#aggregate). See MATH-1016 re extending
>>>>>>> this to more stats.
>>>>>>>
>>>>>>> Phil
>>>>>>>
>>>>>>>> Romain Manni-Bucau
>>>>>>>> Twitter: @rmannibucau
>>>>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>>>>> Github: https://github.com/rmannibucau
>>>>>>>>
>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Multithreaded performances
Posted by Romain Manni-Bucau <rm...@gmail.com>.
The copy will lock too. And it doesnt solve leak issue of the one instance
by thread solution, no?
Le 4 nov. 2013 23:27, "Phil Steitz" <ph...@gmail.com> a écrit :
> On 11/4/13 2:22 PM, Ted Dunning wrote:
> > I still think that what you need is a thread-safe copy rather than a
> > thread-safe mutate.
>
> I was just thinking the same thing. Patches welcome.
>
> Phil
> > Even if you force every thread to do the copy, the
> > aggregation still still wins on complexity/correctness/performance ideas.
> >
> >
> > On Mon, Nov 4, 2013 at 12:58 PM, Romain Manni-Bucau
> > <rm...@gmail.com>wrote:
> >
> >> In sirona we collect (aggregate) data each N ms and we can still use
> stats
> >> during aggregation (worse case surely)
> >> Le 4 nov. 2013 21:48, "Phil Steitz" <ph...@gmail.com> a écrit :
> >>
> >>> On 11/4/13 12:12 PM, Romain Manni-Bucau wrote:
> >>>> But aggregation needs to lock so not a real solution. Lock is fine on
> >>> real
> >>>> cases but not in simple/light ones. ThreadLocal leaks...so a trade off
> >>>> should be found
> >>> Depends on the use case. If the use case is
> >>>
> >>> 0) launch a bunch of threads and let them gather stats individually
> >>> 1) aggregate results
> >>>
> >>> Then the static aggregate method in AggregateSummaryStatistics that
> >>> takes a collection as input will work with no locking required.
> >>>
> >>> Phil
> >>>> Le 4 nov. 2013 18:42, "Phil Steitz" <ph...@gmail.com> a écrit :
> >>>>
> >>>>> On 11/4/13 8:49 AM, Romain Manni-Bucau wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> ATM sirona (a java monitoring library in incubator) relies a lot on
> >>>>>> Summary stats object from [math3] but it needed a lock to ensure
> >>>>>> consistency. I know there is a synchronized version but this one
> >>>>>> scales less then the locked one.
> >>>>>>
> >>>>>> My question is quite simple then: will [math] add an implementation
> >>>>>> with thread safety guarantee and good performances? I think for
> >>>>>> instance to the LongAdder of Doug Lea which could be used as a good
> >>>>>> base.
> >>>>> The short answer is yes, patches welcome.
> >>>>>
> >>>>> Ted makes a good point, though; and there is already some support
> >>>>> for aggregation in the stats classes in [math] (i.e., you can
> >>>>> aggregate the results of per-thread stats by using, e.g.
> >>>>> AggregateSummaryStatistics#aggregate). See MATH-1016 re extending
> >>>>> this to more stats.
> >>>>>
> >>>>> Phil
> >>>>>
> >>>>>> Romain Manni-Bucau
> >>>>>> Twitter: @rmannibucau
> >>>>>> Blog: http://rmannibucau.wordpress.com/
> >>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >>>>>> Github: https://github.com/rmannibucau
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> 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
> >>>>>
> >>>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> 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
>
>
Re: [math] Multithreaded performances
Posted by Phil Steitz <ph...@gmail.com>.
On 11/4/13 2:22 PM, Ted Dunning wrote:
> I still think that what you need is a thread-safe copy rather than a
> thread-safe mutate.
I was just thinking the same thing. Patches welcome.
Phil
> Even if you force every thread to do the copy, the
> aggregation still still wins on complexity/correctness/performance ideas.
>
>
> On Mon, Nov 4, 2013 at 12:58 PM, Romain Manni-Bucau
> <rm...@gmail.com>wrote:
>
>> In sirona we collect (aggregate) data each N ms and we can still use stats
>> during aggregation (worse case surely)
>> Le 4 nov. 2013 21:48, "Phil Steitz" <ph...@gmail.com> a écrit :
>>
>>> On 11/4/13 12:12 PM, Romain Manni-Bucau wrote:
>>>> But aggregation needs to lock so not a real solution. Lock is fine on
>>> real
>>>> cases but not in simple/light ones. ThreadLocal leaks...so a trade off
>>>> should be found
>>> Depends on the use case. If the use case is
>>>
>>> 0) launch a bunch of threads and let them gather stats individually
>>> 1) aggregate results
>>>
>>> Then the static aggregate method in AggregateSummaryStatistics that
>>> takes a collection as input will work with no locking required.
>>>
>>> Phil
>>>> Le 4 nov. 2013 18:42, "Phil Steitz" <ph...@gmail.com> a écrit :
>>>>
>>>>> On 11/4/13 8:49 AM, Romain Manni-Bucau wrote:
>>>>>> Hi,
>>>>>>
>>>>>> ATM sirona (a java monitoring library in incubator) relies a lot on
>>>>>> Summary stats object from [math3] but it needed a lock to ensure
>>>>>> consistency. I know there is a synchronized version but this one
>>>>>> scales less then the locked one.
>>>>>>
>>>>>> My question is quite simple then: will [math] add an implementation
>>>>>> with thread safety guarantee and good performances? I think for
>>>>>> instance to the LongAdder of Doug Lea which could be used as a good
>>>>>> base.
>>>>> The short answer is yes, patches welcome.
>>>>>
>>>>> Ted makes a good point, though; and there is already some support
>>>>> for aggregation in the stats classes in [math] (i.e., you can
>>>>> aggregate the results of per-thread stats by using, e.g.
>>>>> AggregateSummaryStatistics#aggregate). See MATH-1016 re extending
>>>>> this to more stats.
>>>>>
>>>>> Phil
>>>>>
>>>>>> Romain Manni-Bucau
>>>>>> Twitter: @rmannibucau
>>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>>> Github: https://github.com/rmannibucau
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
Re: [math] Multithreaded performances
Posted by Romain Manni-Bucau <rm...@gmail.com>.
A counter has a stat object, then methods are intercepted and duration is
added to the stat object (1 by method). Value is copied each 4s.
Le 4 nov. 2013 23:23, "Ted Dunning" <te...@gmail.com> a écrit :
> I still think that what you need is a thread-safe copy rather than a
> thread-safe mutate. Even if you force every thread to do the copy, the
> aggregation still still wins on complexity/correctness/performance ideas.
>
>
> On Mon, Nov 4, 2013 at 12:58 PM, Romain Manni-Bucau
> <rm...@gmail.com>wrote:
>
> > In sirona we collect (aggregate) data each N ms and we can still use
> stats
> > during aggregation (worse case surely)
> > Le 4 nov. 2013 21:48, "Phil Steitz" <ph...@gmail.com> a écrit :
> >
> > > On 11/4/13 12:12 PM, Romain Manni-Bucau wrote:
> > > > But aggregation needs to lock so not a real solution. Lock is fine on
> > > real
> > > > cases but not in simple/light ones. ThreadLocal leaks...so a trade
> off
> > > > should be found
> > >
> > > Depends on the use case. If the use case is
> > >
> > > 0) launch a bunch of threads and let them gather stats individually
> > > 1) aggregate results
> > >
> > > Then the static aggregate method in AggregateSummaryStatistics that
> > > takes a collection as input will work with no locking required.
> > >
> > > Phil
> > > > Le 4 nov. 2013 18:42, "Phil Steitz" <ph...@gmail.com> a écrit
> :
> > > >
> > > >> On 11/4/13 8:49 AM, Romain Manni-Bucau wrote:
> > > >>> Hi,
> > > >>>
> > > >>> ATM sirona (a java monitoring library in incubator) relies a lot on
> > > >>> Summary stats object from [math3] but it needed a lock to ensure
> > > >>> consistency. I know there is a synchronized version but this one
> > > >>> scales less then the locked one.
> > > >>>
> > > >>> My question is quite simple then: will [math] add an implementation
> > > >>> with thread safety guarantee and good performances? I think for
> > > >>> instance to the LongAdder of Doug Lea which could be used as a good
> > > >>> base.
> > > >> The short answer is yes, patches welcome.
> > > >>
> > > >> Ted makes a good point, though; and there is already some support
> > > >> for aggregation in the stats classes in [math] (i.e., you can
> > > >> aggregate the results of per-thread stats by using, e.g.
> > > >> AggregateSummaryStatistics#aggregate). See MATH-1016 re extending
> > > >> this to more stats.
> > > >>
> > > >> Phil
> > > >>
> > > >>> Romain Manni-Bucau
> > > >>> Twitter: @rmannibucau
> > > >>> Blog: http://rmannibucau.wordpress.com/
> > > >>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > > >>> Github: https://github.com/rmannibucau
> > > >>>
> > > >>>
> ---------------------------------------------------------------------
> > > >>> 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
> > > >>
> > > >>
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
>
Re: [math] Multithreaded performances
Posted by Ted Dunning <te...@gmail.com>.
I still think that what you need is a thread-safe copy rather than a
thread-safe mutate. Even if you force every thread to do the copy, the
aggregation still still wins on complexity/correctness/performance ideas.
On Mon, Nov 4, 2013 at 12:58 PM, Romain Manni-Bucau
<rm...@gmail.com>wrote:
> In sirona we collect (aggregate) data each N ms and we can still use stats
> during aggregation (worse case surely)
> Le 4 nov. 2013 21:48, "Phil Steitz" <ph...@gmail.com> a écrit :
>
> > On 11/4/13 12:12 PM, Romain Manni-Bucau wrote:
> > > But aggregation needs to lock so not a real solution. Lock is fine on
> > real
> > > cases but not in simple/light ones. ThreadLocal leaks...so a trade off
> > > should be found
> >
> > Depends on the use case. If the use case is
> >
> > 0) launch a bunch of threads and let them gather stats individually
> > 1) aggregate results
> >
> > Then the static aggregate method in AggregateSummaryStatistics that
> > takes a collection as input will work with no locking required.
> >
> > Phil
> > > Le 4 nov. 2013 18:42, "Phil Steitz" <ph...@gmail.com> a écrit :
> > >
> > >> On 11/4/13 8:49 AM, Romain Manni-Bucau wrote:
> > >>> Hi,
> > >>>
> > >>> ATM sirona (a java monitoring library in incubator) relies a lot on
> > >>> Summary stats object from [math3] but it needed a lock to ensure
> > >>> consistency. I know there is a synchronized version but this one
> > >>> scales less then the locked one.
> > >>>
> > >>> My question is quite simple then: will [math] add an implementation
> > >>> with thread safety guarantee and good performances? I think for
> > >>> instance to the LongAdder of Doug Lea which could be used as a good
> > >>> base.
> > >> The short answer is yes, patches welcome.
> > >>
> > >> Ted makes a good point, though; and there is already some support
> > >> for aggregation in the stats classes in [math] (i.e., you can
> > >> aggregate the results of per-thread stats by using, e.g.
> > >> AggregateSummaryStatistics#aggregate). See MATH-1016 re extending
> > >> this to more stats.
> > >>
> > >> Phil
> > >>
> > >>> Romain Manni-Bucau
> > >>> Twitter: @rmannibucau
> > >>> Blog: http://rmannibucau.wordpress.com/
> > >>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > >>> Github: https://github.com/rmannibucau
> > >>>
> > >>> ---------------------------------------------------------------------
> > >>> 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
> > >>
> > >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
Re: [math] Multithreaded performances
Posted by Phil Steitz <ph...@gmail.com>.
On 11/4/13 12:58 PM, Romain Manni-Bucau wrote:
> In sirona we collect (aggregate) data each N ms and we can still use stats
> during aggregation (worse case surely)
Can you explain more clearly exactly what you are doing? What needs
to be aggregated when? How are the threads managed?
Phil
> Le 4 nov. 2013 21:48, "Phil Steitz" <ph...@gmail.com> a écrit :
>
>> On 11/4/13 12:12 PM, Romain Manni-Bucau wrote:
>>> But aggregation needs to lock so not a real solution. Lock is fine on
>> real
>>> cases but not in simple/light ones. ThreadLocal leaks...so a trade off
>>> should be found
>> Depends on the use case. If the use case is
>>
>> 0) launch a bunch of threads and let them gather stats individually
>> 1) aggregate results
>>
>> Then the static aggregate method in AggregateSummaryStatistics that
>> takes a collection as input will work with no locking required.
>>
>> Phil
>>> Le 4 nov. 2013 18:42, "Phil Steitz" <ph...@gmail.com> a écrit :
>>>
>>>> On 11/4/13 8:49 AM, Romain Manni-Bucau wrote:
>>>>> Hi,
>>>>>
>>>>> ATM sirona (a java monitoring library in incubator) relies a lot on
>>>>> Summary stats object from [math3] but it needed a lock to ensure
>>>>> consistency. I know there is a synchronized version but this one
>>>>> scales less then the locked one.
>>>>>
>>>>> My question is quite simple then: will [math] add an implementation
>>>>> with thread safety guarantee and good performances? I think for
>>>>> instance to the LongAdder of Doug Lea which could be used as a good
>>>>> base.
>>>> The short answer is yes, patches welcome.
>>>>
>>>> Ted makes a good point, though; and there is already some support
>>>> for aggregation in the stats classes in [math] (i.e., you can
>>>> aggregate the results of per-thread stats by using, e.g.
>>>> AggregateSummaryStatistics#aggregate). See MATH-1016 re extending
>>>> this to more stats.
>>>>
>>>> Phil
>>>>
>>>>> Romain Manni-Bucau
>>>>> Twitter: @rmannibucau
>>>>> Blog: http://rmannibucau.wordpress.com/
>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>>>> Github: https://github.com/rmannibucau
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> 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
Re: [math] Multithreaded performances
Posted by Romain Manni-Bucau <rm...@gmail.com>.
In sirona we collect (aggregate) data each N ms and we can still use stats
during aggregation (worse case surely)
Le 4 nov. 2013 21:48, "Phil Steitz" <ph...@gmail.com> a écrit :
> On 11/4/13 12:12 PM, Romain Manni-Bucau wrote:
> > But aggregation needs to lock so not a real solution. Lock is fine on
> real
> > cases but not in simple/light ones. ThreadLocal leaks...so a trade off
> > should be found
>
> Depends on the use case. If the use case is
>
> 0) launch a bunch of threads and let them gather stats individually
> 1) aggregate results
>
> Then the static aggregate method in AggregateSummaryStatistics that
> takes a collection as input will work with no locking required.
>
> Phil
> > Le 4 nov. 2013 18:42, "Phil Steitz" <ph...@gmail.com> a écrit :
> >
> >> On 11/4/13 8:49 AM, Romain Manni-Bucau wrote:
> >>> Hi,
> >>>
> >>> ATM sirona (a java monitoring library in incubator) relies a lot on
> >>> Summary stats object from [math3] but it needed a lock to ensure
> >>> consistency. I know there is a synchronized version but this one
> >>> scales less then the locked one.
> >>>
> >>> My question is quite simple then: will [math] add an implementation
> >>> with thread safety guarantee and good performances? I think for
> >>> instance to the LongAdder of Doug Lea which could be used as a good
> >>> base.
> >> The short answer is yes, patches welcome.
> >>
> >> Ted makes a good point, though; and there is already some support
> >> for aggregation in the stats classes in [math] (i.e., you can
> >> aggregate the results of per-thread stats by using, e.g.
> >> AggregateSummaryStatistics#aggregate). See MATH-1016 re extending
> >> this to more stats.
> >>
> >> Phil
> >>
> >>> Romain Manni-Bucau
> >>> Twitter: @rmannibucau
> >>> Blog: http://rmannibucau.wordpress.com/
> >>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >>> Github: https://github.com/rmannibucau
> >>>
> >>> ---------------------------------------------------------------------
> >>> 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
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [math] Multithreaded performances
Posted by Phil Steitz <ph...@gmail.com>.
On 11/4/13 12:12 PM, Romain Manni-Bucau wrote:
> But aggregation needs to lock so not a real solution. Lock is fine on real
> cases but not in simple/light ones. ThreadLocal leaks...so a trade off
> should be found
Depends on the use case. If the use case is
0) launch a bunch of threads and let them gather stats individually
1) aggregate results
Then the static aggregate method in AggregateSummaryStatistics that
takes a collection as input will work with no locking required.
Phil
> Le 4 nov. 2013 18:42, "Phil Steitz" <ph...@gmail.com> a écrit :
>
>> On 11/4/13 8:49 AM, Romain Manni-Bucau wrote:
>>> Hi,
>>>
>>> ATM sirona (a java monitoring library in incubator) relies a lot on
>>> Summary stats object from [math3] but it needed a lock to ensure
>>> consistency. I know there is a synchronized version but this one
>>> scales less then the locked one.
>>>
>>> My question is quite simple then: will [math] add an implementation
>>> with thread safety guarantee and good performances? I think for
>>> instance to the LongAdder of Doug Lea which could be used as a good
>>> base.
>> The short answer is yes, patches welcome.
>>
>> Ted makes a good point, though; and there is already some support
>> for aggregation in the stats classes in [math] (i.e., you can
>> aggregate the results of per-thread stats by using, e.g.
>> AggregateSummaryStatistics#aggregate). See MATH-1016 re extending
>> this to more stats.
>>
>> Phil
>>
>>> Romain Manni-Bucau
>>> Twitter: @rmannibucau
>>> Blog: http://rmannibucau.wordpress.com/
>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>>> Github: https://github.com/rmannibucau
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Multithreaded performances
Posted by Romain Manni-Bucau <rm...@gmail.com>.
But aggregation needs to lock so not a real solution. Lock is fine on real
cases but not in simple/light ones. ThreadLocal leaks...so a trade off
should be found
Le 4 nov. 2013 18:42, "Phil Steitz" <ph...@gmail.com> a écrit :
> On 11/4/13 8:49 AM, Romain Manni-Bucau wrote:
> > Hi,
> >
> > ATM sirona (a java monitoring library in incubator) relies a lot on
> > Summary stats object from [math3] but it needed a lock to ensure
> > consistency. I know there is a synchronized version but this one
> > scales less then the locked one.
> >
> > My question is quite simple then: will [math] add an implementation
> > with thread safety guarantee and good performances? I think for
> > instance to the LongAdder of Doug Lea which could be used as a good
> > base.
>
> The short answer is yes, patches welcome.
>
> Ted makes a good point, though; and there is already some support
> for aggregation in the stats classes in [math] (i.e., you can
> aggregate the results of per-thread stats by using, e.g.
> AggregateSummaryStatistics#aggregate). See MATH-1016 re extending
> this to more stats.
>
> Phil
>
> >
> > Romain Manni-Bucau
> > Twitter: @rmannibucau
> > Blog: http://rmannibucau.wordpress.com/
> > LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > Github: https://github.com/rmannibucau
> >
> > ---------------------------------------------------------------------
> > 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
>
>
Re: [math] Multithreaded performances
Posted by Phil Steitz <ph...@gmail.com>.
On 11/4/13 8:49 AM, Romain Manni-Bucau wrote:
> Hi,
>
> ATM sirona (a java monitoring library in incubator) relies a lot on
> Summary stats object from [math3] but it needed a lock to ensure
> consistency. I know there is a synchronized version but this one
> scales less then the locked one.
>
> My question is quite simple then: will [math] add an implementation
> with thread safety guarantee and good performances? I think for
> instance to the LongAdder of Doug Lea which could be used as a good
> base.
The short answer is yes, patches welcome.
Ted makes a good point, though; and there is already some support
for aggregation in the stats classes in [math] (i.e., you can
aggregate the results of per-thread stats by using, e.g.
AggregateSummaryStatistics#aggregate). See MATH-1016 re extending
this to more stats.
Phil
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
> ---------------------------------------------------------------------
> 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
Re: [math] Multithreaded performances
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Thats more or less what does LongAdder in a more clever way.
Le 4 nov. 2013 18:15, "Ted Dunning" <te...@gmail.com> a écrit :
> My experience is that the only way to get really high performance with
> counter-like objects is to have one per thread and combine them on read.
>
>
>
>
> On Mon, Nov 4, 2013 at 8:49 AM, Romain Manni-Bucau <rmannibucau@gmail.com
> >wrote:
>
> > Hi,
> >
> > ATM sirona (a java monitoring library in incubator) relies a lot on
> > Summary stats object from [math3] but it needed a lock to ensure
> > consistency. I know there is a synchronized version but this one
> > scales less then the locked one.
> >
> > My question is quite simple then: will [math] add an implementation
> > with thread safety guarantee and good performances? I think for
> > instance to the LongAdder of Doug Lea which could be used as a good
> > base.
> >
> > Romain Manni-Bucau
> > Twitter: @rmannibucau
> > Blog: http://rmannibucau.wordpress.com/
> > LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > Github: https://github.com/rmannibucau
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
Re: [math] Multithreaded performances
Posted by Ted Dunning <te...@gmail.com>.
My experience is that the only way to get really high performance with
counter-like objects is to have one per thread and combine them on read.
On Mon, Nov 4, 2013 at 8:49 AM, Romain Manni-Bucau <rm...@gmail.com>wrote:
> Hi,
>
> ATM sirona (a java monitoring library in incubator) relies a lot on
> Summary stats object from [math3] but it needed a lock to ensure
> consistency. I know there is a synchronized version but this one
> scales less then the locked one.
>
> My question is quite simple then: will [math] add an implementation
> with thread safety guarantee and good performances? I think for
> instance to the LongAdder of Doug Lea which could be used as a good
> base.
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [math] Multithreaded performances
Posted by Ted Dunning <te...@gmail.com>.
My experience is that the only way to get really high performance with
counter-like objects is to have one per thread and combine them on read.
On Mon, Nov 4, 2013 at 8:49 AM, Romain Manni-Bucau <rm...@gmail.com>wrote:
> Hi,
>
> ATM sirona (a java monitoring library in incubator) relies a lot on
> Summary stats object from [math3] but it needed a lock to ensure
> consistency. I know there is a synchronized version but this one
> scales less then the locked one.
>
> My question is quite simple then: will [math] add an implementation
> with thread safety guarantee and good performances? I think for
> instance to the LongAdder of Doug Lea which could be used as a good
> base.
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>