我需要使用以下算法(在Python中)为我的项目收集一些统计信息:
stats = defaultdict(list)
for s in L:
current = []
for q in L:
stats[s, q] = copy(current)
current = f(current, s, q)
因为列表L
很大且f()
并且复制current
需要一些时间,项目主要语言是C ++我决定选择C ++并使用其多线程功能来实现我的算法。 / p>
我移动了那部分:
stats[s, q] = copy(current)
current = f(current, s, q)
到单独的std::async
,并在插入std::mutex
时锁定stats
,但这会让事情变得更慢。我试图使用tbb::concurrent_ordered_map
但这会让事情变得更糟。
我写了基准来重现它的行为:https://gist.github.com/myaut/94ee59d9752f524d3da8
带有Debian 7的2 x Xeon E5-2420在L中的800个条目的结果:
single-threaded 8157ms
async mutex 10145ms
async with chunks mutex 9618ms
threads mutex 9378ms
async tbb 10173ms
async with chunks tbb 9560ms
threads tbb 9418ms
我不明白为什么TBB最慢(似乎tbb::concurrent_ordered_map
分配更大量的内存,但是为了什么)。有没有其他选择可以帮助我?
编辑:我已使用建议的方法更新了我的基准(并将N减少到800)。似乎问题出在其他地方......
async
处理20个连续元素列表的包EDIT2 :我发现其中一个问题 - 应用消耗大量内存,因此Xen Hypervisor成为瓶颈 - 在纯模式下重启,现在多线程模式只比uni慢一点-threaded
EDIT3 :在复制list
时,似乎多线程的问题是大量的分配:
mprotect()
_int_malloc+0xcba/0x13f0
__libc_malloc+0x70/0x260
operator new(unsigned long)+0x1d/0x90
__gnu_cxx::new_allocator<int>::allocate(unsigned long, void const*)+0x40/0x42
std::_Vector_base<int, std::allocator<int> >::_M_allocate(unsigned long)+0x2f/0x38
std::_Vector_base<int, std::allocator<int> >::_M_create_storage(unsigned long)+0x23/0x58
std::_Vector_base<int, std::allocator<int> >::_Vector_base(unsigned long, std::allocator<int> const&)+0x3b/0x5e
std::vector<int, std::allocator<int> >::vector(std::vector<int, std::allocator<int> > const&)+0x55/0xf0
void threaded_process<concurrent_map_of_list_of_lists>(concurrent_map_of_list_of_lists&, std::vector<int, std::allocator<int> > const&)::{lambda(__gnu_cxx::__normal_iterator<int const*, std::vector<int, std::allocator<int> > >, __gnu_cxx::__normal_iterator<int const*, std::vector<int, std::allocator<int> > >, int)#1}::operator()(__gnu_cxx::__normal_iterator<int const*, std::vector<int, std::allocator<int> > >, __gnu_cxx::__normal_iterator<int const*, std::vector<int, std::allocator<int> > >, int) const+0x5f/0x1dc
_ZNSt12_Bind_simpleIFZ16threaded_processI31concurrent_map_of_list_of_listsEvRT_RKSt6vectorIiSaIiEEEUlN9__gnu_cxx17__normal_iteratorIPKiS6_EESD_iE_SD_SD_iEE9_M_invokeIJLm0ELm1ELm2EEEEvSt12_Index_tupleIJXspT_EEE+0x7c/0x87
std::_Bind_simple<void threaded_process<concurrent_map_of_list_of_lists>(concurrent_map_of_list_of_lists&, std::vector<int, std::allocator<int> > const&)::{lambda(__gnu_cxx::__normal_iterator<int const*, std::vector<int, std::allocator<int> > >, __gnu_cxx::__normal_iterator<int const*, std::vector<int, std::allocator<int> > >, int)#1} (__gnu_cxx::__normal_iterator<int const*, std::vector<int, std::allocator<int> > >, __gnu_cxx::__normal_iterator<int const*, std::vector<int, std::allocator<int> > >, int)>::operator()()+0x1b/0x28
std::thread::_Impl<std::_Bind_simple<void threaded_process<concurrent_map_of_list_of_lists>(concurrent_map_of_list_of_lists&, std::vector<int, std::allocator<int> > const&)::{lambda(__gnu_cxx::__normal_iterator<int const*, std::vector<int, std::allocator<int> > >, __gnu_cxx::__normal_iterator<int const*, std::vector<int, std::allocator<int> > >, int)#1} (__gnu_cxx::__normal_iterator<int const*, std::vector<int, std::allocator<int> > >, __gnu_cxx::__normal_iterator<int const*, std::vector<int, std::allocator<int> > >, int)> >::_M_run()+0x1c/0x1e
std::error_code::default_error_condition() const+0x40/0xc0
start_thread+0xd0/0x300
clone+0x6d/0x90
当堆空间耗尽时,libc调用grow_heap()
,它通常只添加一个页面,但随后调用mprotect()
调用内核中的validate_mm()
。 validate_mm()
似乎使用信号量锁定整个VMA。我用list
替换了默认的tbb::scalable_allocator
分配器,它摇滚!现在tbb
比单处理器方法快2倍。
感谢您的帮助,我会在std::async
中使用@Dave方法处理大量工作。
答案 0 :(得分:3)
如果f(current, s, q)
和复制current
非常便宜,那么多线程的开销很难实现。但是,我想我会使用无锁哈希/无序地图(tbb::concurrent_hash_map
?我不知道tbb)并使用std::async
启动整个内部for循环。我的想法是使用std::async
启动一个相当大的工作块,如果它太小并且你启动了一百万个琐碎的任务,那么使用std::async
的开销将超过任务所需的工作量。做!
另外需要注意的是,当您使用std::async
时,您需要在某处保存已退回的future
,否则最终会阻止,直到future
中的任务完成为止析构函数,购买多线程开销,根本没有并行处理。你现在可能正在遇到这种情况。这非常令人讨厌,我希望它不会那样工作。