To all beta participants:
We sincerely thank you for participating in our Intel Parallel Studio beta program, and sharing your experience with us on our beta product. The Intel Parallel Studio 2011 Tool Suiteis released and now available!
For product forum support, please visit the Intel Parallel Studio User Forum at: http://software.intel.com/en-us/forums/intel-parallel-studio/
Thank you for participating in our Intel Parallel Studio Beta program. We appreciate your continued beta testing and feedback. Please submit any issues or feature requests and comments in this forum so we may resolve them for our product. Again, thank you for sharing your experience with us.
Sincerely,
Beta Team
Thanks for your kind attentions. I am debuging a source code of softwarae. When I've excute my program in debug format, the results (predicted values of temperature and other water quality parametes ) differs than with exe file "w2_ivf.exe" which is build by software developer. When I've emailed to software developer, he said I should contact intel.
Also when I was compile the source code there were a error which said The
type of the actual argument differs from the type of the dummy argument in the arguman of "density"
I am using intel parallel studio XE 2011 to excute the source code of the project. But when I've run the source code, there are different results compared with exe file of software which is developed by software developer. When I was working with the recent version of software, I've made the excutation file in w_cprof_p_11.1.065, there were no problem. The results of my excute software was not different from excute software, but now when I am use theintel parallel studio XE 2011, the results are different. What should do I? is there any difference between the way of excutation?
Thanks for your kind attentions. I am debuging a source code of softwarae. When I've excute my program in debug format, the results (predicted values of temperature and other water quality parametes ) differs than with exe file "w2_ivf.exe" which is build by software developer. When I've emailed to software developer, he said I should contact intel.
Also when I was compile the source code there were a error which said The
type of the actual argument differs from the type of the dummy argument in the arguman of "density"
The installation of VTune Amplifier XE 2011 includes theheader fileandlibrary for the VTune JIT Profiling API.
C:\\Program Files (x86)\\Intel\\Amplifier XE 2011\\include\\jitprofiling.h
C:\\Program Files (x86)\\Intel\\Amplifier XE 2011\\lib32\\jitprofiling.lib
I have a need to profile a specific function. I tried the new XE, but the function is not hot enough to show up in the hotspot functions. One of its child function can still be hot, but that is impossible for me to find, I have to click and review every hotspot's stack to know.
The VTune 9 can profile a spcific function, that would be perfect for this task.
Does the new VTune XE have the same ability to have a precise call graph for a specific function?
If yes, how to use that.
I can't find this ability witht the new VTune XE, is
Hello.
Occasionally, ICL returns the following error when trying to compile a .cpp file which includes :
(0): internal error: backend signals
I'm using the Intel Composer XE 2011 (Update 2) under win7/VS2008.
Sometimes, I can only get rid of this error if I first compile all of the Cilk-related files to .obj and then link them manually.
Regards,
Hello.
The Intel Amplifer XE 2011has beenan outstanding tool to id hot spots and to fix scalability problems whenrunning parallel code. However, under my current development platform (VS2008/Win7), it requires to run VS2008 in an elevated mode (admin) or the tool fails to log into the kernel.
Has anyone a way around this?
Regards,
Hello,
I'm trying to use the Parallel Inspector on my TBB code, but am getting all kinds of strange race conditions.
It actually looks like what I would expect if I wasn't using any mutexes - saying there are concurrent calls to functions when I know the call sites are mutex-protected. (and I double checked this by testing directly in the code, in case the mutexes weren't working somehow. note these are plain tbb:mutex-s)
