.net 我可以同时运行多少个线程?

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/4828296/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-09-03 15:11:39  来源:igfitidea点击:

How many threads can I run concurrently?

.netvb.netmultithreading.net-3.5

提问by Mawg says reinstate Monica

A comment to another of my questionssays that I can only run "so many" threads concurrently, a notion which I have seen elsewhere.

对我的另一个问题的评论说我只能同时运行“这么多”线程,这是我在其他地方看到的概念。

As a threading novice, how can I determine the maximum number of threads to use? Or is this a "how long is a piece of string" question? What does it depends on? Hardware config or what?

作为线程新手,如何确定要使用的最大线程数?或者这是一个“一段字符串有多长”的问题?它取决于什么?硬件配置还是什么?

(VB in MS Visual Studio with .Net 3.5, if that matters)

(如果重要的话,MS Visual Studio 中的 VB 和 .Net 3.5)



Update: is anyone aware of any s/w tool which could suggest a number of threads (or tasks), or should I just code my own which keeps trying different numbers until throughput drops?

更新:是否有人知道任何可以建议多个线程(或任务)的软件工具,或者我应该自己编写代码,它会不断尝试不同的数字直到吞吐量下降?



[Upperdate] Almost seven years later & we now have a software recommendations site, so I askedif there is a tool to help with this.

[更新] 差不多七年后,我们现在有了一个软件推荐网站,所以我是否有工具可以帮助解决这个问题。

采纳答案by Trinidad

It depends on hardware as you're (probably) not using a theoretical computer but a physical hardware one, so you have limited resources.

这取决于硬件,因为您(可能)使用的不是理论计算机而是物理硬件,因此您的资源有限。

Read: Does Windows have a limit of 2000 threads per process?

阅读:Windows 是否有每个进程 2000 个线程的限制?

Furthermore, even if you could run 5000+ threads, depending on your hardware, that could run much slower than a 10 thread equivalent program. I think you should take a look at thread pooling.

此外,即使您可以运行 5000 多个线程(取决于您的硬件),其运行速度也可能比 10 线程等效程序慢得多。我认为你应该看看线程池

回答by Shiv Kumar

Typically, the number of threads the run truly concurrently is determined by the number of CPUs and CPU cores (including hyper threading) you have. That is to say that at any given time the number of threads running (in the operating system) is equal to the number of "cores".

通常,真正并发运行的线程数取决于您拥有的 CPU 和 CPU 内核(包括超线程)的数量。也就是说,在任何给定时间(在操作系统中)运行的线程数等于“内核”数。

How many threads you can run concurrently in your app depends on a large number of factors. The best (lay man's) number would be the number of cores on the machine but of course that's like pretending no one (no other application) else exists :).

您可以在应用程序中同时运行多少线程取决于大量因素。最好的(外行)数字是机器上的内核数,但当然这就像假装没有其他应用程序(没有其他应用程序)存在:)。

Frankly, I'd say do a lot more study on multi-threading in .NET/Windows because one tends to do more "damage" than good when one doesn't have a really solid understanding. .NET has the concept of a thread pool and you need to know how that works in addition to Windows.

坦率地说,我会说对 .NET/Windows 中的多线程进行更多研究,因为当一个人没有真正扎实的理解时,往往会做更多的“损害”而不是好处。.NET 有线程池的概念,除了 Windows 之外,您还需要知道它是如何工作的。

In .NET 3.5/4.0 you should be looking at Tasks (Task Parallel Library) as the library does a much better job of determining how many threads (if at all) to spawn. With the TPL the threadpool gets a major overhaul and it is a lot smarter about spawning threads and task stealing etc. But you typically work with Tasks and not threads.

在 .NET 3.5/4.0 中,您应该查看任务(任务并行库),因为该库在确定要生成的线程数(如果有的话)方面做得更好。使用 TPL,线程池得到了重大改进,它在生成线程和任务窃取等方面更加智能。但您通常使用任务而不是线程。

This is a complex area and as a result, the .NET framework introduced Tasks so as to abstract programmers from threads and therefore allowing the runtime to be smart about this while the programmer just say what she wants and not so much about how to do it.

这是一个复杂的领域,因此 .NET 框架引入了任务,以便将程序员从线程中抽象出来,因此允许运行时对此很聪明,而程序员只说她想要什么而不是如何去做.

回答by Dani Cricco

Each thread consumes more memory (kernel stack, thread environment block, thread-local, stack....). AFAIK there are no explicit limit in Windows, therefore the constrain will be memory (probably the stack for each thread).

每个线程消耗更多内存(内核堆栈、线程环境块、线程本地、堆栈....)。AFAIK 在 Windows 中没有明确的限制,因此约束将是内存(可能是每个线程的堆栈)。

In Linux threads are more like processes (with shared memory) and you're constrained by:

在 Linux 中,线程更像是进程(具有共享内存)并且您受到以下限制:

cat /proc/sys/kernel/threads-max

回答by williambq

A pretty good rule of thumb when running intensive tasks is to run the same number as your physical core count.

运行密集型任务时,一个很好的经验法则是运行与物理核心数相同的数量。

Yes, you can run more tasks, but they will wait for resources (or threads in a thread pool) and your box, regardless of size can't quite allocate all of a cpu core resources 100% of the time to a thread due to background/other processes. So the more tasks you instantiate, the more threads you spawn, as they surpass actual possible concurrent threads (1 per core), the more resource management, queuing and swapping will occur.

