Some effects of multi-core technology on software correctness

1.
Recently, a problem has been found in the AMD64 dual-core CPU running Iometer for disk performance testing, measured response time and other data is 0, obviously illogical. I downloaded the Iometer source code (http://www.iometer.org/doc/downloads.html) for debugging, and found that it might be related to an assembly instruction RDTSC. This instruction returns the clock cycle that has elapsed since the CPU was power-up, and is a powerful tool for high-precision timekeeping. The instruction set used by AMD64 is x86_64, is it x86_64 the instruction is incompatible with the normal 32-bit x86 instruction. No, when AMD launched AMD64, the emphasis was on full compatibility with x86.
I did further debugging and found that the IO processing time calculated by Iometer was negative. That is, for the same IO request, the time to complete the RDTSC statistic is less than the time of the start statistic. Obviously, this is not common sense. Is the time gone backwards. .................. All of a sudden, I thought I was using a dual core, and maybe the time to start and finish is different from the nuclear process, and the time of the two cores is not the same.
I only assigned 1 CPU cores to Iometer's related tasks in the Task manager, so I got all the normal results. It seems that my guess is correct. It seems that the time of AMD64 each core is somewhat different. When booting, you should start a core, start another core, and then both cores faithfully record the time they are running, and they are not synchronizing with each other.
I also tested Iometer on Intel Dual Core, and no such phenomenon occurred. On the internet to see a AMD64 dual-core patch, hit this patch will solve the problem. The computer I am using now is Intel CPU, only wait for the next time to get AMD64 again test.

2.
Multi-core optimization brings a performance boost to many software, but it also brings some new problems. I tried to compile the iometer with visual Stduio2005 and found that vs would somehow quit. Open Task Manager and discover that there are two cl.exe in the process. This process is the C + + compiler for vs. But why would there be a cl.exe two copies? I looked at the output information of VS and saw that two projects were being compiled at the same time.
Originally, Visual Studio2005 is optimized for dual cores, and if there are two projects in a solution, there is no dependency between the two projects, then when compiling vs will process two projects at the same time, take full advantage of the dual-core parallel processing capability. However, if these two projects share some files (for example, they will compile the same file, and the resulting intermediate files are also placed in the same path), then the cl.exe running at the same time is in conflict, and the VS is directly hung out. This problem is easy to solve, add dependencies to the project, and let two projects compile sequentially. It is a good idea to make the output directory of two items different from the intermediate directory, further avoiding conflicts.
Multicore is a relatively new technology, although many software optimizations, but it is not possible at this stage. When we use software on multi-core CPUs, we also need to pay more attention to the appropriate configuration, from the functionality and efficiency of the full multi-core capabilities.