Quote:Original post by AntheusQuote:Original post by Raghar
Using CPU power unnecessary just increases power consumption for no reason. Some people like playing games and render on background, unnecessary consumption of CPU resources might alienate them.
There is X work to do. That determines the CPU load. If done on one or 16 cores makes no difference.
Imagine there is A work to do, there are B parallel working units each require A. The total work on single core would be B*A, total work on B cores would be A. With 100 threads a sheduler that can use 8 CPUs could offload 12-13 work units to each core. Because 1/100 < 1/12, the possibility of a GUI/input thread to commit action is higher and the program would be more snappy with great throughput.
Of course a computer with 256 cores would work even better.
Quote:Quote:Isn't sheduler much better than a single programmer?
Nope. It's merely more convenient, at possibly high run-time cost.
I agree it's convenient, however the programmer can't know runtime characteristic of other programs that runs on the same OS. Sheduler do. In addition the sheduler can switch cores to evenly load each core. (Basically threads with the same core mask are running on the same core, however the physical core changes without threads knowing anything.)
Quote:Quote:I recall that in my Java programs, I try to do ONLY things that thread must do, and then yield quickly. (Or interrupt the thread willingly. OS looks more smooth with threads that sometimes sleep, than with 200 threads that compete for CPU resources. With 200 CPUs there is about 200 speedup. ^_^)
Interestingly enough, Java threads have more in common with co-routines than system threads. They are light-weight, and do not necessarily have a 1:1 mapping to OS threads. Context switches are much less expensive (relatively). Same goes for timing. Same goes for other VMs, or similar light-weight threading run-times.
If anything, hundreds of threads in Java are much less of an issue than equivalent in native application (not that there would be realistic or practical need for that many).
Is that so? I run a test few minutes ago, Windows reported 300+ threads working heavily and competing for resources. If they are using non native threads they are hiding it fairly well. (Sun Java 6 properly updated)
I also recall a Java bug that was caused by changing OS thread shedulling parameters.
An application that was designed to run on cluster, or as parallel as possible to scale well on things like Larrabee, or dual oct core CPUs, basically needs as many native threads as possible without any synchronization whatever.
