如何让我的代码在多个内核上运行?

发布于 2024-07-05 19:14:49 字数 302 浏览 4 评论 0原文

我用 C# 构建了一个应用程序,希望针对多核进行优化。 我有一些线程,我应该做更多吗?

更新了更多详细信息

  • C# 2.0
  • 在 Windows Vista 和 Windows Server 2003 上运行

再次更新

  • 此代码作为服务运行
  • 我不想拥有完整的代码...我的这里的目标是获得您的经验以及如何开始。 就像我说的,我已经使用了线程。 我还能做什么?

I have built an application in C# that I would like to be optimized for multiple cores. I have some threads, should I do more?

Updated for more detail

  • C# 2.0
  • Run on Windows Vista and Windows Server 2003

Updated again

  • This code is running as a service
  • I do not want to have the complete code... my goal here is to get your experience and how to start. Like I say, I have already use threads. What more can I do?

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

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

发布评论

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

评论(6

陪你搞怪i 2024-07-12 19:14:49

对于 C#,开始学习 LINQ 的处理方式,然后使用 Parallel LINQ 库及其 .AsParallel() 扩展。

For C#, start learning the LINQ-way of doing things, then make use of the Parallel LINQ library and its .AsParallel() extension.

揽清风入怀 2024-07-12 19:14:49

了解您要解决的问题、您的应用程序及其算法中的并行性(或并行性的潜力)比线程同步、库等的任何细节都重要得多。

首先阅读 并行编程模式(重点关注“发现并发”和更高级别的设计问题),然后继续多处理器编程的艺术(从理论基础开始的实践细节)。

Understanding the parallelism (or potential for parallelism) in the problem(s) you are trying to solve, your application and its algorithms is much more important than any details of thread synchronization, libraries, etc.

Start by reading Patterns for Parallel Programming (which focuses on 'finding concurrency' and higher-level design issues), and then move on to The Art of Multiprocessor Programming (practical details starting from a theoretical basis).

萌辣 2024-07-12 19:14:49

为了能够更有效地利用多个核心,您应该将工作划分为可以并行执行的部分,并使用线程在核心上划分工作。 你可以使用线程、后台工作者、线程池等

To be able to utilize multiple cores more efficiently you should divide your work up in parts that can be executed in parallel and use threads to divide the work over the cores. You could use threads, background workers, thread pools, etc

自由范儿 2024-07-12 19:14:49

您可能想查看 .NET 的并行扩展

http://msdn.com/concurrency

You might want to take a look at the parallel extensions for .NET

http://msdn.com/concurrency

玉环 2024-07-12 19:14:49

您可能想阅读 Herb Sutter 的专栏“有效并发”。 您可以在此处找到这些文章以及其他文章。

You might want to read Herb Sutter's column 'Effective Concurrency'. You'll find those articles here, with others.

死开点丶别碍眼 2024-07-12 19:14:49

我总结说,编写高度优化的多线程进程比仅仅将一些线程混合在一起要困难得多。

我建议从以下步骤开始:

  1. 将工作负载拆分为离散的并行可执行单元
  2. 测量和表征工作负载类型 - 网络密集型、I/O 密集型、CPU 密集型等 - 这些成为工作池策略的基础。 例如,对于网络密集型应用程序,您可以拥有相当大的工作线程池,但是对于 CPU 密集型任务来说,拥有比硬件线程更多的工作线程是没有意义的。
  3. 考虑使用队列/数组或 ThreadWorkerPool 来管理线程池。 前者比后者更细粒度控制。
  4. 如果可以的话,学会选择异步 I/O 模式而不是同步模式 - 释放更多的 CPU 时间来执行其他任务。
  5. 努力消除或至少减少围绕争用资源(例如磁盘)的序列化。
  6. 最大限度地减少 I/O,在尽可能短的时间内获取并保持最低级别的锁。 (读/写锁是你的朋友)
    5.梳理该代码,确保资源按一致的顺序锁定,以最大限度地减少致命拥抱。
  7. 疯狂地测试 - 多线程应用程序中的竞争条件和错误很难排除故障 - 通常您只能看到大屠杀的取证后果。

请记住,同一应用程序的多线程版本的性能完全有可能比单线程版本差。 良好的工程测量没有任何借口。

I'd generalize that writing a highly optimized multi-threaded process is a lot harder than just throwing some threads in the mix.

I recommend starting with the following steps:

  1. Split up your workloads into discrete parallel executable units
  2. Measure and characterize workload types - Network intensive, I/O intensive, CPU intensive etc - these become the basis for your worker pooling strategies. e.g. you can have pretty large pools of workers for network intensive applications, but it doesn't make sense having more workers than hardware-threads for CPU intensive tasks.
  3. Think about queuing/array or ThreadWorkerPool to manage pools of threads. Former more finegrain controlled than latter.
  4. Learn to prefer async I/O patterns over sync patterns if you can - frees more CPU time to perform other tasks.
  5. Work to eliminate or atleast reduce serialization around contended resources such as disk.
  6. Minimize I/O, acquire and hold minimum level of locks for minimum period possible. (Reader/Writer locks are your friend)
    5.Comb through that code to ensure that resources are locked in consistent sequence to minimize deadly embrace.
  7. Test like crazy - race conditions and bugs in multithreaded applications are hellish to troubleshoot - often you only see the forensic aftermath of the massacre.

Bear in mind that it is entirely possible that a multi-threaded version could perform worse than a single-threaded version of the same app. There is no excuse for good engineering measurement.

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