时间:2019-03-17 标签:c#parallelizesimulation

发布于 2024-09-25 08:45:47 字数 318 浏览 5 评论 0原文

我有一个模拟引擎,我想首先对其进行并行化,然后将其开发为 C# 中的 Web 服务。这是一个密集的模拟,需要大量的 CPU 和 RAM,我想将每次运行拆分到一个单独的线程上。为了让您更好地了解模拟可以运行 100 次,每次运行我都会收集一些结果。收集每次运行的结果然后将它们整理成一个大文件是很简单的。因此,如果我有一台具有 4 个核心的多核机器,例如,想法是在每个核心上运行 4 次,然后再运行 4 次……等等。我已经在较新版本的 .net 中阅读了一些有关并行扩展的内容。我可以在 3.5 中实现相同的目标,还是迁移到 4.0 会更好?如果我将其作为网络服务,还有什么需要注意的吗?任何进一步的想法或建议都非常受欢迎。

I have a simulation engine that I would like to parallelize first and later develop as a web service in C#. This is an intensive simulation that requires a lot of CPU and RAM and I would like to split each run on a separate thread. To give you a better idea the simulation can run 100 runs and for each run I collect some results. It would be straightforward to collect the results from each run and then collate them into one big file. So if I have a multi-core machine with 4 cores for example the idea is to run 4 runs on each core and then another 4 ... etc. I have read a few things about Parallel Extensions in the newer version of .net. Could I achieve the same things in 3.5 or would it be better to move to 4.0? Also anything to watch out if I make this a web service? Any further ideas or suggestions are more than welcome.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

农村范ル 2024-10-02 08:45:47

您最好迁移到 4.0 并使用 TPL。这样你就可以创建一个 Task<>运行每个模拟并让 TPL 调度程序在资源可用时适当地安排它们。运行完成后,您可以将结果放入 ConcurrentCollection<> 中。一旦一切都完成,就对它们运行排序(如果这对您来说很重要,您甚至可以在其他任务运行时对另一个任务进行排序。

在 3.5 中,大部分调度工作将留给您,API 也不再需要)您也不会有任何并发​​集合,这可能会使结果整理变得更加简单(

如果您将其设为 Web 服务,则 永远不要低估编写正确且高性能的并发集合的复杂性)。那么您必须了解服务的使用情况以及这将如何影响 Web 服务 从本质上讲,您可以改善单个请求延迟,但这可能会降低整体吞吐量,请参阅以下链接以获取对此的讨论。

http://blogs.msdn.com/b/pfxteam /archive/2010/02/08/9960003.aspx

You would be better off moving to 4.0 and using the TPL. That way you could create a Task<> to run each simulation and have the TPL scheduler schedule them appropriately as resources become available. As the runs finish you could put the results into a ConcurrentCollection<> and once everything had finished run a collation on them (you could even have another Task collating while the others were running if this turned out to be important to you.

In 3.5 much of the scheduling work would be left to you and the APIs aren't as clean for creating tasks. You'd also not have any of the concurrent collections which might make result collation a lot simpler (never underextimate the complexity of writing a concurrent collection thats both correct and performant).

If you make this a web service then you have to understand the usage of the service and how that will effect the web service. Essentially you can improve individual request latency but this may come at the cost of a degredation in overall throughput. See the following link for a discussion of this.

http://blogs.msdn.com/b/pfxteam/archive/2010/02/08/9960003.aspx

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文