Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
My C# Brute Force programm uses 20% of CPU in runtime. Im only using 1 Backgroundworker for it. If I would spread this task into several parts and insert them in 7-8 Backgroundworkers, would that be faster and use more CPU?
The short answer is maybe.
The long answer is that it depends upon multiple factors:
Is your task CPU bound, if it's not the CPU holding up the task then multithreading probably won't help.
How many cores does your processor have and does it have hyperthreading enabled: if it only has one thread, trying to multithread will actually slow it down; if it has more, you can use as many threads in your program as you have available in the OS. (I suggest that you use the Environment.ProcessorCount value to determine the number of threads that you start).
How much cross-thread synchronisation will have to occur. If your threads are spending ages waiting to write into locked shared variables or passing data between them, it will likely slow your application down.
My main suggestion would be to test it!
You can easily time the execution time of a segment of code fairly accurately using the intuitive Stopwatch class.
Finally, you might want to try using a Thread[] rather than background workers, in general, these have lower overheads so are slightly quicker.
I tested the word "stack". One time with only 1 Backgroundworker the second time with 5. Backgroundworker 1 searches for a word with the length of 1. background worker 2 for a word with the length of 2 and so on.
Word: stack
Backgroundworker Time
1 1min 8sec
5 35sec
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 months ago.
Improve this question
Reading about how does the OS handle the executables, I couldn't figure out if is better to use one executable with many threads inside or use many independent executables. The same task is performed, but I need to process many requests. Is there an executable limits to run simultaneous threds? Does it matter or every OS task goes to same CPU queue and doesnt matter the source executable?
Which is better? One with many threads or many executables? If could give an explanation or share some doc I would be greateful.
As far as the OS scheduling them to CPUs, there's no difference; modern mainstream OSes (Windows / Linux / MacOS) use a 1:1 thread model so every user-space thread is a separately schedulable OS task, not "green threads".
Solaris did or does have an N:M thread model, where user-space threads can be scheduled onto a "thread pool" of OS-level threads, with user-space context switching in some cases, but most other OSes don't.
So either way can take full advantage of all the CPU cores in the system; which is better depends on the use-case. Threads of a single process share memory (and file descriptors) with each other, and are cheaper to create than new processes. But still not that cheap; often you want to have a pool of worker threads that you wake up or queue work for, not start a new thread or process when a new request comes in.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
A CPU bound problem is one that requires a CPU for calculations.
An IO bound problem is one that requires to wait for the network, disk or input.
A single API request is IO bound.
The question is, when I make 100 API requests using a for loop, then, do we say that those requests are IO bound? Or do we say that they are CPU bound? Or do we say they are both CPU and IO bound?
Generally for IO bound we use multi threading or if we use single thread we can use async/await. Where as for a CPU bound process we use parallel programming or multi processing or async await with Task.Run.
For my example of 100 API requests in a for loop, is async/await better than multi threading or async/await+Task.Run or TPL?
If you have 100 I/O-bound operations, then the 100 operations as a whole are still I/O-bound.
CPU-bound is reserved for things that take a non-trivial amount of CPU time. Yes, technically incrementing a counter and starting the next I/O operation does execute CPU opcodes, but the loop would not be considered "CPU-bound" because the amount of time spent doing I/O is vastly higher than the amount of time doing CPU work.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I am recording multiple usb cameras using a 3rd party library. For that I record each camera’s data on a separate thread in C#. The problem is that application sometimes fails to fetch all the data.
Therefore I wonder if opening the C# threads might block my CPU threads as my CPU is 4 core / 4 threads. Are CPU cores/threads related to threads we initialize in C#?
Well, it depends on how you're going to accomplish this task. Recording camera video probably comes as a functionality of some 3rd party library, and that lib's API may already need your UI (main) thread in order to do do a task. If you're implementing your own low-level recording API and wish to receive data from that API then you may want to run data fetching in a separate thread simply using:
Task.Run(()=> {
// new thread running - your data fetching code here
});
This way, your main thread won't be blocked and awaiting on the new thread will yield the results from your camera API.
That totally depends on the way you are using the thread. I can think of at least 3 different scenarios - 1. Your cameraThread is defined as a high priority, and as such (even with the time slicing) takes 99% of the time. 2. Your cameraThread is run with the tasks thread pool, and as such it is being blocked and is blocking at random with other threads (resource contention). and 3. your camera recorder is happening in a low priority in the background.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions concerning problems with code you've written must describe the specific problem — and include valid code to reproduce it — in the question itself. See SSCCE.org for guidance.
Closed 8 years ago.
Improve this question
I am developing a WPF program which performs long running tasks in the background, using TPL's Parallel.ForEach.
I have an image control and when am trying to show an image, it seems that the image rendering happens in the thread pool, and since I use it intensively (via TPL Forech) the rendering is extremely slow.
Is there a way to perform the image rendering in higher priority or not in the thread pool ?
Parallel.ForEach is designed to use as much of your CPU as it can get hold of. If you don't want it to do that, then either don't use it (just run the long-running task in a single poll thread), or control the amount of your CPU which 'Parallel.ForEach' uses, by passing in a 'ParallelOptions' object to limit its appetite for CPU.
You also say you're running 'long running' tasks using Parallel.ForEach - bear in mind that it's designed for getting cpu-bound tasks finished quickly, not backgrounding things which are long-running because they're waiting for I/O (for example). From the symptoms though, it does sound like you're using it for the right thing, it's just that it's using more CPU than you want.
As far as trying to avoid the thread pool, I think you're barking up the wrong tree - it's just a collection of threads which already exist, designed to avoid the overhead of creating and destroying threads all the time - it's not a priority mechanism - what your two activities are fighting over is access to the CPU, not access to the thread pool.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I am just finding my way around parallel programming in C# and understood the significance of cores and true parallel programming.
But I still have a question:
Say I have a long running task does that mean this will be executed using threads from thread pool and in different cores for true parallel programming.
Or does it depend on the actual delegate that is passed onto the task?
I Hope my question is clear.
The delegate itself makes no difference. It is the TaskScheduler that matters.
The default TaskScheduler will run them via the ThreadPool.. to have them run synchronously, you would pass in a TaskScheduler instance that is currently being used.. such as the static TaskScheduler.FromCurrentSynchronizationContext.
True parallel programming requires multiple cores since threads must execute on separate threads to truly run in parallel.. In a single core system you can only achieve fake parallelism since different treads must share the core through allocated time slots. Other treads are waiting while the current thread is running on the single core.