Thread: Spawn on fly vs pre allocate threads

  1. #1
    Registered User
    Join Date
    Jun 2008
    Posts
    15

    Spawn on fly vs pre allocate threads

    For a realtime application, where performance matters. What is the general view of getting better performance. Using threads spawned on the fly (pthread_create), or preallocate group of threads with signalling (cond/locking) ?

    background 120Hz graphics update, heavy data processing, but too much data and programming complexity to use GPU/OpenCL. Have a fixed number of parallel jobs (6). In one cycle, peices of work can be forked off, while others remain stage based.

    Any views would be good to digest.

  2. #2
    Registered User ledow's Avatar
    Join Date
    Dec 2011
    Posts
    435
    Try both. Test. Benchmark.

    It's not the sort of question that has an "answer" except in very, very specific circumstances (which you haven't given and probably don't have without showing us the code, by which time you've written the program and could Test, Benchmark, etc.).

    P.S. What do you honestly think you are you doing that needs 120Hz updates while processing data and deliberately NOT using the GPU?

    - Compiler warnings are like "Bridge Out Ahead" warnings. DON'T just ignore them.
    - A compiler error is something SO stupid that the compiler genuinely can't carry on with its job. A compiler warning is the compiler saying "Well, that's bloody stupid but if you WANT to ignore me..." and carrying on.
    - The best debugging tool in the world is a bunch of printf()'s for everything important around the bits you think might be wrong.

  3. #3
    Registered User
    Join Date
    Jun 2005
    Posts
    6,815
    You might want to clarify what you actually mean by "realtime".

    My definition of realtime is the formal one: that the complete system has failed to meet operational requirements if any process runs outside its specified time intervals (i.e. no process can occur before its designated start time, and that process must have completed before its designated deadline). Consider design of a pacemaker where the patient might suffer physical consequences or even death if the heart is stimulated either too early or too late.

    From my perspective, your question is (best case) underspecified or (worst case) meaningless. Which makes me think your interpretation of "realtime" is different to mine.

    If we take my notion of realtime out of the picture, relative performance of the two schemes you describe is system (OS and hardware) dependent. Starting threads introduces overhead. There is also overhead of signalling that affects the thread that waits for or receives the signal.
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Buttercup, and read this, this, and this before posting again.

  4. #4
    Registered User
    Join Date
    Jun 2008
    Posts
    15
    Quote Originally Posted by ledow View Post
    It's not the sort of question that has an "answer" except in very, very specific circumstances (which you haven't given and probably don't have without showing us the code, by which time you've written the program and could Test, Benchmark, etc.).
    Firstly, I realise that my question is ill-posed. I am more interested in drawing upon others experiences, methodology or approach. I am not looking for a magic answer, just your view or personal experience.

    Quote Originally Posted by ledow View Post
    Try both. Test. Benchmark.
    I agree entirely.

    Are there any tools to evaluate where per-thread performance can be measured, specifically the overhead of spawning threads vs waiting on signal (assume Linux dev env)?

    I can understand that there are subtle points of the signal/lock procedures. I am not an expert in this.

    Quote Originally Posted by ledow View Post
    P.S. What do you honestly think you are you doing that needs 120Hz updates while processing data and deliberately NOT using the GPU?
    My problem is not mappable onto a SIMD parallel architecture like that of a GPU. Of course you realise that GPU is not an "answer" to all heavy computational problems.

  5. #5
    Registered User
    Join Date
    Jun 2008
    Posts
    15
    Quote Originally Posted by grumpy View Post
    You might want to clarify what you actually mean by "realtime".

    My definition of realtime is the formal one: that the complete system has failed to meet operational requirements if any process runs outside its specified time intervals (i.e. no process can occur before its designated start time, and that process must have completed before its designated deadline). Consider design of a pacemaker where the patient might suffer physical consequences or even death if the heart is stimulated either too early or too late.

    From my perspective, your question is (best case) underspecified or (worst case) meaningless. Which makes me think your interpretation of "realtime" is different to mine.

    If we take my notion of realtime out of the picture, relative performance of the two schemes you describe is system (OS and hardware) dependent. Starting threads introduces overhead. There is also overhead of signalling that affects the thread that waits for or receives the signal.
    Nothing wrong with conflict in what is realtime. From my view, 120Hz is needed for crisp refresh rate when using stereo vision. You could say this is soft-realtime for which the deadline missed is not critical (appears laggy).

    So being OS and hardware dependent, what could you say about your personal experience with either? Do you believe that pthread cond wait has been more convenient/useful than spawning threads?

    I realised that by starting this thread I intended to obtain some experience or recommendations on advanced threading in C. I am more interested in the process of how performance and optimisation is approached, rather than how to solve the specific problem at hand. It's kind of like designing software, then implementation. One does not simply jump in and solve the problem. There are (I hope) some software engineering practices that developers use as part of their workflow. A workflow for a bigger-than-a-hack project is useful.

    Apologies if I had come off snooty.

  6. #6
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Obviously spawning a thread every time you need one is going to be more expensive than reusing them. It also encourages you to think about the problem at the WRONG level. You have a bunch of tasks you want to do in parallel, the fact that threads may be involved is an implementation detail. Your question is sort of like asking whether you should use some particular machine instruction or another one. Chances are you are asking the question at too low a level.

    Go get Intel TBB, solve your problem and move forward instead of spending the next two years learning about every obscure threading bug known to man.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  7. #7
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Quote Originally Posted by brewbuck
    Go get Intel TBB, solve your problem and move forward instead of spending the next two years learning about every obscure threading bug known to man.
    I have the impression that Intel TBB is a C++ library, not a C library.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  8. #8
    Registered User
    Join Date
    Jun 2008
    Posts
    15
    Quote Originally Posted by brewbuck View Post
    Obviously spawning a thread every time you need one is going to be more expensive than reusing them.
    Is this obvious? In ideal circumstances, keeping threads suspended and waiting for signal incurs zero computation cost. In addition, the time to activate that thread will have zero delay. If it is obvious, it be proven for any system.

    Quote Originally Posted by brewbuck View Post
    It also encourages you to think about the problem at the WRONG level. You have a bunch of tasks you want to do in parallel, the fact that threads may be involved is an implementation detail. Your question is sort of like asking whether you should use some particular machine instruction or another one. Chances are you are asking the question at too low a level.

    Go get Intel TBB, solve your problem and move forward instead of spending the next two years learning about every obscure threading bug known to man.
    Thank you for referencing Intel TBB. It looks like they are addressing issues much closer to what I am interested in.

    FYI I wouldn't actively discourage anyone to spend time learning to better their knowledge. If they have the time, point them in the right direction. Perhaps a warning is more appropriate.
    Last edited by lordmule; 03-27-2012 at 12:23 AM.

  9. #9
    Registered User
    Join Date
    Jun 2008
    Posts
    15
    Quote Originally Posted by laserlight View Post
    I have the impression that Intel TBB is a C++ library, not a C library.
    This is true. The border of using C++ compiler for mostly C code had already been crossed anyways

  10. #10
    Registered User
    Join Date
    Jun 2005
    Posts
    6,815
    Quote Originally Posted by lordmule View Post
    Nothing wrong with conflict in what is realtime. From my view, 120Hz is needed for crisp refresh rate when using stereo vision. You could say this is soft-realtime for which the deadline missed is not critical (appears laggy).
    There is plenty wrong with using terms to mean something different from what others expect. It is like asking a question in english, and expecting a native japanese speaker to give you a useful answer. No matter how intelligent people might be, it is counter-productive (or, at best, inefficient) to speak to them using language and meanings they are not familiar with.

    Quote Originally Posted by lordmule View Post
    So being OS and hardware dependent, what could you say about your personal experience with either? Do you believe that pthread cond wait has been more convenient/useful than spawning threads?
    My personal experience is that there are trade-offs. There are some circumstances where spawning threads is more convenient/useful than waiting on conditions. And other circumstances where the reverse is true. There are also alternatives that sometimes surpass either technique (and sometimes not).

    Such is the nature of engineering trade-off. There are often no absolute answers. What may be considered better on one machine (computer, operating system, operating system version, etc) may be woefully deficient on another.

    It all comes down to requirements. Sometimes to meet highly specific requirements, it is necessary to be selective of hardware, operating system, as well as in your software design. If, for example, your timing requirements are relaxed, the software will run as required on a wider range of hardware.

    Quote Originally Posted by lordmule View Post
    I realised that by starting this thread I intended to obtain some experience or recommendations on advanced threading in C. I am more interested in the process of how performance and optimisation is approached, rather than how to solve the specific problem at hand. It's kind of like designing software, then implementation. One does not simply jump in and solve the problem. There are (I hope) some software engineering practices that developers use as part of their workflow. A workflow for a bigger-than-a-hack project is useful.
    Good luck on that. I've lost count of the number of researchers, and number of PhD projects, that seek to define some universal approach to capturing requirements, translating those requirements into software, etc etc. Every time someone comes up with their perceived panacea, some other researcher or some real-world practitioner comes up with a counter-example that demonstrates their approach does not always work.

    The same is true of advanced threading. Firstly, there is formally no threading in C. Threading is outside the scope of the C standard. All threading relies on some library that is specified outside the C standard (for example, the IEEE POSIX specification). Second, even if you settle on using some threading API (be it POSIX, win32 threading functions, or whatever) you are in the realm of functionality that is highly operating system dependent. Different operating systems optimise different attributes that affect the overhead of things like process creation, thread creation within threads, creating and triggering semaphores, etc. So the relative performance of (say) creating a thread pool versus creating a new thread every time one is needed are highly operating system dependent.

    And then you get into hardware dependence: how the CPU, memory system, etc is optimised around some performance parameters rather than others.
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Buttercup, and read this, this, and this before posting again.

  11. #11
    Registered User
    Join Date
    Jun 2008
    Posts
    15
    Quote Originally Posted by grumpy View Post
    There is plenty wrong with using terms to mean something different from what others expect. It is like asking a question in english, and expecting a native japanese speaker to give you a useful answer. No matter how intelligent people might be, it is counter-productive (or, at best, inefficient) to speak to them using language and meanings they are not familiar with.


    My personal experience is that there are trade-offs. There are some circumstances where spawning threads is more convenient/useful than waiting on conditions. And other circumstances where the reverse is true. There are also alternatives that sometimes surpass either technique (and sometimes not).

    Such is the nature of engineering trade-off. There are often no absolute answers. What may be considered better on one machine (computer, operating system, operating system version, etc) may be woefully deficient on another.

    It all comes down to requirements. Sometimes to meet highly specific requirements, it is necessary to be selective of hardware, operating system, as well as in your software design. If, for example, your timing requirements are relaxed, the software will run as required on a wider range of hardware.


    Good luck on that. I've lost count of the number of researchers, and number of PhD projects, that seek to define some universal approach to capturing requirements, translating those requirements into software, etc etc. Every time someone comes up with their perceived panacea, some other researcher or some real-world practitioner comes up with a counter-example that demonstrates their approach does not always work.

    The same is true of advanced threading. Firstly, there is formally no threading in C. Threading is outside the scope of the C standard. All threading relies on some library that is specified outside the C standard (for example, the IEEE POSIX specification). Second, even if you settle on using some threading API (be it POSIX, win32 threading functions, or whatever) you are in the realm of functionality that is highly operating system dependent. Different operating systems optimise different attributes that affect the overhead of things like process creation, thread creation within threads, creating and triggering semaphores, etc. So the relative performance of (say) creating a thread pool versus creating a new thread every time one is needed are highly operating system dependent.

    And then you get into hardware dependence: how the CPU, memory system, etc is optimised around some performance parameters rather than others.
    Wow. I can see why you are called grumpy.
    - Realtime has no strict meaning. It is context dependent. (Japanese speaking vs English? lol)
    - I have already understood that trade off exists. Nobody's solution, or approach is applicable to my own. I am merely surveying the landscape, not finding the definitive and only path.
    grumpy, while you appear to have good experience and knowledge about you, little has been presented with reference to threads.


    Reading through the questions and answers of this FAQ proved very useful: comp.programming.threads

  12. #12
    Registered User
    Join Date
    Jun 2005
    Posts
    6,815
    Quote Originally Posted by lordmule View Post
    Wow. I can see why you are called grumpy.
    And I can see why you're named after a beast of burden.
    Quote Originally Posted by lordmule View Post
    - Realtime has no strict meaning. It is context dependent. (Japanese speaking vs English? lol)
    Wrong. The term realtime (in the context of computing systems) has meaning that is specified in a number of international standards.

    You need to do your homework.

    Quote Originally Posted by lordmule View Post
    - I have already understood that trade off exists. Nobody's solution, or approach is applicable to my own. I am merely surveying the landscape, not finding the definitive and only path.
    grumpy, while you appear to have good experience and knowledge about you, little has been presented with reference to threads.
    You asked a general question, and you have received general answers. And the answers were appropriate to the question you asked.
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Buttercup, and read this, this, and this before posting again.

  13. #13

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. fork, execv, spawn, or something else?
    By DavidP in forum C++ Programming
    Replies: 8
    Last Post: 01-26-2009, 04:25 PM
  2. Re: Borland c++ - Spawn Function
    By icc_81 in forum C++ Programming
    Replies: 8
    Last Post: 11-19-2003, 04:43 PM
  3. Spawn Problems
    By wilkisi in forum A Brief History of Cprogramming.com
    Replies: 1
    Last Post: 10-30-2002, 07:48 AM
  4. a little more of spawn()
    By tsarena in forum C++ Programming
    Replies: 0
    Last Post: 05-08-2002, 07:33 AM
  5. spawn
    By lambs4 in forum C Programming
    Replies: 2
    Last Post: 02-17-2002, 05:16 AM

Tags for this Thread