问题标签 [parallel-processing]

我对使用内置并行性/并发性的语言的可能性感到非常兴奋，例如stackless python和erlang，并且坚信我们都必须在不久的将来朝着这个方向前进 - 或者会想要因为这将是获得可扩展性和性能的好方法/简单方法。

但是，我非常习惯于以线性/串行/OOP/功能方式思考解决方案，以至于我正在努力以一种值得使用并发的方式来解决我的任何领域问题。我怀疑我只是需要忘掉很多东西，但我想我会问以下问题：

• 您是否在 stackless 或 erlang 或其他中实现了任何相当大的东西？
• 为什么这是一个不错的选择？这是一个不错的选择吗？你还会做吗？
• 您的问题的哪些特征意味着并发/并行是正确的？
• 您是否重新提出了现有问题以利用并发/并行性？和
• 如果是这样，如何？

有谁愿意分享经验吗？

对于相对粗粒度的并行处理（数据传输可以在 100 Mbit 以太网中完成），您认为适用于 Windows 和 Linux 的哪个中间件最好？科尔巴？MPI1? MPI2? XML-RPC/SOA/WSDL？自定义网络协议？Java RPC？Python RPC？其他的？

我需要并行化一个简单的密码破解程序，以便在 n 处理器系统上使用它。我的想法是创建 n 个线程并在它们完成时为它们提供越来越多的工作。

知道线程何时完成的最佳方法是什么？互斥体？在其他线程运行时不断检查这个互斥锁不是很昂贵吗？

我需要抓取（使用 scrAPI）400 多个网页 ruby​​，我的实际代码是非常连续的：

实际上代码有点不同（异常处理和东西）。

我怎样才能让它更快？如何并行下载？

我熟悉 Java 中的并发编程，它为此提供了很多工具。然而，C++ 并发编程并不是那么容易上手的。

在 C++ 上开始并发编程的最佳方式是什么？是否有任何不错的库可以包装并发编程原语并为您提供更高级的构造？

我尝试了 QtConcurrent，它为您提供了不错的 MapReduce 功能，但它严重偏向于使用 Qt 进行并发计算，因此如果您不想使用 Qt，这不是一个好的选择。

还有其他类似的库吗？人们在这里使用什么？

提前感谢您的帮助，斯内格

使用 GNU make，是否可以在使用“--jobs”选项时创建一组永远不会同时安排的目标？

背景：

为了使这更具体一点，请考虑以下形式的生成文件

我需要做的主要事情是确保 e1、e2 和 e3 永远不会同时被处理，因为它们在资源有限的嵌入式设备上做一些工作。如果其中多个同时执行，它们会崩溃。p1、p2 和 p3 可以与任何东西并行执行，包括任何 e* 作业。

请注意，实际的 makefile 有几千个目标，其依赖关系树大约有 10 级深，所以我希望有一种方法可以做到这一点，（a）不需要连续运行 make 并且（b）保留的好处在生成文件中编码依赖树。

我有 D2 程序，在其当前形式下，它是单线程的，并且对于该程序的外循环的每次迭代，在内循环中调用相同的纯函数大约 10 到 100 次。调用之间没有数据依赖关系，即没有调用使用来自任何其他调用的结果。总的来说，这个函数被调用了数百万次，是我程序的主要瓶颈。参数几乎每次都是唯一的，因此缓存无济于事。

乍一看，这似乎是并行化的完美候选者。唯一的问题是该函数每次调用只需要大约 3 微秒，远低于创建新线程的延迟，并且不高于将作业添加到任务池的开销（意思是，获取互斥体，分配内存到保存有关任务的信息，处理可能的任务池队列争用等）。有没有什么好的方法可以利用这种细粒度的并行性？

这个问题我想了很久：

您能否利用拥有多个 CPU 的事实在多核机器上构建更快的基础数据结构（即链表、哈希表、集合、跳过列表、布隆过滤器、红黑树等）？

我对 pthreads 做了一些初步试验，发现 pthread_create() 大约需要 30us，但是一个简单的 hash_map 插入比在单核上花费的时间要少得多。因此，我很难想象创建一个更快的 hash_map<>，因为同步原语和线程创建是如此缓慢。我也可以想象树遍历和并行平衡，但同样，同步原语似乎使运行时间更长，而不是更短。

我仍然觉得“我有更多的 CPU，因此，我应该能够更快地做到这一点”对我来说仍然很直观，但我不能完全围绕该陈述的证明或反证明。我在 C++ 中进行了相当多的实验，但现在我怀疑其他语言可能会为此任务提供更好的解决方案（erlang？）。想法？

编辑细节：我认为有几种经常使用的编程/数据结构范例可能会加快速度。例如，我发现自己经常编写基本上看起来像这样的代码（其中真实数据已替换为“rand()”）

这种范式经常用于名称-值设置和配置数据、批处理等。10 倍（或更多）的查找/插入比率使传统的 hash_map<> 成为此类操作的理想选择。

这可以很容易地分成两半，一个插入阶段和一个查找阶段，在并行世界中，两半之间可能会有一些“刷新队列”操作。更困难的是交错插入 + 查找版本：

在这种情况下，只要在每次查找之前刷新插入队列，插入就可以是异步的，并且如果 LOOKUP_RATIO 足够大（例如，>1000），那么它就变得与上面的批处理示例非常相似，但有一些排队。虽然，排队意味着同步原语。

想象一下，下面的代码片段：

因此，可以通过以下方式“并行”进行查找：

在应用程序的某些部分需要完全并行的情况下，F# 是否优于 C#？

我的主要语言是 C#，我正在编写一个应用程序，其中构建在应用程序 (C#) 之上的核心功能必须并且计划非常并行。

我在 F# 中实现这些类更好吗？

我知道 C# 得到了很多并行编程支持，但是 AFAIK 仍然没有用于副作用验证的构造，对吗？

我认为既然 C# 已经布局，那就更棘手了。但是有计划把它放进去吗？还是 F# 是唯一具有副作用验证构造的 .NET 语言？