我正在使用work_pile模式,以便线程始终运行并等待传入的新函数指针+队列中的数据的信号量。那是什么苹果营销人员现在称之为大中央调度和推广作为新的切片面包的事情。细粒度多线程 - 工作任务应该执行多少?
我只是想知道如何将短任务分成两个更短的任务是否有用。是否有我可以判断是否值得排队新对象的规则?
我正在使用work_pile模式,以便线程始终运行并等待传入的新函数指针+队列中的数据的信号量。那是什么苹果营销人员现在称之为大中央调度和推广作为新的切片面包的事情。细粒度多线程 - 工作任务应该执行多少?
我只是想知道如何将短任务分成两个更短的任务是否有用。是否有我可以判断是否值得排队新对象的规则?
两个可能的答案:
我更喜欢第二个。
无论如何,如果两个任务总是依次运行(即按顺序),那么我认为没有增益来分割它们。
基准测试并不容易,只有在实施后才能做到。我想有一个清单,当我应该开始寻找分裂。我甚至不知道线程激活的平均成本是多少,是否需要纳秒,微秒?如果我排队算法的多个步骤,那么没有只有一个信号量计数器递减和一个互斥体,比如100个周期+缓存未命中? – Lothar 2009-08-26 13:49:26
我想补充一点,一个重要因素也是CPU /内核的数量以及如何为它们分配任务。虽然理论上你可以从可用内核的数量中抽象出来,但我确信只有基准测试才能正确回答你的问题。 – mouviciel 2009-08-26 14:33:13
@mouvicel:基准测试的局限性在于它只能给出具体问题的答案,并不一定能提供很多关于如何在稍微不同的情况下调整最佳性能的深入见解。这就是为什么我们希望有一些理论上的见解可以用于自动调整。 – 2009-08-27 14:10:35
多任务的限制是您拥有多少个核心以及多少算法是并发的。各种类型的开销(包括锁定)可以减少并发的数量,降低甚至扭转多任务的好处。这就是为什么当有独立的,长时间运行的任务时,它是最好的。话虽如此,只要开销并不能带来性能上的提升,就可以在核心之间划分一个短小的任务。
工作模式背后的想法是,您可以从可用内核数量中抽象出来。 – Lothar 2009-08-26 13:34:49
对,对于CPU绑定的活动,您可能会设置n + 1个线程从输入队列中读取,其中n是核心数。对于I/O绑定的,您可能需要更多。 – 2009-08-26 16:50:18
好吧,我对它做了更多的研究,听起来操作系统正在为池中的线程数量负责。我想这很方便,但我不确定它是如何决定调整的。当I/O阻塞时,n + 1启发式失败。 – 2009-08-26 20:27:46
简而言之,您需要考虑资源+工作量+基准。
这里有一些事情会打破方式:
因此,总之,我会说,你需要输入你三思。如果你已经有了可以工作的代码,那就好比银行里的钱。是否值得投入更多时间来提高代码的生产力,或者投资回报率是否太低(或负值)?
这是我在GCD上找到的链接:http://episteme.arstechnica.com/eve/forums?a=dl&f=174096756&x_id=mtid39095 – 2009-08-26 20:26:24