I really would like to express concerns regarding possibility of removing DLLs from IPP library

[SergeyKostrov]

Here is quote from Intel IPP developer:

>>...By the way, now we are thinking about if it worth continuing relases of dynamic IPP libraries. If there nothing helpful
>>in DLLs why not to stop doing them?

We already discussed that subject some time ago and I've explained that when application is linked with IPP dynamic link libraries and uses IPP DLLs it allows to change CPU dispatching DLLs for different computer systems with different CPUs. An application stays the same and doesn't need to be re-compiled!

You need to contact all IPP developers in order to conduct a survey before making such final decision. I really would like to express concerns regarding that and possibility of removing DLLs from IPP.

This is a wrong direction and it will affect thousands of IPP library developers. Take into account that Intel MKL and TBB teams don't even consider it and if a couple of developers had / have some issues with IPP DLLs this is Not the reason to remove DLLs and to change everything to static linking.

All major libraries used in the software industry, like MFC, Boost, QT, GTK, etc, provide both options ( that is, dynamic and static linking ) and it allows a developer to decide what solution works better for a project.

You should think about a solution similar to MKL's Link Adviser instead, like IPP Link Adviser, and it is Not clear why it is Not done for so many years.

[SergeyKostrov]

I appreciate if every IPP library developer / user follow ups that thread and leaves a short statement ( a vote ) if IPP DLLs need to be removed or should not be removed. Thanks in advance.

[Sergey_K_Intel]

Wow, discussion! :))

Sergey Kostrov wrote:

We already discussed that subject some time ago and I've explained that when application is linked with IPP dynamic link libraries and uses IPP DLLs it allows to change CPU dispatching DLLs for different computer systems with different CPUs. An application stays the same and doesn't need to be re-compiled!

That's what static libs do pretty well with static dispatching.

Sergey Kostrov wrote:

You need to contact all IPP developers in order to conduct a survey before making such final decision.

That's impossible.

Sergey Kostrov wrote:

This is a wrong direction and it will affect thousands of IPP library developers.

Hmm, not sure. 

Sergey Kostrov wrote:

Take into account that Intel MKL and TBB teams don't even consider it and if a couple of developers had / have some issues with IPP DLLs this is Not the reason to remove DLLs and to change everything to static linking.

The reason could be dramatic decrease of IPP package size, less uncertainty of IPP customers, better application portability and many other pluses. From the negative affects I see still nothing.

Sergey Kostrov wrote:

All major libraries used in the software industry, like MFC, Boost, QT, GTK, etc, provide both options ( that is, dynamic and static linking ) and it allows a developer to decide what solution works better for a project.

Many of them not. Nevertheless, that's not argument.

Sergey Kostrov wrote:

You should think about a solution similar to MKL's Link Adviser instead, like IPP Link Adviser, and it is Not clear why it is Not done for so many years.

There can be other technical solutions, like custom DLL build tool, to prepare small-sized DLL having only functions required for particular application directly of static libraries. So, global DLLs are not a panacea.

Nevertheless, it's not a decision, even not a proposal yet. We, you're right, need to count all costs.

Regards,
Sergey 

[SergeyKostrov]

>>...Wow, discussion! :)) >>... >>Hmm, not sure... >>... Sergey, Remember that you're representing Intel Corporation. You need to put off all personal impressions and technical professionalism should be your top priority. >>... you're right, need to count all costs. Let's assume that IPP DLLs are removed after a two year derprecation period. I could assume ( for 99% ) that some time later Intel will be forced to bring IPP DLLs back after hundreds of complaints from different IPP developers. You're thinking about your problems and, it looks like, you do not care about all the rest problems with IPP developers and customers. Take into account that some IPP functions marked as deprecated in the past and already removed are restored after some numbers of complaints. A change related to IPP DLLs is a significantly larger compared to removing some number of "obsolete" IPP functions.

[Sergey_K_Intel]

Sergey, It was a smile, I apologize for that.

Regarding deprecation, this program has no real history yet. It's a multi-step process, actual removing of functions is very last step of this process, which can or cannot happen.

Regarding possible, I need to stress, possible eliminating of DLLs, we would like to collect the strong arguments for not doing this. The library content remains intact, we are changing ways of just handling this content.

But, these are theoretical thoughts, though. And beyond the scope of my interests.

Regards,
Sergey 

[scott-gordon5_3]

We call IPP from C#, which provides interoperability (C# calling native x86 code) via dlls only. I vote to keep the dlls.

[SergeyKostrov]

>>...We call IPP from C#, which provides interoperability (C# calling native x86 code) via dlls only. I vote to keep the dlls... Thanks for the note! Even if I don't do any C# programming I simply can't imaging how it could affect C# projects which use IPP through interoperability. I think this is a really important note.