Dynamic Linkage

[Chuck_De_Sylva]

Does your product link to IPP dynamically? And if so, what would be the potential impact to you if Intel were to remove dynamic linkage entirely from the product and only provide static linkage as part of the product? Your input is appreciated.

[SergeyKostrov]

Q: Does your product link to IPP dynamically? A: Yes and only Dynamic linking is used at the moment. Q: What would be the potential impact to you if Intel were to remove dynamic linkage entirely from the product and only provide static linkage as part of the product? A: Significant, for example size of application will grow. Next, What about dispatching? There are more flexibility with Waterfall DLLs because I could easily replace w7 ( SSE2 ) Dlls with e9 ( AVX ) Dlls if needed. PS: The most important point is I even can't imaging if Intel will do that.

[Chuck_De_Sylva]

Thanks for your input Sergey. It is greatly appreciated. We know that a lot of customers are using dynamic linkage and are trying to assess the impact to our customers if we were to remove it.

[andy4us]

I statically link, and much prefer it. The fact of life now is that hard drives are massive, as is memory, compared to win 3.1 days when DLL's were really needed. I have worked at companies where DLL's, and especially COM caused massive problems due to different product installs affecting already instealled programs. I prefer to statically link, and know my programs will work, regardless of what any other program or installer does. I believe a user is much more concerned about that, that slightly more hard drive used and a little bit more memory.

[SergeyKostrov]

>>... >>A: Significant, for example size of application will grow. Next, What about dispatching? There are more flexibility with >>Waterfall DLLs because I could easily replace w7 ( SSE2 ) Dlls with e9 ( AVX ) Dlls if needed. Should be: ...I could easily replace w7 ( SSE2 ) Dlls with g9 ( AVX ) Dlls if needed... This is because: - w7 to g9 is possible ( 32-bit DLL to 32-bit DLL ) - w7 to e9 is Not possible ( 32-bit DLL to 64-bit DLL )

[SergeyKostrov]

Hi Chuck, >>...We know that a lot of customers are using dynamic linkage and are trying to assess the impact to our customers >>if we were to remove it... Let's think in terms of innovations, OK? Now, what innovations are we going to see? Having worked with IPL ( predecessor of IPP ), IPP versions 3, 5 and now 7 I could tell that the most innovating period was a period when advance from IPL to IPP was done ( up to version 3 ). All the rest I would consider as improvements ( performance / multi-threading ), enchancements ( support for new instruction sets ), new domains, new subsets of functions, bugs fixes. Unfortunately, for a long period of time I don't see something that would really forced me to say That is a Great Idea! It is Not a matter of space on HDD that an executable will use. An increadably awesome and very complex, when it comes to installation and device compatibility, OS/2 Warp operating system did Not survived in competition with a light and simple Windows 95 and very robust WIndows NT v4.x operating systems. I simply would like to understand Why do you consider that option, that is Dynamic linking removal?

[Adrian_Edmonds1]

We could live with it I suppose. It would save another install step.

[SergeyKostrov]

Here is another input: I verified a couple of my tests and in case of static linking performance improvement was about 1.6 percent ( on a 32-bit Windows XP OS ).

[Chuck_De_Sylva]

Sergey Kostrov wrote:

I simply would like to understand Why do you consider that option, that is Dynamic linking removal?

Sergey,

Intel is trying to gauge whether or not dynamic linking is something that is needed for IPP moving forward. If the customers are not using it and it is of little value, then it is important to consider removing it in a future release. Again, we are just trying to get a feel for what the customers think.

Thanks,

Chuck

[petervk]

Internally, we use several applications that use dynamic linking. No external apps do. It simply is not worth the descent into dll-hell for little or no gain. Given how cheap storage is and the (comparitively) small size of the IPP memory footprint, I see no reason to maintaion dynamic linkage.

A caveat is that static linkage to IPP does not work on Windows with the combination of Composer 2013 and Visual Studio 2012. See this post for details: http://software.intel.com/en-us/forums/topic/328164

[SergeyKostrov]

[ Thu, 05/09/2013 - 16:03 ] >>...A caveat is that static linkage to IPP does not work on Windows with the combination of Composer 2013 and >>Visual Studio 2012. See this post for details: software.intel.com/en-us/forums/topic/328164... Information about the problem is already Not up-to-date. [ Fri, 05/10/2013 - 12:33 ] Peter has resolved the problem and it was related to a problem with project settings. Here is a quote from his last post in the mentioned thread ( topic/328164 ): ... Each of the problem apps contains multiple dependencies. I had not put /Qipp-link:static into the compiler options in each and every one. Once I did, voila, no more dependency on the IPP dll files. ...

[Thomas_Jensen1]

I link several DLLs using threaded static libraries, with each DLL having one CPU type. A main DLL contains my common functions, and also takes care of dispatching (loading + getting function pointers) to the proper CPU DLL.

I achieve more or less the same as IPP dynamic libraries, but then with only my actually used functions. This way, the size of my used IPP is much smaller.