英文:
Will my program get more cpu time if it has more threads
问题
如果当前内核正在调度60个线程，它们属于3个进程：
A：10个线程
B：20个线程
C：30个线程
它们都在进行计算（没有磁盘IO）
C是否会完成更多的工作，B完成的工作是否比A多？
对我来说，这似乎不太公平。如果我是一个不负责任的程序员，我可以只是创建更多的线程来占用更多的CPU资源。
这与Go语言有什么关系：
在Go中，通常go调度器具有与CPU核心数量相等的线程池。如果一个进程有更多的线程，为什么这是有意义的？
英文:
If currently kernel is scheduling 60 threads, they belong to 3 processes:
> A: 10 threads
>
> B: 20 threads
>
> C: 30 threads
And they are all doing computing (no disk IO)
Will C gets more stuff done than B, and B gets more stuff done than A?
It does not seem very fair to me. If I am a irresponsible programmer, I can just spawn more threads to eat more CPU resource.
How this relate to golang:
In go, typically the go scheduler has a thread pool of #of-CPU-cores threads. Why does this make sense if a process with more threads gets more stuff done?
答案1
得分: 1
你描述的情况是一个负载过重的机器。只有在CPU没有空闲时间的情况下，具有更多线程的进程才能完成更多的工作。
Go语言并不是为了与其他进程争夺过载CPU的更大份额而设计的。如果你希望参与这样的争夺，可以自由地将GOMAXPROCS设置为任意数字。
在一个更典型的系统中，总工作量小于总CPU时间的情况下，具有8个线程和30个goroutine的Go进程的性能与同时运行的具有30个线程的进程大致相当。
英文:
The situation you describe is an overloaded machine. It is only true that the process with more threads will get more work done if the CPU has no spare time.
Go was not designed to fight other processes for a greater share of an overloaded CPU. You are free to set GOMAXPROCS to any number you like if you desire to participate in such a fight.
In a more typical system where the total work is less than the total CPU time; a Go process with 8 threads and 30 goroutines will perform about equally to a process with 30 threads running at the same time.
答案2
得分: 0
这对我来说似乎不太公平。如果我是一个不负责任的程序员，我可以创建更多的线程来占用更多的CPU资源。
你也可以分配你的全部空闲内存，导致操作系统崩溃并劫持网络卡。你可以做各种事情，但是谁会想使用你的软件呢？
这与Golang有什么关系呢？在Go中，通常go调度器具有与CPU核心数量相等的线程池。为什么如果一个进程有更多的线程，它能完成更多的工作呢？
Golang的goroutine基本上是一个线程池。每个goroutine都是线程池的工作项。许多因素会导致线程池线程阻塞，比如使用同步IO、等待非自旋锁和手动休眠或让出。在这些常见情况下，拥有比CPU核心更多的线程通常会提高应用程序的性能。
请注意，并非所有的IO都是磁盘IO。向控制台写入是一个IO操作，但它并不是真正的"磁盘IO"。
另一件事是，上下文切换可能不会占用CPU的大部分时间，拥有更多的线程也可能不会使任务的吞吐量降低。因此，在这种情况下，拥有更多的线程意味着您的并行性更高，而且您不会损失性能。这是一种常见的情况。如今，在线程之间进行上下文切换非常廉价。拥有比核心稍多一些的线程可能不会对性能产生负面影响或降低性能。
英文:
> It does not seem very fair to me. If I am a irresponsible programmer,
> I can just spawn more threads to eat more CPU resource.
you can also allocate your entire free memory, cause OS-failure and hijack the network card. you can do sorts of things but then who will want to consume your softwares?
> How this relate to golang: In go, typically the go scheduler has a
> thread pool of #of-CPU-cores threads. Why does this make sense if a
> process with more threads gets more stuff done?
Golang goroutines are basically a threadpool. each goroutine is a thread-pool work item. many things can make your thread-pool thread block, like using synchronous IO, waiting on a (non-spin-lock) lock and manually sleeping or yielding. in these cases, which are very common, having more threads than CPU's usually increase the performance of your application.<br/>
Do note that not all IO is a disk IO. writing to your console is an IO operation, but it isn't really a "Disk IO".<br/><br/>
another thing is that context switching may not consume a large portion of your CPU, and having more threads may not make your tasks-throughput degrade. so in this case having more threads means that your parallelism is higher, and yet you don't loose performance. this is somewhat common situation. context switching between threads these days is very cheap. having a bit more threads than your cores may not necessary kill your performance or degrade it in some way.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论