0

Is it worth taking the time to write the code to reuse threads in C, or are they cheap to create and destroy?

I'm rendering some CPU only 3D graphics and it was going pretty slow (looked like about 5 fps). I tried using threads to solve this. Using 4 threads, each rendering a strip of the screen, seemed to boost my frame rate to something very reasonable and smooth. I'm still worried about what will happen when I make my graphics more complicated. Would I get any appreciable speed boost by reusing my threads instead of creating and destroying them every frame?

Edit: The operating system I'm working on is Windows.

Void Star
  • 2,401
  • 4
  • 32
  • 57

2 Answers2

3

Since with 1 thread you got about 5 fps, presumably with 4 threads, you got to somewhere around 20 fps? So, you would be creating and destroying 80+ threads per second if you don't keep them around? Threads are fairly lightweight, but I think you'd begin to notice that much overhead.

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
  • 80 per second is nothing, unless Windows sucks more than I realize. 80 per frame might be costly, but on Linux, thread creation cost is somewhere around 20 microseconds. Not as low as I'd like, but at 80 per second, that's 1600 microseconds, i.e. 1.6 milliseconds or 0.16% overhead. – R.. GitHub STOP HELPING ICE Feb 04 '12 at 22:40
  • Okay, I will try reusing my threads if it gets too slow, thanks. There seems to be some controversy on just how slow threads are. – Void Star Feb 04 '12 at 22:51
  • I'd be interested in hearing from ppl with Windows experience how slow thread creation is on Windows. – R.. GitHub STOP HELPING ICE Feb 05 '12 at 00:04
1

You will eliminate quite a lot of overhead and latency, yes. TBH, I can't understand why so many developers start off by continually creating and destroying threads - it's inefficient, difficult and prone to leaks and other disasters.

Martin James
  • 24,453
  • 3
  • 36
  • 60
  • I disagree. Creating and destroying threads as you need them leads to clean, simple resource management. Pooling and reusing them forces you to do much more complex management of thread and resource lifetimes. For many tasks, performance is a compelling reason not to create and destroy threads often, but on a decent OS the performance issue only arises when you get to the point of tens of thousands of threads per second. Keep in mind signaling a condition variable can easily take 10-20% of the time it takes to start a new thread. – R.. GitHub STOP HELPING ICE Feb 04 '12 at 22:44
  • Well, it will be much easier to agree to disagree on this one rather than starting a threaded-design jihad. – Martin James Feb 04 '12 at 23:16
  • No need for a jihad. :-) I agree both approaches have merits, but I think the "common sense" is a bit outdated and swayed in one direction, and that the simplicity argument is on opposite. Still there's definitely a place for both. I tend to lean towards having a thread's lifetime coincide with its task/data domain, which is somewhere between pools (reassigning a new task/data to existing threads) and constant creation/destruction. – R.. GitHub STOP HELPING ICE Feb 05 '12 at 00:03