【问题标题】:Sorting seems to be slower with 2 threads instead of 1使用 2 个线程而不是 1 个线程,排序似乎更慢
【发布时间】:2016-07-11 14:06:23
【问题描述】:

我从 Python 中的线程开始,并尝试实现合并排序,在开始时,作业被拆分为 2 个线程。我正在使用collections.dequeitertools.islicethreading.Thread

我在开始时创建了两个线程,它们正常地完成了一半的工作,然后我加入它们并合并结果。但我注意到 使用两个线程所需的时间比我正常使用时要长得多(几乎是原来的 2 倍)

这怎么可能? Here is a link to the code,如果需要,我可以在这里复制主要部分(我也在Code Review SE 上发布了这个问题,我宁愿保持这个简短)

它是否链接到this 问题(在C++ 中似乎是一个类似的问题)?非常感谢。

【问题讨论】:

  • 为什么投反对票?
  • 虽然 CPython 的 GIL 限制了多线程,但你仍然可以使用multiprocessing
  • @EliKorvigo - 假设至少需要一些共享内存,即使在多处理时这是否仍然是个问题?
  • @rcgldr multiprocessing 有一些使用起来很痛苦的低级共享内存原语,但 GIL 不是问题。

标签: python multithreading performance sorting mergesort


【解决方案1】:

这怎么可能?

与 C++ 不同,Python 很难并行化,因为 GIL

虽然collections.dequeappendpopleft 是线程安全的,但这并不能保证它们在非串行范例中表现良好。

它与这个问题有关吗?

没有。 GIL 是 CPython 的一个属性。它与虚假分享完全脱节。

使用两个线程比我正常执行时花费的时间更长(几乎是两倍的时间)。

这是因为 GIL 不支持共享内存多线程。因此,您实际上是在连续两次运行您的代码。

【讨论】:

  • 所以你的意思是我不能只用多线程来让它更快?我能做什么?
  • @BusyAnt 我不推荐将 Python 用于多线程应用程序。更喜欢 C++、Java、Scala 或其他几乎任何东西。
  • 好的,我会记住的。你能说是什么在吃我的节目在这里的表现吗?线程创建?在线程之间切换?还有什么?我不确定我是否完全理解这里...
  • @BusyAnt GIL 并没有真正允许共享内存,所以你基本上是在运行两次串行代码。
  • 请注意,您可以使用 multiprocessing 使应用程序更快 - 这可以避免 GIL 问题。
猜你喜欢
  • 2013-06-25
  • 2018-03-03
  • 1970-01-01
  • 2016-10-29
  • 1970-01-01
  • 2015-08-21
  • 1970-01-01
  • 2019-09-16
  • 2021-06-03
相关资源
最近更新 更多