You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by Alan Carroll <so...@oath.com.INVALID> on 2017/10/01 22:04:00 UTC
Re: [Dependency Proposal] intel::tbb
I wonder where Concurrency Kit falls on that graph. Here's an interesting
quote from TBB:[1]
"Using the task scheduler is usually the best approach to threading for
performance, however there are cases when the task scheduler is not
appropriate. The task scheduler is intended for high-performance algorithms
composed from non-blocking tasks. It still works if the tasks rarely block.
However, if threads block frequently, there is a performance loss when
using the task scheduler because while the thread is blocked, it is not
working on any tasks. Blocking typically occurs while waiting for I/O or
mutexes for long periods. If threads hold mutexes for long periods, your
code is not likely to perform well anyway, no matter how many threads it
has. If you have blocking tasks, it is best to use full-blown threads for
those."
Hmmmm.....
[1] https://software.intel.com/en-us/node/506101
Re: [Dependency Proposal] intel::tbb
Posted by Masaori Koshiba <ma...@apache.org>.
Anybody looked at libcds[1]? It says it's mostly header-only template
library of concurrent data structures. It sounds like what we're looking
for. And performance looks similar to TBB.
( I'm not -1 to TBB )
- [1] libcds
https://github.com/khizmax/libcds
- Masaori
2017年10月5日(木) 7:37 Jason Kenny <jk...@oath.com.invalid>:
> I this we could a lot of value out of TBB. The tasking engine is much
> better than what we have. However I would not suggest we just replace
> everything, but instead bring it in and look at "low-hanging" fruit such as
> the hash map that we can get value out of today. Larger projects as using
> its advance tasking engine, arena, etc can be done slowing as the team
> understands the value in doing so and how to do it without breaking
> existing APIs.
>
> On Wed, Oct 4, 2017 at 3:59 PM, CrazyCow <zh...@gmail.com>
> wrote:
>
> > We use continuations everywhere, which might not be appropriate according
> > to the above quote? xD
> >
> > For this particular use case of the PR, it's pretty simple code and I
> don't
> > think it will be a performance bottleneck. What we want here is a mature,
> > well documented and widely used concurrent implementation of hashmap,
> which
> > I think tbb is one of the top choices.
> >
> > 2017-10-01 15:04 GMT-07:00 Alan Carroll <solidwallofcode@oath.com.
> > invalid>:
> >
> > > I wonder where Concurrency Kit falls on that graph. Here's an
> interesting
> > > quote from TBB:[1]
> > >
> > > "Using the task scheduler is usually the best approach to threading for
> > > performance, however there are cases when the task scheduler is not
> > > appropriate. The task scheduler is intended for high-performance
> > algorithms
> > > composed from non-blocking tasks. It still works if the tasks rarely
> > block.
> > > However, if threads block frequently, there is a performance loss when
> > > using the task scheduler because while the thread is blocked, it is not
> > > working on any tasks. Blocking typically occurs while waiting for I/O
> or
> > > mutexes for long periods. If threads hold mutexes for long periods,
> your
> > > code is not likely to perform well anyway, no matter how many threads
> it
> > > has. If you have blocking tasks, it is best to use full-blown threads
> for
> > > those."
> > >
> > > Hmmmm.....
> > >
> > > [1] https://software.intel.com/en-us/node/506101
> > >
> >
>
Re: [Dependency Proposal] intel::tbb
Posted by Jason Kenny <jk...@oath.com.INVALID>.
I this we could a lot of value out of TBB. The tasking engine is much
better than what we have. However I would not suggest we just replace
everything, but instead bring it in and look at "low-hanging" fruit such as
the hash map that we can get value out of today. Larger projects as using
its advance tasking engine, arena, etc can be done slowing as the team
understands the value in doing so and how to do it without breaking
existing APIs.
On Wed, Oct 4, 2017 at 3:59 PM, CrazyCow <zh...@gmail.com> wrote:
> We use continuations everywhere, which might not be appropriate according
> to the above quote? xD
>
> For this particular use case of the PR, it's pretty simple code and I don't
> think it will be a performance bottleneck. What we want here is a mature,
> well documented and widely used concurrent implementation of hashmap, which
> I think tbb is one of the top choices.
>
> 2017-10-01 15:04 GMT-07:00 Alan Carroll <solidwallofcode@oath.com.
> invalid>:
>
> > I wonder where Concurrency Kit falls on that graph. Here's an interesting
> > quote from TBB:[1]
> >
> > "Using the task scheduler is usually the best approach to threading for
> > performance, however there are cases when the task scheduler is not
> > appropriate. The task scheduler is intended for high-performance
> algorithms
> > composed from non-blocking tasks. It still works if the tasks rarely
> block.
> > However, if threads block frequently, there is a performance loss when
> > using the task scheduler because while the thread is blocked, it is not
> > working on any tasks. Blocking typically occurs while waiting for I/O or
> > mutexes for long periods. If threads hold mutexes for long periods, your
> > code is not likely to perform well anyway, no matter how many threads it
> > has. If you have blocking tasks, it is best to use full-blown threads for
> > those."
> >
> > Hmmmm.....
> >
> > [1] https://software.intel.com/en-us/node/506101
> >
>
Re: [Dependency Proposal] intel::tbb
Posted by CrazyCow <zh...@gmail.com>.
We use continuations everywhere, which might not be appropriate according
to the above quote? xD
For this particular use case of the PR, it's pretty simple code and I don't
think it will be a performance bottleneck. What we want here is a mature,
well documented and widely used concurrent implementation of hashmap, which
I think tbb is one of the top choices.
2017-10-01 15:04 GMT-07:00 Alan Carroll <so...@oath.com.invalid>:
> I wonder where Concurrency Kit falls on that graph. Here's an interesting
> quote from TBB:[1]
>
> "Using the task scheduler is usually the best approach to threading for
> performance, however there are cases when the task scheduler is not
> appropriate. The task scheduler is intended for high-performance algorithms
> composed from non-blocking tasks. It still works if the tasks rarely block.
> However, if threads block frequently, there is a performance loss when
> using the task scheduler because while the thread is blocked, it is not
> working on any tasks. Blocking typically occurs while waiting for I/O or
> mutexes for long periods. If threads hold mutexes for long periods, your
> code is not likely to perform well anyway, no matter how many threads it
> has. If you have blocking tasks, it is best to use full-blown threads for
> those."
>
> Hmmmm.....
>
> [1] https://software.intel.com/en-us/node/506101
>