是的,您可以运行更多任务,但它们将等待资源(或线程池中的线程)和您的盒子,无论大小如何,都无法在 100% 的时间内将所有 CPU 核心资源分配给线程,原因是后台/其他进程。因此,您实例化的任务越多,您产生的线程就越多,因为它们超过了实际可能的并发线程(每个内核 1 个),就会发生更多的资源管理、排队和交换。

A test we did where I work now using a viral pattern to launch additional tasks found that optimal was pretty close to the cpu count as a cap. Tasks launched at a one-to-one ratio with the physical core count ran at about 1 minute per task to complete. Set at double the cpu count, task time went from 1 minute average to about 5 minutes average time to complete. It gets geometrically slower the more tasks initiated past core count.

我们在我现在工作的地方进行的一项测试使用病毒模式来启动其他任务,发现最优值非常接近 cpu 计数作为上限。以一比一的比率启动的任务与物理核心数运行每个任务大约需要 1 分钟才能完成。设置为 cpu 计数的两倍,任务时间从平均 1 分钟增加到平均约 5 分钟完成。超过核心数启动的任务越多,它的速度就会越慢。

So for example, if you have 8 physical cores, 8 tasks (and using TPL, essentially 8 concurrent threads in active process) should be the fastest. There is your main thread or process which creates the other tasks, and other background processes, but if the box is pretty isolated for your resource exploitation pleasure, those will be fairly minimal.

因此,例如,如果您有 8 个物理内核,那么 8 个任务(并且使用 TPL,本质上是活动进程中的 8 个并发线程)应该是最快的。您的主线程或进程会创建其他任务和其他后台进程,但是如果为了您的资源开发乐趣,该框非常孤立,那么这些将相当少。

The upside of programming your task cap based on core count as you chew tasks off a queue or list so when you deploy the application on different sized boxes, it adjusts itself automatically.

当您从队列或列表中咀嚼任务时,根据核心数对任务上限进行编程的好处是,当您将应用程序部署在不同大小的盒子上时,它会自动调整自身。

To determine this programmatically, we use

为了以编程方式确定这一点,我们使用

var CoreCount = System.Environment.ProcessorCount / 2;

var CoreCount = System.Environment.ProcessorCount / 2;

Why divide by two, you ask? Because nearly all modern processors use logical cores or hyperthreading. You should find with your own testing that if you use the Logical count, your overall speed per task, and thus the whole process, will drop significantly. Physical cores is the key. We couldn't see a quick way to find physical vs logical but a quick survey of our boxes found this to be consistently true. YMMV, but this might get your pretty far pretty fast.

你问为什么要除以二?因为几乎所有现代处理器都使用逻辑内核或超线程。您应该通过自己的测试发现,如果您使用逻辑计数,则每个任务的整体速度以及整个过程将显着下降。物理内核是关键。我们看不到找到物理与逻辑的快速方法,但对我们的盒子的快速调查发现这始终是正确的。YMMV,但这可能会让你很快。

回答by Oded

It very much depends on the machine - CPU and memory are the main limiting factors (though OS limits may come into it).

这在很大程度上取决于机器 - CPU 和内存是主要的限制因素(尽管可能会受到操作系统限制)。

In regards to .NET the thread poolconfiguration also comes into play.

对于 .NET,线程池配置也开始发挥作用。

回答by Retro Gamer

From my own experience, when using threads a good rule of thumb for increased performance for CPU bound processes is to use an equal number of threads as cores, except in the case of a hyper-threaded system in which case one should use twice as many cores. The other rule of thumb that can be concluded is for I/O bound processes. This rule is to quadruple the number threads per cores, except for the case of a hyper-threaded system, then one can quadruple the number of threads per core.

根据我自己的经验,当使用线程来提高 CPU 绑定进程的性能时,一个很好的经验法则是使用与内核相同数量的线程,除非在超线程系统的情况下,在这种情况下应该使用两倍的线程数核心。可以得出的另一个经验法则是针对 I/O 绑定进程。此规则是将每个内核的线程数增加四倍,除了超线程系统的情况外,每个内核的线程数可以增加四倍。

回答by Q13E5

I was able to run 4 threads at once on my current old CPU (2005) Using EVGA's CPU burner before my CPU buzzer sounded off (Programmed inside BIOS menu) Meaning i hit over 90*c. Keep in mind we are talking about Data threads working all at once. a good example would be having multiple programs open at once. But overall it really depends how good your CPU is with multitasking. (in other words can handle many active threads) A safe way to test is is to download "ocscanner (By EVGA)" and "CPU Thermometer" use CPU burner inside OC Scanner While testing, make sure your temperature does not rise over 90*c (or any temperature you feel safe at) and look at your current number of threads you have running threw your CPU. start at 2 threads, wait 3-5 minutes while watching the CPU temperature, add another thread, repeat. (DO NOT PUSH YOUR LUCK!!!)(DO NOT ATTEMPT IF CPU THERMOMETER CAN NOT DETECT YOUR TEMPERATURE!!!)

在我的 CPU 蜂鸣器响起之前,我能够在我当前的旧 CPU(2005)上一次运行 4 个线程(在 BIOS 菜单中编程)这意味着我达到了 90*c。请记住,我们正在谈论同时工作的数据线程。一个很好的例子是同时打开多个程序。但总的来说,这真的取决于你的 CPU 在多任务处理方面有多好。(换句话说,可以处理许多活动线程)一个安全的测试方法是下载“ocscanner (By EVGA)”和“CPU Thermometer”,使用 OC Scanner 内的 CPU 刻录机 测试时,请确保您的温度不超过 90* c(或您认为安全的任何温度)并查看您当前正在运行的线程数,从而抛出了 CPU。从 2 个线程开始,等待 3-5 分钟,同时观察 CPU 温度,添加另一个线程,重复。