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 <zhangzizhong0...@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 <solidwallofc...@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 > > >
