I'm happy to see that someone has started to integrate Qt applications with TBB. Hopefully your application is open source too, at which point I'll be very very happy. I'll try to help you as much as I can.
Let's start with your first question regarding encoding as a tbb::task. First, you are right that blocking a TBB task is a no-no. tbb::tasks are there for computational work, which in your case will be computation for the encoding. I'm not sure how hard encoding is, computationally-speaking. The tasks should represent fairly small units of computation for load balancing, the smaller the units are the better the load balancing will work.
I'll try to illustrate this with an example. You described encoding an entire track as a tbb::task. Let's say you have 4 tracks, and 4 processors. Suppose that 3 of these tracks are fairly short, and finish quickly. The scheduling algorithm cannot break up the work any further, so you will have 3 idle cores while a single core bears all the computational work. Sometimes you will get a speed-up, sometimes not. Now, suppose that instead you break up work to represent encoding say two seconds of track (I'm not sure how encoding works, so forgive me if this isn't right). Each tbb::task would include an id for the 2 second segment, say the track number it belongs to and the offset of the 2 seconds into the track. Now you break up encoding of tracks into many many 2s segments... this eliminates the former problem that occurs when one track is longer than others.
Now we have the I/O problem. You will have to determine if your problem is I/O bound, or computationally bound. The tbb::pipeline seems like it could help you with this problem. You could setup a pipeline where you read a segment of memory, encode it, then write it back to disk.
Finally, Qt threads. What are you using the Qt threads for? I am assuming this is for the graphical interface only? It would likely be best to just link your encoding module separately, so that it can manage its own threading via TBB. That is to say, write your encoder as a separate module in C++ with TBB, and define an external inteface to the module so that threading is entirely hidden. Then you can call this module from your Qt application so that it does not know it is even calling a threaded program. Technically this could lead to oversubscription, which happens when there are more threads than processors. Whether or not this is a problem depends entirely upon how and why you are using threads.
AJ - thank you for the very helpful and informative response. I'll try to answer all of your questions in order.
First, yes my application is open source, but is in the very early stages and I haven't published it in any public source repository. I'll try to whip it into shape a little bit and push it up to github or somewhere.
Next, you are correct that my application design has tasks that are far too coarsely grained. I should have fine-grained tasks to best take advantage of TBB. I initially chose the coarse-grained design for two reasons:
- I was thinking more in terms of application level tasks, or "units of work" as the user would understand them. At this level, tasks are complete units of work that can be started, paused, and cancelled, and most importantly report status and progress back to the GUI thread so that the user can see how tasks are progressing. At this level you can also have dependencies and priorities for tasks, but it is a very different thing than the more fine-grained tasks defined by TBB.
- I am using external libraries to do the actual encoding operations, e.g. libvorbis, libflac, etc.. These libraries tend to have high level interfaces with operations such as "encode this WAV file using the given bitrate, etc.". With my current application design, I don't really have the flexibility to break down the tasks into smaller units because the API doesn't expose such lower level operations.
So that explains why I've chosen to design the application the way that I have. However, I am not tied to this design and would be happy to redesign some portions in order to work better with TBB. That may mean that I have to actually go into the code for the encoding libraries (which are all open-source, fortunately) and hack them a bit to get them to work with TBB. I'd prefer not to have to do this if I could avoid it, but I'm not sure that I can. Any thoughts on that?
As for the I/O problem, my experience indicates that encoding a WAV file into FLAC, Ogg Vorbis, or Mp3 is
mostly CPU bound, but there is still a good deal of I/O. The encoders will read a chunk of data from the rather largish WAV file and then do a fairly large amount of computation on the chunk of data. I do not know the innards of these encoders well enough to provide any more detail, but having used them it appears they spend more time on CPU than waiting on disk I/O.
Finally, Qt threads. I am currently using them only because I had started writing my own version of tbb::task before I discovered TBB. If I can get TBB working for this application I don't think I'd need to use Qt threads at all. However, one very important feature of Qt threads is that Qt's signals/slots mechanism works transparently across threads. If a signal that is emitted in a worker thread is connect to a slot in, say, the GUI thread, Qt transparently turns the signal into an event and places it into the GUI thread's event queue. I'm not sure if this support requires use of Qt threads, or if Qt is smart enough to determine that there are separate threads involved even if some other threading library is being used.
Thanks again for your help. I really think TBB would be a great boon to my application if I can overcome these hurdles.
