Parallel Inspector: Time Stamp needed?

Parallel Inspector: Time Stamp needed?

Nice work, I have already found some really interesting things in my code.

However I see what seems to be quite a lot of false positive too.For example I have an Unitialized memory access reported with the read in a function call before the Allocation site (from what Parallel Inspector seems to suggest). The allocation is also for a buffer that has nothing to do with the read event.My guess is that it should be checked against an earlier allocation and that the heavy memory usage just landed the same pointer and caused some confusion.

Anyway, I wonder if it might not be better to have the time stamp for each event that way a mismatch like that can easily be detected.

In addition it seems to report a lot of Error: Invalid deallocation when using realloc! (Having more info in that case might help)

I did some runs with Threading checks too and it worked nicely but again there was some really strange data race reported with the initialization of the data before the start of the read thread for example causing some issues.

I won't unfortunately be able to produce some code since that is part of a large propriatory library.

Obviously all the code used above works fine, passes our tests and while there might be small issues nothing has been reported in the field so far. (so far :)

Anyway as a feedback comment I would say that the tools are great and easy to use. While I regret the fact that I cannot dig into the assembly code while viewing the hotspots I can always do that with VTune.

I also had a few crashes and it even fail to send the feedback :) but I am quite satisfied with the stability of the product so far.

Anyway, I wonder if it might not be better to have the time stamp for each event that way a mismatch like that can easily be detected.

Anyway as a feedback comment I would say that the tools are great and easy to use. While I regret the fact that I cannot dig into the assembly code while viewing the hotspots I can always do that with VTune.

First of all, we're happy to hear of the many things you like about the Intel Parallel Inspector. A lot of effort has gone into the product so far, and more likely as the product matures. False positives are sometimes difficult to catch, especially in complex programs. One thing I'd like to check, though: are you doing your runs on the Debug build of your test program? Optimization sometimes makes it difficult to reassociate assembly code with the proper source lines. Your comment about not being able to dig into assembly code raised this question. Usually people don't care too much about looking at debug assembly code except when looking for compiler or linker errors.

I assume the timestamp you want is one that is displayed along with the rest of the observation data so that you, inspecting the results, can further test the context of such observations to sort out such false positives?

Well digging into the assembly code was mainly targetted at the hotspot feature, I would not even dare trying to find the hotspots in my 3D rendering program in debug that's for sure :)I found a case where I had a strange hotspot and I had to start the app and break into it to check the assembly code.And it turned out to be a case where the code is not as clean as it should have been and the Intel compiler just decides apparently to not optimize that part. After factorizing some of the code into 2 new functions the compiler generated the code I was expecting and the hotspot was gone.

For the rest yes threading and memory tests were done on debug version and in this case indeed I don't care about assembly code as you can imagine.Your assumption is correct, having the timestamp along with the rest of the data should help (I hope).

Since my first tries, I have managed to clean quite a few things on the small portion of the code I was testing so I am definitively quite happy with the tool as it is right now.

The only report I havent figured out yet is an invalid deallocation poping up on some realloc.

Quoting - laurent lessieux - Toshiba MedicalWell digging into the assembly code was mainly targetted at the hotspot feature, I would not even dare trying to find the hotspots in my 3D rendering program in debug that's for sure :)

And it turned out to be a case where the code is not as clean as it should have been and the Intel compiler just decides apparently to not optimize that part. After factorizing some of the code into 2 new functions the compiler generated the code I was expecting and the hotspot was gone.

Your assumption is correct, having the timestamp along with the rest of the data should help (I hope).

"Hotspot feature?" So you're playing with Intel Parallel Amplifier as well as Intel Parallel Inspector? Great to hear. As I suspect you know, Intel Parallel Inspector has no hot spot feature and Intel Parallel Amplifier should be run on the Release (optimized) builds in order to locate the hot spots that matter, the ones in your release code.

As for the compiler failing to optimize particular sections of code, the compiler writers have their own Hippocratic Oath, insofar as their goal is, "first, do no harm." Optimizations that introduce errors are anathema for a compiler. But compilers have limited information and can't always disambiguate safe and unsafe conditions. Source modification to disambiguate for the compiler as you described often can be effective.

I'm not on the development team but I know where they sit. I'll bounce your idea of a sanity-test timestamp to them and see what reaction I get.

"Hotspot feature?" So you're playing with Intel Parallel Amplifier as well as Intel Parallel Inspector? Great to hear. As I suspect you know, Intel Parallel Inspector has no hot spot feature and Intel Parallel Amplifier should be run on the Release (optimized) builds in order to locate the hot spots that matter, the ones in your release code.

As for the compiler failing to optimize particular sections of code, the compiler writers have their own Hippocratic Oath, insofar as their goal is, "first, do no harm." Optimizations that introduce errors are anathema for a compiler. But compilers have limited information and can't always disambiguate safe and unsafe conditions. Source modification to disambiguate for the compiler as you described often can be effective.

I'm not on the development team but I know where they sit. I'll bounce your idea of a sanity-test timestamp to them and see what reaction I get.

Yes so far I played with both Amplifier and Inspector before trying Composer. Since our code is quite old we already have in place threading where we should have it but might replace it by some TBB code or something else.Although since the code is working in the first place, there is always very limited incentive to replace it.

There is a lot of features in the Amplifier that I quite like. It is perhaps not giving tons of options like VTune (which is the tool we are using from time to time to optimize things) but at the same time it is way simpler to use and the call stack informations are great too.

Parallel Studio will certainly have a place in the list of tools we are using. In fact my team has scheduled a few days to look into it after my first reports so it already passed our first test :)