Our Windows version of VTune is crashing on any attempt to initialise ITT. We are currently investigating this issue on another forum. However as a temporary work-around we have removed “/DDO_ITT_NOTIFY” and rebuilt TBB using build\vs2010\makefile.sln. This resolved our VTune crash however it raises further questions.
I assume the prebuilt Windows TBB binaries are built with /DDO_ITT_NOTIFY defined. Is this correct?
If so, is there any performance penalty introduced by ITT?
What’s the recommend method to build production ready Windows TBB binaries from source? Is it safe to use build\vs2010\makefile.sln (but migrated to appropriate version of MSC). Or should I use the GNU make utility as outlined in TBB “build directions”. In which case, which GNU utilities should I use? I tried both MYSYS and CYGWIN, both encounter the following error -
'\"cscript /nologo /E:jscript ./build/detect.js /arch \""' is not recognized as an internal or external command,
operable program or batch file.
'\"cscript /nologo /E:jscript ./build/detect.js /runtime \""' is not recognized as an internal or external command,
operable program or batch file.
build/common.inc:54: *** Architecture not detected. Stop.
1. You can add TBB_VERSION=1 to the environment before running application that uses TBB. It will provide some info including defined macros. For the last update, /DDO_ITT_NOTIFY is present.
2. Theoretically, it should not affect the performance. In any case, you can always check it with your application.
As for production ready binaries. What do you mean with "production ready"? TBB build without /DDO_ITT_NOTIFY should work correctly but some features can be unavailable in VTune. Therefore, your customers can lose some features when using VTune. If "production ready" relates to some legal stuff - it is better to consult with your legal department.
As for build on Windows, usually Microsoft Compiler or Intel Compiler is used either with "GNU make utility for Windows" or with solution file (that should be identical to command line approach). To build with MinGW your need to specify "compiler=gcc" in a command line for make, e.g. "make compiler=gcc".
1. I did try "TBB_VERSION=1" but there was no output. I assumed we didn't executed the relevant TBB code that printed the relevant macros defs.
2. By "production release" I simply mean binaries that can be deployed to clients.
3. I'm attempting to build with Microsoft Compiler. After executing "C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\vcvars32.bat" does make auto detect the compiler and architecture?
ITT support code was changed in TBB 4.4 update 3. What is the version you work with? Knowing is the crash affects versions prior 4.4u3, after 4.4u3 or all of the might be helpful.
1. You need to use any TBB functionality to force initialization and message printing. E.g. call tbb::parallel_for with empty body;
2. Sorry to be too punctilious but "can" in what meaning? Physically, you can deploy anything that you want but as for licences, rights and so on you need to consult your legal. If your are worrying about correctness and performance it should be Ok. If your are worrying about your customers' experience with VTune then they can be affected;
3. Yes, it should use Microsoft Compiler by default. Did you open tools command prompt shipped with Visual Studio, change directory to "tbb/1.0", call "gmake" command and face some issues? Could you share the output log? (To make sure that Microsoft Compiler is available call "cl.exe" from command line.)
1. We are using TBB 4.4 update 0. To clarify, the app profiled by VTune is crashing, not VTune itself. However Intel Inspector works fine and the app runs fine outside VTune. The VTune issue is not solely caused by the addition of TBB. We have same issue for ITT code used to silence false data races in our app that are reported by Inspector which only is activate in a special "profile" build. Thus we managed to work-around the VTune issue by VTuning the deployable release build where the ITT code has been removed.
2. We are worried about correctness and performance. In part because https://software.intel.com/en-us/node/544200 implies there's a performance hit using ITT. Currently we can't VTune our deployable release build unless we rebuild TBB with /DDO_ITT_NOTIFY removed and thus any customer VTune experience is rather moot (however some colleagues don't have same the VTune issue).
3. Yes I opened tools command prompt shipped with Visual Studio. However I only tried MSYS & CYGWIN. I'm currently in the process of acquiring GNUWin32 utils. Hopefully this will resolve the issue.