Yea, I looked into Junction before tbb, until I found this comment on hacker news.
Uhm... The absolute Y-position of the curve on the graph is secondary to > its shape. Also, the scalability discussion is largely pointless if the > sample set covers only 6 CPUs. > Intel TBB scales proportionally, which is precisely what you'd want here. > Junction starts to flatten out on 6th CPU, which implies that it has > fundamental design issues that crop up at higher CPU counts. Chances are > that its performance not only won't scale further, but will actually drop > further down the graph. > On other hand TBB code can be put throught some routine code optimization > (hand-coded assembly and such) to increase its performance without > affecting its linear graph shape. >From https://news.ycombinator.com/item?id=11016350 And at the end of the blog you mentioned, the author admitted Junction was a temporary project, so I walked away. > Jeff Preshing · 16 weeks ago > Look like I didn't implement that, sorry! I know clear is basic > functionality, but this was an experimental project and I'm now busy with > other things. I suppose there are different ways it could be added > depending whether thread safety is required. 2017-09-29 15:13 GMT-07:00 Bryan Call <bc...@apache.org>: > Here are some benchmark numbers I ran across when looking at different > thread safe hash implementations: > > > > > Source: http://preshing.com/20160201/new-concurrent-hash-maps-for-cpp/ > > -Bryan > > > > On Sep 29, 2017, at 2:42 PM, Bryan Call <bc...@apache.org> wrote: > > TCL handles concurrency for memory allocation bits. Looking at it more, > the hashtable part of the library doesn’t support currency and you would > have to handle locking yourself. > > *I created a test program to see when it was locking:* > #include "ink_hash_table.h" > #include <stdlib.h> > #include <iostream> > > using namespace std; > > int main() { > const char *foo = "hello_world"; > InkHashTable *mine(ink_hash_table_create(InkHashTableKeyType_String)); > ink_hash_table_insert(mine, "foo", (void*)foo); > char *foo_check = nullptr; > ink_hash_table_lookup(mine, "foo", (void**)&foo_check); > cout << foo_check << endl; > } > > Breakpoint 3, 0x00007ffff5ea4da0 in pthread_mutex_lock () from > /lib64/libpthread.so.0 > (gdb) bt > #0 0x00007ffff5ea4da0 in pthread_mutex_lock () from /lib64/libpthread.so.0 > #1 0x00007ffff65fe927 in ?? () from /lib64/libtcl8.6.so > #2 0x00007ffff65fed6d in TclpAlloc () from /lib64/libtcl8.6.so > #3 0x00007ffff65213c8 in Tcl_Alloc () from /lib64/libtcl8.6.so > #4 0x00007ffff65b6315 in ?? () from /lib64/libtcl8.6.so > #5 0x00007ffff65b64c7 in ?? () from /lib64/libtcl8.6.so > #6 0x00007ffff7bafe67 in ink_hash_table_get_entry (ht_ptr=<optimized > out>, key=<optimized out>, new_value=<optimized out>) at > ink_hash_table.cc:244 > #7 0x00007ffff7bafeb6 in ink_hash_table_insert (ht_ptr=ht_ptr@entry=0x614010, > key=key@entry=0x400b3c "foo", value=value@entry=0x400b30) at > ink_hash_table.cc:293 > #8 0x0000000000400951 in main () at test_ink_hash_table.cc:10 > (gdb) cont > > -Bryan > > > > On Sep 29, 2017, at 1:50 PM, CrazyCow <zhangzizhong0...@gmail.com> wrote: > > I read the code of Tcl_HashTable. They say nothing about handling > concurrency. > > The biggest concern about this is, as Alan and Bryan said, what level of > use will we have for ATS. > I read docs <https://www.threadingbuildingblocks.org/docs/help/index.htm> > of TBB. It's offering rich tools of handling threading issues. We can look > into it more to see if there are other utilities appealing. > Generally speaking, nice docs, good reputation, and upcoming new releases > are signs of tbb being a good choice. > > 2017-09-29 12:11 GMT-07:00 Bryan Call <bc...@apache.org>: > >> This seems like a large dependency to pull in to get a thread safe >> unordered map. We already have a dependency on Tcl_HashTable >> (InkHashTable), that handles concurrency, and it used throughout the code >> base. >> >> -Bryan >> >> >> >> On Sep 28, 2017, at 5:55 PM, CrazyCow <zhangzizhong0...@gmail.com> wrote: >> >> Hi, ATS devs, >> >> Currently, we have a requirement of concurrent_unordered_map (details can >> be found https://github.com/apache/trafficserver/pull/2555). And >> intel::tbb::concurrent_unordered_map is the most mature one we can try >> out. >> I understand this dependency is huge. I'd like to hear opinions from you >> guys, that whether we need to do it or not and if yes, what is the best >> approach to introduce it. >> >> >> Thanks, >> Zizhong >> >> >> > > >
