在多进程多处理器环境

我经历了几个问题，如POSIX Threads on a Multiprocessor System和Concurrency of posix threads in multiprocessor machine和Threads & Processes Vs MultiThreading & Multi-Core/MultiProcessor : How they are mapped?在多进程多处理器环境

基于这些和其他一些维基文章去选择的线程数，我相信，有三个基本的作品即一个系统，输入，处理和输出

对于CPU - CPU密集型的线程绑定处理号（申请号*每个应用程序线程）应该是处理器的核的apprx 1〜1.5倍的数量。
输入和输出线程必须足够大，以消除任何瓶颈。例如，对于基于查询/查询确认和响应/响应确认模型的通信系统，在I/O等待状态中不能浪费时间。
如果对动态内存有很大的要求，最好使用比线程更多的进程（以避免内存同步升级）。

这些参数是否相当一致，同时确定我们应用程序中的线程数量？我们是否需要查看其他参数？

来源

2012-04-13 Anerudhan Gopal

'1至1.5倍核心数量' - 这看起来是OS /语言相关的。例如，在Windows/C++中，如果有大量CPU密集型任务，则最优化似乎要比性能分布非常小的内核数量多两倍。如果这样的环境，看起来你可能只是分配一个池中的64个线程，而不会打扰核心的数量。

'查询/查询-Ack和响应/响应 - ack模型，时间不能浪费在I/O等待状态中' - 这对于大多数网络具有高延迟的协议是不可避免的。延迟是由'乒乓'协议&强制执行的，所以不可避免地会有I/O等待。异步I/O只是将这种等待转移到内核 - 它仍然存在！

对动态内存的大量需求，它比线程更适合处理更多的进程 - 并非如此。 “对动态内存的大量需求”通常意味着大数据缓冲区将被移动。大型缓冲区只能通过引用有效地移动。由于共享内存空间，这在线程之间非常简单快捷。通过流程，你会陷入尴尬和缓慢的进程间通信。

'确定我们应用程序中的线程数量' - 好吧，在几个方面很困难。给定一个未知的架构，设计。语言和操作系统，我唯一的建议是尝试尽可能灵活和可配置地构建一切。如果您有线程池，请将其大小设置为可调整的运行时参数。如果您有对象池，请尝试设计它，以便您可以更改其深度。有一些默认值可用于测试框，然后在安装时或运行时，可以对特定系统进行任何特定的更改和调整。

灵活/可配置设计的另一件事情是，你可以，在测试时，调整路程，修复许多建筑师，设计师，开发商和，最重要的是，客户

做出不正确的决策，假设和瞎猜

来源

2012-04-13 10:33:59

感谢马丁..但为什么操作系统有它的作用？是否因为指令（调度等）的最终执行顺序取决于操作系统？我猜想，管道衬里和无序执行是硬件线程的属性..请纠正我，如果我错了.. – 2012-04-13 10:39:53

OS是界面的基础。不可避免地，性能差异将浮出水面。其中之一是调度算法。线程调度的最终顺序取决于操作系统，是的。管道衬里和无序执行是硬件优化，是的。 – 2012-04-13 10:47:59

再一次感谢..想想我最好的前进方向是开放性的想法...... :) – 2012-04-13 10:53:26

在多进程多处理器环境

回答

相关问题