Intel® Integrated Performance Primitives
Deliberate problems developing high-performance vision, signal, security, and storage applications.

UIC::JPEGDecoder API weirdness

levicki
Valued Contributor I
365 Views
I am looking at sample code...
[cpp]  jpegdec.SetNOfThreads(param.nthreads);

status = jpegdec.Init();
[/cpp]
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.

0 Kudos
6 Replies
Vladimir_Dudnik
Employee
365 Views
Igor,


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.

Regards,
Vladimir
0 Kudos
levicki
Valued Contributor I
365 Views
Vladimir, thanks for clarification.

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.
0 Kudos
Vladimir_Dudnik
Employee
365 Views
Igor,

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.

Regards,
Vladimir
0 Kudos
levicki
Valued Contributor I
365 Views
Vladimir,

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.

0 Kudos
Vladimir_Dudnik
Employee
365 Views
yeah, overhead might be big but absolute performance numbers still should be small enough. That's why I think not that important to care of.
0 Kudos
levicki
Valued Contributor I
365 Views
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.

0 Kudos
Reply