Some of you may recall that on some events, we got an error message on Intel Thread Checker during the Multicore lab. No matter what we did, even if we solved all the concurrency issues related to our code, the Thread Checker would always log this message:
Write -> Read data-race Memory read at [PrimesInstrumented.exe, 0x2468] conflicts with a prior memory write at [PrimesInstrumented.exe, 0x16816] (flow dependence)
During the labs, we have said that we've been working out the solution with the Intel support people - and now we have an answer!!The thing is that you can work with Thread Checker in two ways:
- Use compiler based instrumentation. With this, you basically need to add the /Qtcheck flag to the compiler command line to instrument the binary. Once it is instrumented and you run it, it will create a file called "Threadchecker.thr", that you can then load in the VTune Thread Checker. To do this, you need to use the following command lines: (using the primes example from the lab)
icl /c /Zi primes.cpp /Qopenmp /Qtcheck /Od
link primes.obj /out:PrimesInstrumented.exe /fixed:no /DEBUG
- Use Thread Checker to intrument the application. In this scenario, you don't intrument the binary at compile time, but have Thread Checker intrument it when running the application. For this, you need to build the application with the following command lines:
icl /c /Zi primes.cpp /Qopenmp /MD /Od
link primes.obj /out:PrimesInstrumented.exe /fixed:no /DEBUG
And then load it in Thread Checker.
The error we were doing on the lab is that we were using both compiler and "Thread Checker" instrumentation, and that caused Thread Checker to report conflicts that are outside of the program and in the runtime libraries. Now, using either option (BUT not both at the same time) the strange error is gone!
Thanks to Vasanth Tovinkere at Intel who really helped us out with this problem!!
BTW, this is repeating an old blog post I did for the 64–bit Advantage Blog. The post was deleted for some reason. Since I consider this information to be important, I am re-posting it here.
You can create C++ application in Visual Studio that use OpenMP. When you run an application created with OpenMP and VS.NET, however, you may get this annoying error message: “This application has failed to start because vcompd.dll was not found. Re-installing the application may fix this problem.”:
When we tried this, we were puzzled by this error message, especially since it works with the Intel Compiler flawlessly. Well, it turns out that you need to include omp.h in your files ALWAYS when you use OpenMP from Visual Studio. This is not required on other compilers if you’re only using the OpenMP pragmas, but it is an issue with Visual Studio.
Thanks to Kang Su for pointing this out in his blog – I was going crazy trying to figure out what was wrong.
Also remember to enable OpenMP support in the C++ Project properties. This setting is in Configuration Properties->C/C++->Language->OpenMP Support.
OpenMP is very easy-to use API that you can use to very rapidly add multi-threading to your C/C++ applications. OpenMP allows you to parallelize the execution of a region of code by just adding a few pragmas to the code. For example, take this code:
for(int i = 0;i<=100;i++){
a[i] = a[i]*10;
...
}
The code above performs a for loop sequentially. Since each iteration could be executed independently, we can easily add multi-threading to the application by adding these simple pragmas:
#pragma omp parallel for
for(int i = 0;i<=100;i++){
a[i] = a[i]*10;
...
}
The omp pragmas tell the compiler to generate code to parallelize the execution of the for loop. That means that if you run this code on a 4 core machine, it will create 4 threads, and each one will execute 25 iterations of the loop. Just by adding those pragmas, you now have a multi-threaded application that takes advantage of multi-core systems.
Yes, it's that simple.
A while back I documented the process for doing a Sysprep on a Windows 2003 installation. Well, that same process works for a Windows XP installation. The sysprep GUI on Windows XP is slightly different, but you only need to make sure that the “MiniSetup” and “Pre-Activate” options are selected before pressing the Reseal button and shutting down the machine.
Here are the instructions to run Sysprep on Windows 2003.
If you ever do a Visual Studio .NET 2005 unattended install, you’ll notice that the installation reboots the machine several times and won’t continue until you log back in – defeating in part the purpose of the UNATTENDED install.
Well, this page over at Aaron Stebner's WebLog has some instructions that can help you make your installation REALLY unattended. It requires two things: first, remove some pre-requisites that end up on the vs_2005.ini files regardless of what you do (instructions here), and second, create a batch file that installs both the prerequisites and VS.NET. This is the code in the batch file for the unattended install on x64 boxes (run it from the VS dir):
wcu\msi31\WindowsInstaller-KB893803-v2-x86.exe /quiet /norestart
wcu\dotNetFramework\x64\netfx64.exe /q:a /c:"install.exe /q"
wcu\DExplore\DExplore.exe /q:a /c:"install.exe /q"
setup\setup.exe /unattendfile vs_2005.ini
For other machines, you may need to change the architecture of the .NET framework for the correct one (x86/x64). I made that batch file for an unattended install a few months ago at a 64–bit event where I had to install Visual Studio in around 30 machines, and it worked like a charm. YMMV
Windows Vista RC1 was completed today. From the Windows Vista Team Blog:
It’s official — Windows Vista RC1 is done!
...
You’ll notice a lot of improvements since Beta 2. We’ve made some UI adjustments, added more device drivers, and enhanced performance. We’re not done yet, however — quality will continue to improve. We’ll keep plugging away on application compatibility, as well as fit and finish, until RTM. If you are an ISV, RC1 is the build you should use for certifying your application.
Right now it is only available for customers on the TAP program, but according to a post in the forum, they plan to make it available to MSDN and Technet subscribers.
The Windows Live team recently launched the Live Writer tool for writing blog posts. This is a sample post made with the tool. So far, it looks nice, with most features already working.
One of the nicest features is Live Map integration:
San Jose, Costa Rica
I think I am going to stick with Blogjet for the time being (especially for the flickr integration). But it won't harm you to check out Live Writer as well.
One nice features of the JLCA is that it converts javadoc-style comments into the corresponding .NET XML comment. Well, a new tool was released a few weeks ago that can take .NET’s XML documentation and create nice looking files. It is called Sandcastle, and is currently a CTP download. It can create .html files from the source code, which can be processed with the HTML Help Workshop to generate a .chm file. It also has a Visual Studio Add-in that makes the process really easy.
You can download the CTP here, and read all about it in the Sandcastle team blog.