none
Threading, performance boost or just the feeling of a performance boost? RRS feed

  • Question

  • Hello,

    I'm struggling with this question for weeks now..
    Let's say I still have a computer with 1 CPU/Core.

    If I work with several threads in my program, does this give me a performance boost or just the feeling of having a smoother program?

    Threading works with slicing, which means the cpu will give every thread a bit of time. which makes it look like several threads run simultaniously . So how can multiple threads be faster? Each thread simply has to take a much longer time to finish each time another thread is added to the "list", right?

    Regards,
    Aussie


    Thursday, April 17, 2008 2:21 PM

Answers

  • Threading is a hugely complex area, and there's no real answer to your question. It's true that only one thread can run at a time on a machine with only one CPU, and yes you're right the threads are scheduled on it and each gets their time slice (or quantum). However, there's no way to know the effect that multiple threads will have on performance without trying it out.

    You might find that if you have more threads then you'll get a higher proportion of quanta relative to other applications and thus finish faster.

    You might find that if you have more threads then you'll cause more context switches (the period of inactivity on the CPU where one thread is swapped for another) and thus finish slower.

    You might find that the scheduling and thus the results are affected by the other programs that are running.

    You might find the performance is different on different machines, or different versions of Windows.

    Generally the rule is not to use threading unless you have to. A typical case where you might want to is if you want to do some background work in a WinForms app but want to keep the UI responsive, or another case is if you have parallelizable tasks and you know there are likely to be multiple CPUs/cores in the target environment.

    Even in these cases it's better to let someone else manage the threads for you, e.g. using the BackgroundWorker class, or using the ThreadPool because explicit threading is hard, especially if you haven't done much of it before.
    Saturday, April 19, 2008 10:07 AM
  • On a single-core CPU, threading can only make your program's total execution time longer.  A legitimate use is to make your program "smoother".  You can keep your UI responsive while a background thread is executing a lengthy operation like a database query.  It could actually make the query take longer but rarely enough to make a noticeable difference.  Most of the time, your background thread will be stalled, waiting on the network card to deliver a response packet from the server.  Your user won't see a frozen "Not responding" window and think your program works better.
    Saturday, April 19, 2008 5:13 PM
    Moderator
  • Aussie, threads are most commonly used for three types of situations.

    1) For UI functions that make method calls to perform tasks that take a considerable amount of time. Without spawning another thread to complete the task the UI will hang until the work has been completed. By creating another thread the UI can repaint itself, respond to other user interaction as well as give updates on the status of the task running on the other thread.

    2) For completing multiple tasks whose execution time is not entirely dependent on the CPU. Web browsers spawn multiple threads to download various elements of a web page. Pictures, html pages, javascript includes or whatever else because the time it takes to complete these task is far more dependent on the delay between client and server communications over the network. By running multiple threads you help these delays occur concurrently rather than consequtively.

    3) Taking advantage of the number of cores on a users system. If the task you are trying to execute is solely processor work (say computing digits of pi for example) it only makes sense to create as many threads as there are cores. If it's a single core system, only one thread is necessary. Two threads at best won't make a noticable difference in processing time and at worst might even slow down the process some.
    Sunday, April 20, 2008 12:43 AM

All replies

  • Okay, you need to do some testing now. Here's a problem for you to try..

    Try multiplying two matrices of (rows,column) > 999 both ways.

     

    For thread way: u assign each thread, a row and a column. Then it multiplies and stores the result in result[,]

    Calculate the time taken both ways and conclude yourself. You start rows.count number of threads for thread way.

     

    My personal conclusion:

    For smaller problems, simple method wins (since there's overhead of thread creation) but for larger problems (mentioned above) thread method is suitable.

    Correct me if I'm wrong, I think n x CPU/Core (n>0) runs thousands of threads simultaneously but have set priorities for each thread. When trying to solve a huge problem with simple method (no threading) we have very limited numbers of threads created automatically at the kernel level, may be your threads don't get enough CPU attention to finish the job early. With more threads CPU gets forced to spend time on your app.

     

    Thursday, April 17, 2008 5:17 PM
  • Threading is a hugely complex area, and there's no real answer to your question. It's true that only one thread can run at a time on a machine with only one CPU, and yes you're right the threads are scheduled on it and each gets their time slice (or quantum). However, there's no way to know the effect that multiple threads will have on performance without trying it out.

    You might find that if you have more threads then you'll get a higher proportion of quanta relative to other applications and thus finish faster.

    You might find that if you have more threads then you'll cause more context switches (the period of inactivity on the CPU where one thread is swapped for another) and thus finish slower.

    You might find that the scheduling and thus the results are affected by the other programs that are running.

    You might find the performance is different on different machines, or different versions of Windows.

    Generally the rule is not to use threading unless you have to. A typical case where you might want to is if you want to do some background work in a WinForms app but want to keep the UI responsive, or another case is if you have parallelizable tasks and you know there are likely to be multiple CPUs/cores in the target environment.

    Even in these cases it's better to let someone else manage the threads for you, e.g. using the BackgroundWorker class, or using the ThreadPool because explicit threading is hard, especially if you haven't done much of it before.
    Saturday, April 19, 2008 10:07 AM
  • On a single-core CPU, threading can only make your program's total execution time longer.  A legitimate use is to make your program "smoother".  You can keep your UI responsive while a background thread is executing a lengthy operation like a database query.  It could actually make the query take longer but rarely enough to make a noticeable difference.  Most of the time, your background thread will be stalled, waiting on the network card to deliver a response packet from the server.  Your user won't see a frozen "Not responding" window and think your program works better.
    Saturday, April 19, 2008 5:13 PM
    Moderator
  • Aussie, threads are most commonly used for three types of situations.

    1) For UI functions that make method calls to perform tasks that take a considerable amount of time. Without spawning another thread to complete the task the UI will hang until the work has been completed. By creating another thread the UI can repaint itself, respond to other user interaction as well as give updates on the status of the task running on the other thread.

    2) For completing multiple tasks whose execution time is not entirely dependent on the CPU. Web browsers spawn multiple threads to download various elements of a web page. Pictures, html pages, javascript includes or whatever else because the time it takes to complete these task is far more dependent on the delay between client and server communications over the network. By running multiple threads you help these delays occur concurrently rather than consequtively.

    3) Taking advantage of the number of cores on a users system. If the task you are trying to execute is solely processor work (say computing digits of pi for example) it only makes sense to create as many threads as there are cores. If it's a single core system, only one thread is necessary. Two threads at best won't make a noticable difference in processing time and at worst might even slow down the process some.
    Sunday, April 20, 2008 12:43 AM