Originally posted by: UserCplex

Hello,

I am trying to use the VTune Profiler in Windows (Visual Studio IDE) to find hotspots in my C++ CPLEX application (that uses C Callable library functions from CPLEX) and from a variety of sources, it appears that it is a good idea to build the application with optimizations turned on. That is, Release Mode Build. For e.g., with a debug mode build that does not apply optimizations, I have encountered std::vector bounds checking to be a hotspot, for instance which if an application is fully debugged, can be redundant.

Now, under the Release Mode Build, c_cpp.html from CPLEX documentation recommends using the stat_mda version of the libraries. On doing so, VTune hotspot analysis points to a spot where I as the user have called the CPLEX function CPXmipopt(env, lp). Then, digging deeper into this function points inside of cplex1280.dll. (See VTune1.jpg). On diving deeper into this function, it takes me to the assembly code of the line that caused the hotspot. See VTune2.jpg.

(1) Now, as a user (and not a CPLEX developer), can I use this information intelligently to design my programs differently to make it more efficient? Or, if the profiler points to any function in cplex1280.dll as the hotspot, should I basically not worry further since that hotspot is inevitable and already highly optimized by CPLEX developers?

(2)I also noticed that if I build under Debug mode and use the mdd version of the libraries as suggested by c_cpp.html, I still encounter a wall where it eventually points to a function within cplex1280.dll. The c_cpp.html file only talks about Concert APIs and how they relate to mda vs mdd builds. Is there any documentation of the C API and how they relate to the mda vs mdd builds? In other words, suppose I build my application in Visual Studio Debug mode, but force some optimizations in the debug build itself by overriding the defaults provided by Visual Studio for the debug build (for instance, skip std::vector bounds checking) and run the application linking to mdd files (since it is a debug build where NDEBUG is NOT defined) would the application be less efficient than a default release build linking to mda files?

Thanks.

I don't think there is anything (reasonable) you can do about the functions inside the CPLEX dll. You should assume that we did our best to eliminate hotspots and tune the code appropriately. Like you mentioned, some hotspots just cannot be avoided.

What is said in c_cpp.html about mda and mdd should apply to C and C++ in the same way.

Originally posted by: Laci Ladanyi

As Daniel said, you can't really do much about hotspots that are within the cplex dll. Actually, that is not quite true.

There are three phases: 1) building up the model; 2) calling optimization; 3) tearing down the model. If a hotspot appears in 1 or 3, then you might be able to rearrange how you do those steps (for a stupid example: if you add the coefficients of the matrix one-by-one, that could cause a hotspot, while adding a whole constraint at a time is a lot more efficient). If a hotspot appears in 2 then just don't worry about it. No matter what formulation you use for your problem there *always* is a hotspot somewhere in the optimization process, choosing a different formulation will just move the hotspot. Find the formulation that solves the fastest and don't worry about hotspots during optimization.

His comment on mdd vs. mda is also correct. C/C++/Concert makes no difference: The only difference between the libs in stat_mda and stat_mdd is whether NDEBUG was defined or not. Otherwise they are compiled with the same optimization level. So unless you have a strong suspicion that there is a bug in CPLEX and you want the windows runtime libraries to perform extra checks, you should use the mda libraries (which are compiled with NDEBUG) to avoid the performance penalty of those checks.

Originally posted by: Laci Ladanyi

Just to clarify the statement "The only difference between the libs in stat_mda and stat_mdd is whether NDEBUG was defined or not. Otherwise they are compiled with the same optimization level." :

CPLEX itself is always compiled with -DNDEBUG. The difference is that the cplex dll in stat_mda is linked with /MD, that is, the windows runtime the cplex dll links against was compiled with -DNDEBUG; while the cplex dll in stat_mdd is linked with /MDd. 

I hope this makes it clearer... and sorry for the confusion.

Originally posted by: UserCplex

Hi Laci,

Thanks. Just so I understand further, the compilation with -DNDEBUG is so that the debug information is not available in the object files preventing the user from stepping through CPLEX internal code. Had CPLEX been compiled without defining NDEBUG, then the user would be able to step into and see cplex internal code. This, the user cannot control. For instance, I obtain the attached image from within VTune that cplex1280.dll module does not contain debug information. and that enabling debug information is possible by recompiling with /DEBUG flag. That, presumably, would enable the user to step through CPLEX internal code and VTune to be able to show the hotspot within CPLEX function source code.

Regardless and independent of this, the internal CPLEX source code involved here either defines _DEBUG or does not define it (not to be confused with the /DEBUG flag that VTune is referring to above and in the image). That is, two sets of object files will be produced both with -DNDEBUG. In one of them (that which will eventually be used by the user in /MD linking),  _DEBUG is not defined. In the other (that which will eventually be used by the user in /MDd linking), there will be a line on top that says #define _DEBUG. Regardless, both of these are compiled with the -DNDEBUG to suppress generation of debug/symbol lookup information.

What the user can control is in terms of linking, the option of whether to use /MDd or /MD. As explained https://msdn.microsoft.com/en-in/library/2kzt1wy3.aspx, /MDd defines _DEBUG (not to be confused with the -DNDEBUG used in the compilation process above) in addition to _MT and _DLL. By then linking to the cplex180.lib in the appropriate folder (stat_mda for /MD option and stat_mdd for /MDd option), the right functions are loaded. Presumably then, the additional definition of _DEBUG in /MDd, leads to a function in the "debug" cplex180.lib  whose underlying source code had such as:

#ifdef _DEBUG

//do stuff that only happens in /MDd linking, not in /MD linking

#endif

Am I right in my understanding? I have been spending time online looking at different sources to try and figure out what exactly these symbols achieve:

https://msdn.microsoft.com/en-in/library/2kzt1wy3.aspx

https://stackoverflow.com/questions/2290509/debug-vs-ndebug

and it is still not fully clear in my head.

Thank you.

Originally posted by: Laci Ladanyi

Defining a symbol (or not defining) only changes *what* gets compiled (by the #ifdef directives in the source code) not *how* it gets compiled. For a production release of CPLEX we don't want to include sanity checking code, that is needed for development only. The flag /DEBUG, or /OPT (or a host of other flags) controls how the compiler compiles the code. With /DEBUG the compiler foregoes possible optimizations in the compilation so that it can match the generated assembly code (the machine code) to the source code thus enabling debugging. With /OPT this is generally not possible.

So when you link with /mdd, you get the windows libraries that are compiled without /DNDEBUG, but that does not mean the windows libs will have all the debugging information. No, they were compiled with /OPT, but they do include lots of sanity checking code. 

Similarly the distributed CPLEX is always compiled with /OPT. You need not know what /D... definitions existed at the time of compilation, that has nothing to do with linking against the library. The reason why we distribute two CPLEX libraries is that if a customer wants to link with /mdd, but CPLEX was linked with /md, then there may be very mysterious failures. You are not supposed to mix runtime libraries. So we distribute CPLEX libs linked with /md, and libs linked with /mdd.

I hope this clears up some issues. For details on the various stages of compilation and linking, about which flags are effective when, the msdn websites have some good description.