You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Sergey Evdokimov <se...@gridgain.com> on 2015/03/08 19:45:26 UTC

GridConcurrentFactory.CONCURRENCY_LEVEL

Hello,

Why we have so huge concurrency level for concurrent hash maps created by
GridConcurrentFactory.newMap() ? By default concurrency level is 256, does
we expect that 265 thread will update the map *at same time*? Huge
concurrency level increases iteration time.
When I set concurrency level to jvm default value (16) my benchmark became
73% faster (23000 operation/sec vs 40000 operation/sec). My benchmark just
executes simple job on local node. GridTaskProcessor iterates over
GridTaskProcessor#tasks on each task submit. Although
GridTaskProcessor#tasks is empty iteration get a lot of time.

Re: GridConcurrentFactory.CONCURRENCY_LEVEL

Posted by Yakov Zhdanov <yz...@gridgain.com>.
I removed the iteration and committed it to sprint-2.

--
Yakov Zhdanov, Director R&D
*GridGain Systems*
www.gridgain.com

2015-03-11 1:37 GMT+03:00 Dmitriy Setrakyan <ds...@apache.org>:

> Sergey,
>
> I think the default concurrency level should be the number of available
> cores times 2. On top of that, I would also look at why GridTaskProcessor
> needs to iterate over list of tasks on each submit... is it really
> necessary?
>
> D.
>
> On Tue, Mar 10, 2015 at 6:29 AM, Yakov Zhdanov <yz...@gridgain.com>
> wrote:
>
> > I agree, this makes iterations over map much longer.
> >
> > Please create ticket in jira and remove the factory and run benchmarks
> > after that.
> >
> > --
> > Yakov Zhdanov, Director R&D
> > *GridGain Systems*
> > www.gridgain.com
> >
> > 2015-03-08 21:45 GMT+03:00 Sergey Evdokimov <se...@gridgain.com>:
> >
> > > Hello,
> > >
> > > Why we have so huge concurrency level for concurrent hash maps created
> by
> > > GridConcurrentFactory.newMap() ? By default concurrency level is 256,
> > does
> > > we expect that 265 thread will update the map *at same time*? Huge
> > > concurrency level increases iteration time.
> > > When I set concurrency level to jvm default value (16) my benchmark
> > became
> > > 73% faster (23000 operation/sec vs 40000 operation/sec). My benchmark
> > just
> > > executes simple job on local node. GridTaskProcessor iterates over
> > > GridTaskProcessor#tasks on each task submit. Although
> > > GridTaskProcessor#tasks is empty iteration get a lot of time.
> > >
> >
>

Re: GridConcurrentFactory.CONCURRENCY_LEVEL

Posted by Sergey Evdokimov <se...@gridgain.com>.
Dmitry,

We uses ConcurrentHashMap8, this implementation does not uses
*concurrencyLevel* parametrer, constructor *ConcurrentHashMap8(int
initialCapacity, float loadFactor, int concurrencyLevel)* was left for
backward compatibility only, parameter *concurrencyLevel* uses just as
restriction *initialCapacity*.

public ConcurrentHashMap8(int initialCapacity, float loadFactor, int
concurrencyLevel) {
    ...
    if (initialCapacity < concurrencyLevel)   // Use at least as many bins
        initialCapacity = concurrencyLevel;   // as estimated threads
    ...
}

So we should not pass concurrencyLevel at all.

On Wed, Mar 11, 2015 at 1:37 AM, Dmitriy Setrakyan <ds...@apache.org>
wrote:

> Sergey,
>
> I think the default concurrency level should be the number of available
> cores times 2. On top of that, I would also look at why GridTaskProcessor
> needs to iterate over list of tasks on each submit... is it really
> necessary?
>
> D.
>
> On Tue, Mar 10, 2015 at 6:29 AM, Yakov Zhdanov <yz...@gridgain.com>
> wrote:
>
> > I agree, this makes iterations over map much longer.
> >
> > Please create ticket in jira and remove the factory and run benchmarks
> > after that.
> >
> > --
> > Yakov Zhdanov, Director R&D
> > *GridGain Systems*
> > www.gridgain.com
> >
> > 2015-03-08 21:45 GMT+03:00 Sergey Evdokimov <se...@gridgain.com>:
> >
> > > Hello,
> > >
> > > Why we have so huge concurrency level for concurrent hash maps created
> by
> > > GridConcurrentFactory.newMap() ? By default concurrency level is 256,
> > does
> > > we expect that 265 thread will update the map *at same time*? Huge
> > > concurrency level increases iteration time.
> > > When I set concurrency level to jvm default value (16) my benchmark
> > became
> > > 73% faster (23000 operation/sec vs 40000 operation/sec). My benchmark
> > just
> > > executes simple job on local node. GridTaskProcessor iterates over
> > > GridTaskProcessor#tasks on each task submit. Although
> > > GridTaskProcessor#tasks is empty iteration get a lot of time.
> > >
> >
>

Re: GridConcurrentFactory.CONCURRENCY_LEVEL

Posted by Dmitriy Setrakyan <ds...@apache.org>.
Sergey,

I think the default concurrency level should be the number of available
cores times 2. On top of that, I would also look at why GridTaskProcessor
needs to iterate over list of tasks on each submit... is it really
necessary?

D.

On Tue, Mar 10, 2015 at 6:29 AM, Yakov Zhdanov <yz...@gridgain.com>
wrote:

> I agree, this makes iterations over map much longer.
>
> Please create ticket in jira and remove the factory and run benchmarks
> after that.
>
> --
> Yakov Zhdanov, Director R&D
> *GridGain Systems*
> www.gridgain.com
>
> 2015-03-08 21:45 GMT+03:00 Sergey Evdokimov <se...@gridgain.com>:
>
> > Hello,
> >
> > Why we have so huge concurrency level for concurrent hash maps created by
> > GridConcurrentFactory.newMap() ? By default concurrency level is 256,
> does
> > we expect that 265 thread will update the map *at same time*? Huge
> > concurrency level increases iteration time.
> > When I set concurrency level to jvm default value (16) my benchmark
> became
> > 73% faster (23000 operation/sec vs 40000 operation/sec). My benchmark
> just
> > executes simple job on local node. GridTaskProcessor iterates over
> > GridTaskProcessor#tasks on each task submit. Although
> > GridTaskProcessor#tasks is empty iteration get a lot of time.
> >
>

Re: GridConcurrentFactory.CONCURRENCY_LEVEL

Posted by Yakov Zhdanov <yz...@gridgain.com>.
I agree, this makes iterations over map much longer.

Please create ticket in jira and remove the factory and run benchmarks
after that.

--
Yakov Zhdanov, Director R&D
*GridGain Systems*
www.gridgain.com

2015-03-08 21:45 GMT+03:00 Sergey Evdokimov <se...@gridgain.com>:

> Hello,
>
> Why we have so huge concurrency level for concurrent hash maps created by
> GridConcurrentFactory.newMap() ? By default concurrency level is 256, does
> we expect that 265 thread will update the map *at same time*? Huge
> concurrency level increases iteration time.
> When I set concurrency level to jvm default value (16) my benchmark became
> 73% faster (23000 operation/sec vs 40000 operation/sec). My benchmark just
> executes simple job on local node. GridTaskProcessor iterates over
> GridTaskProcessor#tasks on each task submit. Although
> GridTaskProcessor#tasks is empty iteration get a lot of time.
>