I can't figure out why this API was designed like this?
First, it is counter-intuitive to call other functions before Init() because, well... object isn't initialized!
In other words, it is common for Init() to be the first thing you call before doing anything else.
Second, if it is possible to call SetNoOfThreads() only before Init(), then there is no compelling reason to provide SetNoOfThreads() -- you could have accomplished the same with Init(int NoOfThreads) and in that case there would be known default.
Third, it is not clear why JPEGDecoder doesn't figure out the proper number of threads on its own depending on the image size (that is, after calling ReadHeader()).
Finally (and I came to expect that when it comes to IPP or UIC), UIC documentation has no mention of SetNoOfThreads() function.
It is possible to set number of threads either before call to Init ro after. UIC JPEG codec automatically choose number of threads, so you are not required to call SetNOfThreads. But with SetNOfThreads function you can specify desired number of threads you want to allocate for decoder or encoder. This desired number can differ from what UIC choose automatically.
Be default, UIC will try to allocate all available hardware threads for operations and you can limit this with SetNOfThreads. For example, on Nehalem system, it might make sense to use 2 threads for decoding leaving the rest of threads for other needs of your application.
May I suggest that JPEGDecoder in the future decides on the number of threads used depending on the image size? Without extensive testing I couldn't find out what number of threads to use. Given that you know better how the code is parallelized, you should also know better when it makes sense to split workload to more than one thread.
there are might be several consideration and image size is one of them, thanks for idea. We will consider that for implementation in future. Other considerations might be just to allocate 2 threads for JPEG decoder which leaves rest of threads available for use in application on quad (or more) cores systems. I would expect customer cares on performance in case ofbig images,so for small images it might be not that important if threading was turned on or off and was it efficient or not. Please, correct me if I'm wrong in my assumption.
The cost of thread startup and synchronisation overhead for smaller images might be worse than the gain from threading, that is why I am suggesting that the decision should be based on image size.
For large files (I am thinking 3,000 pixels and up) I would personally want to use all available cores, not just two of them.
In any case, without extensive performance testing the proper number of threads cannot be determined. Now it is just a matter of who is going to perform that testing -- Intel or every developer individually.
Depends on what you do, if you are processing 100,000 of small images, splitting each one to several threads would considerably increase processing time. In that case it would be better to work with n images at a time where n is a number of threads available.