The Intel Power Checker 2.0 now supports measurement both on battery and with the system plugged into an external AC power source. External power measurement is only supported on Intel® Second Generation Core processors and if the Intel® Power Gadget software has been installed.

For this article, I took a very compute-intensive parallel application that I wrote to solve instances of the logic puzzle Akari. The code uses a backtracking algorithm to explore how to place light bulbs onto a grid under constraints dictated by the rules of the puzzle and the layout of the puzzle instance. Potentially millions of independent tasks can be generated by the code as the solution space is searched by threads executing those tasks. This solution method is eminently scalable to a large number of threads and is able to keep many cores running at peak speed for a sustained amount of time.

How to Use Intel Power Checker

The Intel Power Checker provides a GUI wizard that leads you through the four steps of power analysis. These four steps in the checker are described below. Before starting the assessment, be sure to know which section of your application (a workload) you want to be measured, as the Power Checker will only measure a 30 second execution interval. (If you want to measure the entire execution workload, you should try some other tool, like Intel Power Gadget.) Your workload could be a compute-intensive portion or an I/O-intense section or just some point in execution that typifies the majority of expected usage.

Step 1: Specifying the Power Meter device

If you have an external power meter attached to your test system, you can select the model being used on the first screen of the wizard. The default is that no external device is being used. For this default case, Intel Power Checker will determine if the system is capable of providing power consumption data and if the correct power driver, EzPwr.sys, is installed. (The driver is part of the default installation of Intel Power Gadget.)

Step 2: Measure System Baseline

The first measurement that the Intel Power Checker will perform is on the next screen within the wizard. This is to measure the baseline power consumption of the hardware without your application running. Prior to this measurement phase any unnecessary processes such as operating system updates, Windows Indexing Service, virus scans, media players, and internet browsers should have been shut down. In other words, to get the most accurate results you should make your test system as idle as possible and ensure that nothing will become a foreground process during your measurement runs.

Once you have a quiescent system, click the “Start” button to begin this phase of the testing. The Intel Power Checker waits 15 seconds to allow the system to come to an idle state before starting the measurements. You need to be sure to position your mouse and the keyboard out of reach, or keep your hands away from them, to avoid any stray contact that might trigger some response from the platform. After the pause, the checker will observe the system for 30 seconds in this idle state. A progress bar will show the time remaining in each part of this phase. Once the baseline data collection is complete, click the “Next” button to proceed to the next phase.

Step 3: Measure Active Application

Before you are taken to the next screen in the wizard, you are instructed to start the application you are interested in measuring. Start up your application and click the “OK” button to advance the GUI to the next screen. Once you have reached the Step 3 screen, use the scroll bar to locate your application in the process list and click on that line to select it. If your application is not listed, click the “Refresh List” button so that your application’s process will be available to select. In addition, you can use the “Apply Filter” button to narrow down the list in order to find your application’s process quickly. .After selecting your application from the list, click “Next” to move on to the data collection for this phase. Before starting the assessment, be sure your application has reached the desired point of measurement. If there are some initial setup computations that are not of interest, you will need to get past this point before letting Intel Power Checker begin measurement. For my Akari application, there is very little setup time. It was typically in the thick of computation by the time I had gotten to the point of selecting the process from the list.

As soon as I could, I clicked the “Start” button to begin capturing measurement data. Since this is one of the crucial power measurements for your application, always begin capturing data after the workload or critical section has begun and make sure this active execution will run longer than the 30 seconds needed to complete the measurement time.

Step 4: Measure Idle Application

The final phase is to measure your application’s idle power consumption. This is another important phase of energy efficiency measurement of an application since your application must not only do efficient computation, but also not waste energy when sitting idle.

This step doesn’t make much sense within my compute-intensive application since there is no idle state of the application. Once you start the application on a given puzzle instance, it simply computes all legal solutions in parallel and then ends. As (multiple) solutions are found, they are printed out by the thread that found it. If there are no solutions, a message is printed just before the application terminates. This latter case describes the workload I used for my tests. Because you must have your application running in “idle” mode for this step, I left the application running at full speed and simply allowed Power Checker to take its measurements.

If your application does have an idle state, perhaps waiting for interaction from the user, the checker will give the system 15 seconds to calm down fully before taking a final 30 second measurement.

Upon completion of this last data collection phase, you will be able to proceed to the results screen within the Intel Power Checker wizard. After all three measurement phases have been completed; a Tool Report File will be generated containing all of the results for later analysis.

What data is presented

The View Results screen of the Intel Power Checker wizard provides basic information about the software assessment. The type of processor in your system and the type and model of the power source that was used are given. Four numerical values for each of the three measurement phases are presented. These values are:

• Elapsed Time: The exact number of seconds that each of the phases lasted.
• Energy Consumption: The rate that the battery was discharged during each of the three phases.
• Average C3 State Residency: The percentage of time that the system was in the C3 state during the data collection period.
• Platform Timer Period: The number of milliseconds that the platform timer collected

Typical results would hopefully show a larger percentage of time spent in the C3 State Residency for the application idle time measurement (the middle of the three columns on the View Results screen). As my puzzle solving application was still computing as much as it did in the active execution measurement step, this was not the case for my results. This is atypical for the intended type of applications Intel Power Checker assumes will be measured. Thus, the C3 State Residency values provided by the tool for the idle application were not valid for my particular application.

The name of the report file and the directory to which it will be found are listed on the View Results screen.

Some Caveats

Below are some things you should consider before and during a measurement run using Intel Power Checker.

• Before you start using Intel Power Checker, be sure your chosen workload will run for at least 30 seconds from the point you wish to measure power consumption. In my case, I required a data set that would force the application to run for at least 75 seconds (30 for active measurement, 15 for idle setup, and 30 for idle measurement) plus the time I needed to click boxes and find my application in the process list. Since I ran the application on several different numbers of threads, I needed to be sure that the fastest execution time was still large enough to get all the timings steps completed during a Intel Power Checker run.
• Upon starting Intel Power Checker, the checker may first report that the platform timer period is invalid. In this case, some currently running (background) process has changed the default and it will be up to the user to determine which currently running application has changed the value. Once you have identified the culprit you must stop this process or service before restarting Intel Power Checker. If you are unsure about which active process is preventing Intel Power Checker from starting, you will need to turn off processes one at a time and try Intel Power Checker until the error message doesn’t come up.
• Instructions on the Step 3 screen ask you not to touch the keyboard or mouse. If you are measuring an interactive application or you must interact with the application to generate activity for the full 30 seconds, you will need to touch the keyboard and/or mouse. If possible, a workload that can forego interactivity and still compute for the 30 seconds of measurement time would be best. However, if interaction by the user is part of how the application is utilized, interfacing through peripherals will give you a more accurate measure of the overall energy consumption for typical application usage.
• A data file is created during each phase of the Intel Power Checker assessment to hold the current information. If you cancel the assessment in any of the three phases then a data file will not be created for that phase. After all three phases have been completed, a Tool Report File, in XML format, will be generated containing all of the results. You can find the name of the report file and where it is located on the View Results screen.
• The “Submit Results” button on the View Results screen is optional and only intended for members of the Intel® Software Partner Program to submit their measurement results to the program. If you are not a member, do not submit your results. Simply click on the “Close” button after you have examined the results compiled by Intel Power Checker.

Some Results

The purpose of this article is not to determine the best scenario for running my Akari solver application in the most energy efficient way. You will want to do this for your application, though, and this article has given you the background on Intel Power Checker to determine if this checker can help you quantify the current power consumption of your application. Also, as you make modifications to the application you will be able to determine if those changes improve the energy efficiency or cause your application to suck more power than before.

In addition to the average C3 State Residency percentage, the checker delivers the total number of Joules expended during the 30 seconds of execution time measured. From this I can compute the average Watts for execution parts of the application. I have found that a better metric for comparing different applications or different runs of the same application is milliwatt hours (mWh). You need the total execution time of the execution portion of the application to compute this value. Since Intel Power Checker only measures activity in 30 second segments, you will need to have some timing data available, which I happened to have for the different runs I made of my Akari application.

I found significant differences when running with and without Hyper-Threading Technology (HT) turned on. Also, if the platform was running on battery (DC) power or from the wall socket (AC) power, a difference in execution time and power usage was evident. For example, when running with HT on and a full complement of four threads on the 4 logical cores in my system, I saw the AC power run 1.19X faster that when running the same workload on DC power. However, the former run took 1.15X more power.

Comparing results between runs on DC power versus AC power is a not a good comparison, especially in this case. The power source is detected by the system and the processor is allowed to run with Intel® Turbo Boost Technology at a higher frequency if the platform is using external power. Even so, you may need to be concerned about power consumption of your application in both power source circumstances and you will need to run measurement experiments within each setup to gauge how well your application modifications affect overall power consumption.

System Requirements

You can use Intel Power Checker on a laptop or netbook based on Intel® Core™ processor or Intel® Atom™ processor technology. A desktop with an external power meter or a desktop that is capable of providing the power consumption information can also be analyzed. A Java* Runtime Environment (JRE) (version 6 update 11 or higher) is also required to run the checker. Supported operating systems are Microsoft Windows* XP (Service Pack 3), Microsoft Windows Vista* (Service Pack 2), Microsoft Windows* 7 (Service Pack 1 [32-bit and 64-bit]), and Microsoft Windows* Server 2008 R2.

Download link

To download the Intel Power Checker installation package, go to the following link:

http://software.intel.com/partner/app/software-assessment/. Click on the Intel Power Checker tab to move down to the download link.

Other supporting links

There is a video demonstration of using Intel Power Checker, “A Look at Intel Power Checker,” at the link: http://software.intel.com/en-us/videos/channel/intel-software-partner-program/a-look-at-the-intel-power-checker/1127786023001. Dave Valdovinos and Taylor Kidd, both from Intel, show off the GUI wizard as it measures the power performance of a game-like application.

To ensure this, the following exhaustive steps are enforced by Intel Cluster Checker test modules:

1. · Check that base libraries and their uniformity (base_libraries)
2. · Check that MPI tools have consistent paths (mpi_consistency)
3. · Check that per-node MPI jobs can do Hello World independently (intel_mpi_rt)
4. · Check that a global Hello World is successfully executed across compute nodes (intel_mpi_rt_internode)
5. · Runs Intel MPI Benchmarks such as Ping Pong to check available latency and bandwidth (imb_pingpong_intel_mpi)
6. · Stress the communication system by running the HPCC benchmark (hpcc)

If the tool reports something, then an MPI application might have issues to complete their work.

These steps will even catch potential timeouts due wrong configuration on the network stack; and most important, bad cabling or down hardware interfaces. However, if the cluster uses InfiniBand adapters then there is a known issue to be aware of. The global MPI check can hang as any other MPI application will do if InfiniBand is not correctly configured and online.

Intel(R) MPI Library Runtime Environment (All nodes), (intel_mpi_rt_internode, 1.8.....................................................^C

Caught signal INT, cleaning before termination.

With InfiniBand setups, the configuration of Intel Cluster Checker must define openib and dat_conf as dependencies of intel_mpi_rt_internode. This action will ensure that the InfiniBand devices are properly detected and healthy. openib check hardware devices, and dat_conf the DAPL software interface.

<intel_mpi_rt_internode>

<add_dependency>dat_conf</add_dependency>

<add_dependency>openib</add_dependency>

</intel_mpi_rt_internode>

This decision cannot be done automatically as choosing were to use or not the low latency, high bandwidth capabilities of InfiniBand during the check is at discretion of the user. For instance, the administrator may want to double check that an Ethernet fabric can be properly used to run MPI applications.

Be aware that this manual requirement may be lifted in the near future.

More Work, Less Power

Energy Efficency

EE=Work/Energy

Code Instrumentation

Energy Consumed

1. Use a power meter to collect actual “platform energy and power” information.
   
   There are several different power meters that work with the Intel Energy Checker SDK. Please consult the Intel® Energy Checker SDK User Guide included in the download or found on the Intel® Energy Checker SDK page to determine which power meters will work and how they should be attached to the test system.
   
2. Use Intel® Power Gadget to collect “processor energy and power” usage information on 2nd Generation Intel Core™ processor family. External power meters can also be used which report platform power together with Intel Power Gadget that provides processor power.The blog Accessing Intel® Power Gadget From Intel® Energy Checker SDK by Intel engineer Jun De Vega discusses how to enable Intel® Power Gadget with Intel® Energy Checker.
   
3. Choose to use the simulation method which will use the CPU utilization percentage returned from the OS. This method does not require a hardware probe. The Intel Energy Checker SDK offers this method as an option for all processors (rather than just the 2nd Generation Intel Core processor family as with the Intel Power Gadget) in order for enable the user who does not have a power meter. Included in the SDK is a support library for accessing this metric.

Figure 1: Conceptualized drawing of Intel Energy Checker setup with Instrumented Application, Power Meter and Environmental probes attached

Intel Energy Checker Extras

Figure 2: PL GUI Monitor running while a picture is being rendered

Optimizing Applications for Ultrabooks

Summary

About the Author

In the case of legacy projects, ask the developers to submit new code only if they reduce the number of findings.
In the case of coding from scratch, allow no findings before uploading new code in your repository.

When enabling the check (-diag-enable sc3) and compiling the code, a new folder will be created where the findings will be stored using a custom XML format.

$ file rXsc/data.X/rXsc.pdr
rXsc/data.X/rXsc.pdr: XML document text

$ xml sel -t -m /diags/diag -v "concat(message/thread/stacktrace/loc/file, ':', message/thread/stacktrace/loc/line, ':', sc_verbose)" -n rXsc/data.0/rXsc.pdr
/home/$USER/work/$PROD/src/pool.c:157:pool.c(157): warning #12178: this value of "ret" isn't used in the program
/home/$USER/work/$PROD/src/pool.c:186:pool.c(186): error #12192: unreachable statement
/home/$USER/work/$PROD/src/pool.c:216:pool.c(216): warning #12135: procedure "pool_done" is never caled

Intel® Threading Building Blocks is used in wide range of applications. If performance makes sense and multi core platform is used, TBB is good thing to be added to C++ program. Network applications are usually highly-loaded as they process huge amount of traffic and processing time constraints are high. This article is intended to show how TBB can be used in network packet processing software, improving its productivity and processing time.

For a sample project I've created a simplified Network Router emulator. Network Router is a device that routes and transmits IP (Internet Protocol) packets in local area network (LAN). It connects several PCs, provides them access to Internet and internal network. The device has several internal network interfaces and one external.

The sample project emulates Network Router logic. It provides the following functionality:

• Input packets from file - the application is just a model so there is no need for real interconnection with network interface. Reading from file emulates real reading from network interface.
• NAT - Network Address Translation. The router has only one external IP address, but packets should be delivered to several internal devices behind the router. NAT allows port and IP mapping from external to internal and vice versa.
• IP routing - delivering packets to appropriate router NIC (Network Interface Controller) according to destination IP.
• Bandwidth management - some traffic is real time and it's critical to deliver these packets as quick as possible (e.g. voice over IP). The VoIP protocols maintain telephone conversation and delays would degrade quality. The router can prioritize these critical packets so they can be processed quicker.

I've created two versions of Network Router: serial and parallel. The latter uses Intel® Threading Building Blocks. I'll describe how TBB was used in the project and will provide performance results of the program parallelization.

Network Router implementation

Network router emulator gets packets from file and processes them. Packet processing includes Bandwidth management, NAT translation and IP routing. Packets are processed by several program modules. These processing modules are ordered sequentially, like in assembly line. This is common composition of packet processing application. Input file is a text file, each line represents one IP packet. There is separate thread that reads packets by big chunks.

Intel® TBB has tbb::pipeline class that provides high level framework for such kind of program structure. It has filters that process packets on each stage. Each packet goes through the pipeline and is processed step by step by its filters. One packet is processed sequentially - from first filter to second, than third, etc. However processing of one packet is independent from another, so filters can operate in parallel.

Network Router scheme

Main function:

#include <iostream> 
#include <sstream>
#include <fstream>
#include <vector>
#include <algorithm>
#include <ittnotify.h>
#include <tbb/pipeline.h>
#include <tbb/concurrent_hash_map.h>
#include <tbb/atomic.h>
#include <tbb/concurrent_queue.h>
#include <tbb/compat/thread>
// Redirects calls to "new" and "delete" to TBB thread safe allocators
#include <tbb/tbbmalloc_proxy.h>

using namespace tbb;
using namespace std;

class bandwidth_manager_t;
class network_adress_translator_t;
class ip_router_t;
class compute_t;
typedef vector<packet_trace_t> packet_chunk_t;

int chunk_size = 1600;
concurrent_queue<packet_chunk_t> chunk_queue;
atomic<bool> stop_flag;

int main(int argc, char* argv[])
{
	ip_addr_t external_ip;
	nic_t external_nic;	
	nat_table_t nat_table;	// NAT table   
	ip_config_t ip_config;	// Router network configuration 					
	int ntokens = 24;	
	
	get_args (argc, argv);	
    ifstream config_file (config_file_name);

    if (!config_file) {
        cerr << "Cannot open config file " << config_file_name << "\n";
        exit (1);
    }		
	if (! initialize_router (external_ip, external_nic, 
                            ip_config, config_file)) exit (1);	
	
	thread input_thread(input_function);

	// packet processing objects
	bandwidth_manager_t bwm;	
	network_adress_translator_t nat(external_ip, external_nic, nat_table);
	ip_router_t ip_router(external_ip, external_nic, ip_config);		

__itt_resume();
	bool stop_pipeline = false;	
	
	parallel_pipeline(ntokens,		
		make_filter<void, packet_chunk_t*>(		// Input filter
			filter::parallel,
			[&](flow_control& fc)-> packet_chunk_t*{				
				
				if (stop_pipeline){					
					fc.stop();
				}				
				packet_chunk_t* packet_chunk = new packet_chunk_t(chunk_size);
					
				if(!chunk_queue.try_pop(*packet_chunk)){				
					if (stop_flag) {
						stop_pipeline = true;
					}
				}				
				return packet_chunk;
			}
		)&	// Bandwidth manager filter
		make_filter<packet_chunk_t*, packet_chunk_t*>(		
			filter::parallel,
			[&](packet_chunk_t* packet_chunk)-> packet_chunk_t*{								
				
				for(int i=0; i<packet_chunk->size(); i++){
					packet_trace_t packet;
					packet = (*packet_chunk)[i];				
					
					if (packet.nic == empty){
						break;
					}
					else{
						bwm.prioritize(packet);									
						compute_t compute;
						compute.work();						
					}										
				}
				std::sort(packet_chunk->begin(), packet_chunk->end(),
							packet_comparator);
				return packet_chunk;	
			}
		)&	// NAT filter
		make_filter<packet_chunk_t*, packet_chunk_t*>(	
			filter::parallel,
			[&](packet_chunk_t* packet_chunk)-> packet_chunk_t*{

				for(int i=0; i<packet_chunk->size(); i++){	
					packet_trace_t packet;

					packet = (*packet_chunk)[i];					
					if (packet.nic == empty)
						break;
					else{				
						nat.map(packet);
						compute_t compute;
						compute.work();	
					}
				}				
				return packet_chunk;
			}
		)&	// IP routing filter
		make_filter<packet_chunk_t*, packet_chunk_t*>(		
			filter::parallel,
			[&](packet_chunk_t* packet_chunk)-> packet_chunk_t*{			

				for(int i=0; i<packet_chunk->size(); i++){						
					packet_trace_t packet;
					packet = (*packet_chunk)[i];
					
					if (packet.nic == empty)
						break;
					else{				
						ip_router.route(packet);
						compute_t compute;
						compute.work();	
					}
				}				
				return packet_chunk;
			}
		)&	// Output filter
		make_filter<packet_chunk_t*, void>(	
			filter::parallel,
			[&](packet_chunk_t* packet_chunk){														
				
				for(int i=0; i<packet_chunk->size(); i++){						
					packet_trace_t packet;
					packet = (*packet_chunk)[i];	
					compute_t compute;
					compute.work();	

					if (packet.nic == empty)
						break;
				}	
				// No output is required , just drop packets
				delete packet_chunk; 
			}
		)
	);	
__itt_pause();

	cout << "\nAll packets are processed\n\n";		
	return 0;
}

First part is "preparation" - creating objects, reading command line, opening files and initializing. Configuration file contains router interfaces info. Objects bwm, nat and ip_router are packet processing objects. They use containers nat_table and ip_config for storing NAT and IP tables.

The core component of Network Router is pipeline. It is implemented using tbb::parallel_pipeline() function, that takes number of tokens and list of filters as arguments. The element of work that is passed through the pipeline is of type packet_chunk_t. Parameter ntokens controls maximum number of concurrently processed elements. It has value 24 because the project was tested on 24-core machine and making it bigger wouldn't make an effect.

Pipeline filters perform some work execution, particularly packet processing in this application. Filters can be serial or parallel. This mode is controlled by filter parameter that is filter::parallel for all filters. This means that any filter can process some elements at the same time.

First filter extracts packet chunk from chunk_queue and passes it to second filter. Second filter performs bandwidth management operations on each packet from chunk. bwm module assigns priorities to packets according to protocol. Then packets in chunk are sorted by priority. This allows critical traffic to be processed as early as possible.  Subsequent filters make NAT mapping and IP routing. Last filter is output, but for simplicity real output is not done. Packets are just dropped.

Packet chunk is used as pipeline token because it's big enough. If single packets were passed through pipeline there would be too much transitions between threads, and overhead would be bigger than positive effect.

The __itt_resume() and __itt_pause() functions are used by Intel® VTune^TM Amplifier XE that was used for performance measurements. These API functions mark the beginning and the end of area of interest.

Object compute of type compute_t makes workload for CPU. It just performs additional computations to simulate computing in real systems. The application doesn't perform the entire job needed for processing and routing packets in real life network equipment. It is just model framework of real application, so there is not enough CPU usage. Method compute_t:: work()starts computing "N Queens" algorithm.

Input file opening and reading is a job of separate thread. It is instantiated using std::thread class that is a part of new upcoming C++ 11 standard.

Serial implementation

To understand effect from parallelization a serial version was created. It has similar structure. The only difference is that parallel_pipeline is replaced with simple while loop.

Network router serial scheme

While loop (replacing parallel_pipeline):

__itt_resume();
	bool stop = false;

	while (!stop){
		packet_chunk_t packet_chunk(chunk_size);
		
		if(!chunk_queue.try_pop(packet_chunk)){				
			if (stop_flag) {
				stop = true;
			}
		}		
		
		for(int i=0; i < packet_chunk.size(); i++){
			packet_trace_t packet = packet_chunk[i];;			
			bwm.prioritize(packet);	
			compute_t compute;
			compute.work();									
		}
		std::sort(packet_chunk.begin(), packet_chunk.end(), packet_comparator);
		for(int i=0; i < packet_chunk.size(); i++){
			packet_trace_t packet = packet_chunk[i];				
			nat.map(packet);
			compute_t compute;
			compute.work();		
			ip_router.route(packet);				
			compute.work();							
			compute.work();								
		}
	}
__itt_pause();

There are four calls of compute.work() - the same number as in TBB version. This is going to be the most CPU time consuming function, so it's fair to have same number of calls to it.

Data structures

Input file has the following format:

eth3 104.44.44.10 10.230.30.03 4003 5003 ftp
eth3 104.44.44.10 10.230.30.03 4003 5003 rtp
eth0 134.77.77.30 104.44.44.10 2004 4003 sip
eth3 104.44.44.10 10.230.30.03 4003 5003 http

Each line represents one packet. It has network interface, source, destination IP and port, protocol. Packet is stored in packet_trace_t structure:

typedef struct {
	nic_t nic;			// network interface where packet arrived
	ip_addr_t destIp;		// destination IP
	ip_addr_t srcIp;		// source IP
	port_t destPort;		// destination port
	port_t srcPort;		// source port 
	protocol_t protocol;	// protocol type (rtp, ftp, http, sip, etc)
	int priority;			// packet priority
} packet_trace_t;

typedef concurrent_hash_map<port_t, address*, string_comparator> nat_table_t; 
typedef concurrent_hash_map<ip_addr_t, nic_t, string_comparator> ip_config_t; 
typedef vector<packet_trace_t> packet_chunk_t;
concurrent_queue<packet_chunk_t> chunk_queue;

void input_function(){	
    ifstream in_file (in_file_name);
    if (!in_file) {
        cerr << "Cannot open input file " << in_file_name << "\n";
        exit (1);
    }
	stop_flag = false;	
	
	while(in_file.good()){			
		packet_chunk_t packet_chunk(chunk_size);
								
		for(int i=0; i<chunk_size; i++){
			packet_trace_t packet;
			in_file >> packet;					
			packet_chunk[i] = packet;			
		}
		chunk_queue.push(packet_chunk);			
	}
	stop_flag = true;
}

Performance measurements

The goals of this project were to achieve good performance and scalability by using TBB. For measurements the following setup was used:

CPU: 4 processors Intel® Xeon X7460, 2,66 Ghz, 24 physical cores total
RAM: 16 GB
OS: Microsoft Windows Server® Enterprise 2008 SP2
Workload: input file: 113405 packets (5,1 MB)
Measurement tool: Intel® VTune^TM Amplifier XE 2011
Analysis type: Concurrency with default settings

It's seen that CPU time is similar. This is sum of CPU times of all cores of the system. But elapsed time is very different. This is clock time that the application takes for processing. In serial version it is near the value of overall CPU time. In TBB version it is 19 times less. So the application worked 19 times faster.

Average number of utilized cores for TBB version is 20.5 and most of the processing time all 24 were used. This demonstrates that application is scalable enough and can use almost all cores on multi-core system.

The results provided show good performance results for TBB-based application. However keep in mind the following conditions:

1) There were used Amplifier XE API functions __itt_resume() and __itt_pause() that bound measured area. The result show performance of tbb::parallel_pipeline for TBB version and while loop for serial version. Measurements of overall application work will give a little bit different results.

2) Simulated job was used to utilize CPU. The compute_t class computes algorithm of "N queens" task. Real processing is different.  If there would be not enough job for CPU, file input would consume relatively more time. So in real application scalability and performance gain can be worse.

Conclusion

In this article, you will find out how hardware based Event Based Sampling (EBS) technology can help developers estimate the floating point operations per second executed by their applications. FLOPS will refer to 32 bit and 64 bit floating point operations and the operations will be either addition or multiplication (computational).

The Intel® VTune^TM Amplifier XE is a performance analysis tool, which can help the software developers analyze their application to identify algorithmic and microarchitectural performance issues. The VTune^TM Amplifier XE uses the processor's Performance Monitoring Unit (PMU) to sample processor events and some of these processor events can be used to statically sample the number of computational floating point operations at execution.

Figure 1: Scalar processing vs. SIMD (Single Instruction Multiple Data) processing

Figure 2: Intel® Architecture integer, floating point, MMX and SSE (Streaming SIMD Extensions) registers.

Note: The figure doesn't show the latest AVX extension and registers.

As Figure 1 and 2 demonstrate, floating point operations can be performed on legacy x87 registers or on SSE registers, depending on how the compiler generates the code. If the floating point instructions are executed on SSE registers, then they can be either scalar or packed operations. Table 1 (below) gives the PMU event names which can be used to statistically estimate the computational floating point operations executed by the hardware. It is a good idea to keep in mind that not all the executed instructions, hence counted by these events, are retired due to speculative nature of the architecture. Therefore, it is possible to experience overcounting of these events.

Table 1: PMU events are used to count the computational floating point operations at execution.

Note: This table does not include the event names used to sample AVX FP operations

The VTune^TM Amplifier XE can use any of the events or all of them at the same time to estimate the flops achieved by an application. In order to measure the elapsed time, the CPU_CLK_UNHALTED (a.k.a clockticks) event can be used. If the processor frequency is constant during the measuring period, you can use the clockticks event to calculate the elapsed wall clock time. Please keep in mind that the CPU_CLK_UNHALTED event name might vary by the processors architecture.

Alternatively, CPU_CLK_UNHALTED.REF, which counts the number of reference cycles and is not affected by thread frequency changes, can be used. The difference between the reference clocktick event and clocktick event is that even if a thread enters the halt state (by running the HLT instruction), the reference clocktick event continues to count as if the thread is continuously running at the maximum frequency.

Estimating FLOPS

The FLOPS formula can be given as follows:

FLOPS = ((number of FP ops / clock) * number of total computational FP ops) / Elapsed Time

Elapsed Time = CPU_CLK_UNHALTED / Processor-Frequency / Number-of-Cores.
Note: The cores with non zero CPU_CLK_UNHALTED event count needs to be considered for this formula.

To demonstrate how EBS technology can be used to estimate the FLOPS, a simple multi-threaded matrix multiplication will be used. Each thread in the thread pool executes the following code.

double a[NUM][NUM];

double b[NUM][NUM];

double c[NUM][NUM];

...

slice = (unsigned int) tid;

from  = (slice * NUM) / NUM_THREADS;

to    = ((slice + 1) * NUM) / NUM_THREADS;

 

for(i = from; i < to; i++) {

for(j = 0; j< NUM; j++) {

for(k = 0; k < NUM; k++) {

// 2 fp ops / iteration: 1 add, 1 multiply
c[i][j] += a[i][k] * b[k][j];

}

}

}

...

The application also reports the flops measured by dividing the total FP operations ( 2 / iteration * NUM * NUM * NUM) with the elapsed time. The elapsed time only includes matrix multiplication part and doesn't include the initialization and thread creation overhead.

In order to collect samples for the relevant code section __itt_pause() (pauses the collection) and __itt_resume() (resumes the collection) APIs are used. Please refer to VTune^TM Amplifier XE documentation on how to use the user APIs.

VTune^TM Amplifier XE can be configured as follows on Intel® Core^TM i7 (x980) based system (3.33GHz, 6 core + Hyper Threading enabled):

Using x87 Registers

The sample application is compiled in released mode (optimization level set to 0x) on a Windows* system using Visual Studio

The application reports the following when analyzed under VTune^TM Amplifier XE.

The results below give us insight on how the compiler generated the code.  In this run, we can clearly see that we only collected samples on FP operations using x87.

If we plug the numbers into the formula:

MFLOPS Formula = FP_COMP_OPS_EXE.FP / 1x10⁶ / Elapsed Time

Elapsed time = CPU_CLK_UNHALTED.THREAD / Processor-Frequency / Number-of-Cores

Elapsed Time = 607,652,000,000.00 / 3.33 x 10⁹ / 12 = 15.206 secs

MFLOP = 18,470,000,000.00 / 1x10⁶/ 15.206 secs = 1,214.652 MFLOPS

Using SSE registers

Now, let's look at the same application when SSE registers are used.  If we compile the application using Intel® compiler version 12.0, we see the following results under the VTune^TM Amplifier XE.

One thing you will notice right away in the new result displayed is the difference in the function names where the samples are happening.  In the earlier example, we were getting the samples in matrixMultiply function, but now we see the samples in threadPool function.  This is due to inlining (for more information: http://en.wikipedia.org/wiki/Inline_expansion). Drilling down into the threadPool makes this clear.

We multiply FP_COMP_OPS_EXE.SSE_DOUBLE_PRECISION event by 2 because two packed double precision floating operations can be performed on 128 bit XMM registers in every clock. For single precision floating point operations, the total count for packed single precision floating operations needs to be multiplied by 4.

MFLOPS Formula = 2 * FP_COMP_OPS_EXE.SSE_DOUBLE_PRECISION / 1x10⁶ / Elapsed Time

Elapsed time = CPU_CLK_UNHALTED.THREAD / Processor-Frequency / Number-of-Cores

Elapsed time = (66,178,000,000 / 3.33 x10⁹ / 12 ) =  1.656 secs

MFLOPS = 2 * FP_COMP_OPS_EXE.SSE_DOUBLE_PRECISION / 1 x 10⁶ / 1.656 secs =  11,053.140 MFLOPS

Introduction : 

The data volumes which researchers and engineers analyze nowadays in their daily tasks are huge and continue to increase. The size of datasets which are generated each day for solution of research or engineering problems can achieve hundred gigabytes, while the whole data array sizes have crossed terabyte threshold. To analyze the data in timely fashion and to enable faster and more accurate decision making, one needs a better tool stack. It includes not only the most powerful computer, but also the best software tools to effectively explore all capacities of the computer.

Intel® Math Kernel Library (MKL) team identified a set of statistical computationally intensive algorithms which are used on the different stages of the data analysis, and optimized those algorithms for the x86 multi-core platforms. Those statistical functions are available in Intel® MKL 10.3 under Vector Statistical Library (VSL) chapter and are referred as Summary Statistics. VSL Summary Statistics provides the instruments for the fast, accurate and reliable data analysis on multi-core CPU. 


Functionality : 

VSL Summary Statistics contains the set of the computational blocks that helps to get insight into the structure of the dataset from the different perspectives. This dataset is store in matrix form. It contains number of observations, sequence of n vectors; and each observation has the value of p variables (or p dimension of the task). Using VSL Summary Statistics algorithms, you can compute the basic statistical estimates like moments or quantiles for your observation matrix, estimate dependencies in the dataset, or even process the incomplete or noised data which are related to imperfect measurement process.
Based on the type of the estimates and the structure of the dataset we classify the Summary Statistics algorithms in the following way:

       Computation of the basic statistical estimates for observations matrix:
           - Moments, skewness, kurtosis, variation coefficient, quantiles and order statistics
       Analysis of the datasets that have missing points
           - Restoring the basic statistical characteristics in presence of missed observations
       Analysis of the noised dataset, the one that contains artifacts (outliers)
           - Detection of outliers, robust (to noise) estimates of the covariance matrix and mean
       Analysis of the dependencies
           - Variance-covariance/correlation matrix, partial variance-covariance/correlation matrix, 
              pooled/group variance-covariance/correlation matrix
           - Parameterization (stabilization) of the correlation matrix

Typically, the algorithms for support of missing values and detection of outliers can be used for so called data cleaning when the initial analysis of the raw data that became available as result of a research experiment or a measurement of an object, or a sociological survey.

As soon as you clean the raw data, complete the initial analysis of the raw data, and apply some other steps like the data transformation using other MKL routines, you can use the rich set of the Summary Statistics estimators to learn the structure of the data array. With basic statistical estimates like mean or standard deviation you will obtain the first impression about your data. The advanced analysis would involve computation of the quantiles for understanding the distribution properties of the data, variance-covariance matrices - for revealing the dependencies between the components of the observed random vector, or computation of the robust version of the basic estimates.

The algorithms for estimation of dependencies are the important building blocks in the algorithms for signal processing, gene analysis, real-time analysis of the financial data, and portfolio management problems. In addition to “classical” covariance you will find more covariance algorithms in the library like pooled/group covariance which is used in the linear discriminant analysis for face recognition or gene expression level estimation and partial covariance used underneath filtering problems. In the real-life problems which involve intensive real-data based computation of the covariance matrix you may run in the situation when the matrix losses the property of positive semi-definiteness (PSD) due to spurious observations. In some problems you may also want to modify the entries of the matrix to integrate additional information about the object, and thus can impact on PSD. To help you to quickly restore PSD property of the correlation matrix the library provides the tool for parameterization of correlation matrix.

While more and more advanced methodologies for data collection (like microarray approach for the gene expression) are designed and become available, the process for object measurement is not free of spurious data and artifacts. To minimize impact of the noise on the final statistical conclusions you may use the robust methods available in the library.

There is a number of the problems in which the size of the raw data is huge and can’t fit into memory of the computer or the observation matrix become available in blocks only (like in astronomy or in real-time trading systems). Some of Summary Statistics routines are designed in the way that helps to easily address progressive, block-based analysis. In particular, you may provide the data, block-by block, to the algorithm for computation of covariance and, eventually, after processing the last data block will have the covariance estimate for the whole dataset. For another estimate, quantile, the library provides the version for streaming data: for price of pre-defined estimation error and one pass over the data you will obtain the distribution structure of the whole dataset without a need to return back to the processed chunks of the data.

Another important feature of the VSL Summary Statistics - the opportunity to store the observation matrix and results of the computations in one of the predefined formats: all algorithms of the library process the dataset held in raw-major and column-major format; based on the request of the user, the covariance estimators return the result in full or packed storage format.


Usage Model : 

API of VSL Summary Statistics is similar to that of other MKL features (Convolution / Correlation, FFT, RNGs). The minimal set of entry points into the library, scalability, and support of Object-Oriented Programming – the major drivers behind the library API.
The key element of Summary Statistics API is task object which is a data structure that holds the parameters related computation of Summary Statistics. All Summary Statistics operations are done in the context of this task. The typical Summary Statistics usage model consists of four steps shown on the scheme below:

          Step 1: task construction
                     status = vsldSSNewTask(&task, &p, &n, &x_storage, x, w, indices);
          Step 2: Editing the task parameters
                     status = vsldSSEditTask(task, VSL_SS_ED_MEAN, mean );
          Step 3: Computation of statistical estimates
                     status = vsldSSCompute(task, VSL_SS_MEAN, VSL_SS_METHOD_1PASS);
          Step 4: Destroying the task
                     status = vslSSDeleteTask(&task );

Here are three examples on how to use VSL Summary Statistics functionality in MKL:


Example 1 : In-memory datasets 

This example for estimation of the mean using one-pass method shows the typical four-stage approach of using VSL Summary Statistics functionality.

First, it creates a new task by passing the task descriptor, problem size (dimension of the random vector p and number of the observed vectors n), observation matrix, and its matrix storage format. Summary Statistics usage model admits assigning weights to each observation in the dataset, which are not negative numbers; in the example below, the null pointer to the array of weights is passed to the constructor, thus, the default weights equal to 1 are assigned to the observations and are used in the computations. Second, it initializes the task parameter, necessary for the solution of the specific problem of sample mean estimation by means of registering the array of result VSL_SS_ED_MEAN. Third, it computes the mean using one pass method VSL_SS_METHOD_1PASS. Finally, it calls the task destructor to release the memory resources.


#define DIM 1 /* Task dimension */
#define N 1000 /* Number of observations */
int main()
{
    VSLSSTaskPtr task; /* SS task descriptor */
    double x[N]; /* Array for dataset */
    double mean; /* Array for mean estimate */
    double* w = 0; /* Null pointer to array of weights, default weight equal to one will be used in the computation */
    MKL_INT p, n, xstorage;
    int status;

    /* Initialize variables used in the computation of mean */
    p = DIM;
    n = N;
    xstorage = VSL_SS_MATRIX_STORAGE_ROWS;
    mean = 0.0;
   
    /* Step 1 - Create task */
    status = vsldSSNewTask( &task, &p, &n, &xstorage, x, w, 0 );

    /* Step 2- Initialize task parameters */
    status = vsldSSEditTask( task, VSL_SS_ED_MEAN, &mean );

    /* Step 3 - Compute the mean estimate using SS one-pass method */
    status = vsldSSCompute(task, VSL_SS_MEAN, VSL_SS_METHOD_1PASS );

    /* Step 4 - deallocate task resources */
    status = vslSSDeleteTask( &task );

    return 0;
}

Example 2 : Out-of-memory datasets 

The example below is extension of the previous scheme to the case of out-of-memory datasets. While the example follows the same four-stage scheme, there are few modifications to the previous example done to support processing of out-of-memory dataset

• First, the example registers the auxiliary array in the library intended for holding accumulated weight and accumulated squared   weight which are just a sum of the observation weights and sum of the squares of the observation weights processed so far. It is necessary for the correct processing of the next available data block.
• Second, the example contains call to the function responsible for obtaining the next data block

The rest computations remain the same. As soon as the last data block is processed you will have the mean estimate for the  whole dataset.

#define DIM 1 /* Task dimension */
#define N 1000 /* Number of observations */
#define BLOCKN 100 /* Number of blocks */
int main()
{
    VSLSSTaskPtr task; /* SS task descriptor */
    double x[N]; /* Array for dataset */
    double mean; /* Array for mean estimate */
    double W[2]; /* Array of accumulated weights */ 
    MKL_INT p, n, xstorage  
    int status, block_idx;

    /* Initialize variables used in the computation of mean */
    p = DIM; n = N;
    mean = 0.0;
    W[0] = 0.0; W[1] = 0.0;
    xstorage = VSL_SS_MATRIX_STORAGE_ROWS;

    /* Create task */
    status = vsldSSNewTask( &task, &p, &n, &xstorage, x, 0, 0 );

    /* Initialize task parameters */
    status = vsldSSEditTask( task, VSL_SS_ED_MEAN, &mean );
    status = vsldSSEditTask( task, VSL_SS_ED_ACCUM_WEIGHT, W );

    /* Compute the mean estimate for block-based data using SS one-pass method */
    for( block_idx = 0; block_idx++; )
   {
          status = vsldSSCompute( task, VSL_SS_MEAN, VSL_SS_METHOD_1PASS );
          if ( block_idx >= NBLOCK )
                break;
          else
                GetNextDataBlock( x, N ); } 

     /* De-allocate task resources */
     status = vslSSDeleteTask( &task );
     return 0;
   }

Example 3 : Do several estimations simultanenously 

This example shows how to compute several statistical estimates for same data set. Let us assume that we need mean, variance, variation coefficient, and covariance in the statistical analysis. The computational scheme is the same and similar to those considered in the previous examples. We just need to modify those parameters in the task which are associated with the estimates we are interested in, that is we need to register the pointers to the memory which would hold the results and storage format for covariance matrix. In the code below, we use the editor for Moments vsldSSEditMoments, the editor for covariance vsldSSEditCovCor , and the generic editor for variation vsldSSEditTask to specify task parameters. We also use statement consisted four kind of estimations that will be use in the compute stage.


#define DIM 2 /* Task dimension */
#define N 1000 /* Number of observations */
int main()
{
    VSLSSTaskPtr task; /* SS task descriptor */
    double x[DIM*N]; /* Dataset array */
    double mean[DIM],variation[DIM], r2m[DIM], c2m[DIM];
    /* mean/variation/2nd raw/2nd central moments */

    double cov[DIM*DIM];
    double* w = 0;
    MKL_INT p, n, xstorage, covstorage;
    int status;

    /* Initialize variables */
    p = DIM; n = N;
    xstorage = VSL_SS_MATRIX_STORAGE_ROWS;
    covstorage = VSL_SS_MATRIX_STORAGE_FULL;

    /* Create task */ errcode = vsldSSNewTask( &task, &p, &n, &xstorage, x, w, 0 );

    /* Edit task parameters */
    errcode = vsldSSEditTask( task, VSL_SS_ED_VARIATION, variation );
    errcode = vsldSSEditMoments( task, mean, r2m, 0, 0, c2m, 0, 0 );
    errcode = vsldSSEditCovCor( task, mean, cov, &covstorage, 0, 0 );

    /* Computation of several estimates using 1PASS method */
    estimates = VSL_SS_MEAN|VSL_SS_2C_MOM|VSL_SS_COV| VSL_SS_VARIATION;
    status = vsldSSCompute( task, estimates, VSL_SS_METHOD_1PASS );

    /* De-allocate task resources */
    status = vslSSDeleteTask( &task );
    return 0;
}

Note that some statistical estimators compute additional estimates if they are not explicitly requested by the user, e.g., the algorithm for covariance estimation also computes mean estimate. In order to provide the correct processing of such estimates you need to allocate the memory for those additional estimates, and to register pointers to this memory in the library. See [SSApp] for more details.


Summary : 

In this article, we describe the Summary Statistics Library functionality, usage model and examples under Intel® MKL VSL. The examples provided in the article demonstrate the ease of use of VSL Summary Statistics in different cases, e.g., processing of out-of-memory data, and simultaneous estimation of several statistical estimates. The additional information about API, usage models are available in [MKLMan] and [SSApp].


Bibliography : 

[MKLMan] Intel® MKL Manual, http://software.intel.com/en-us/articles/intel-math-kernel-library-documentation/

[SSApp]Summary Statistics Application Notes,
http://software.intel.com/en-us/articles/intel-math-kernel-library-documentation/

This time, it is the Notepad++ 5.8.2 project that we chose for the test.

Notepad++

At first a couple of words about the project we have chosen. Notepad++ is an open-source and free source code editor that supports many languages and appears a substitute for the standard Notepad. It works in the Microsoft Windows environment and is released under the GPL license. What I liked about this project is that it is written in C++ and has a small size - just 73000 lines of code. But what is the most important, this is a rather accurate project - it is compiled by presence of the /W4 switch in the project's settings and /WX switch that makes analyzers treat each warning as an error.

Static analysis by compiler

Now let's study the analysis procedure from the viewpoints of a compiler and a separate specialized tool. The compiler is always inclined to generating warnings after processing only very small local code fragments. This preference is a consequence of very strict performance requirements imposed on the compiler. It is no coincidence that there exist tools of distributed project build. The time needed to compile medium and large projects is a significant factor influencing the choice of development methodology. So if developers can get a 5% performance gain out of the compiler, they will do it.

Such optimization makes the compiler solider and actually such steps as preprocessing, building AST and code generation are not so distinct. For instance, I may say relying on some indirect signs that Visual C++ uses different preprocessor algorithms when compiling projects and generating preprocessed "*.i" files. The compiler also does not need (it is even harmful for it) to store the whole AST. Once the code for some particular nodes is generated and they are no more needed, they get destroyed right away. During the compilation process, AST may never exist in the full form. There is simply no need for that - we parse a small code fragment, generate the code and go further. This saves memory and cache and therefore increases speed.

The result of this approach is "locality" of warnings. The compiler consciously saves on various structures that could help it detect higher-level errors. Let's see in practice what local warnings Intel C++ will generate for the Notepad++ project. Let me remind you that the Notepad++ project is built with the Visual C++ compiler without any warnings with the /W4 switch enabled. But the Intel C++ compiler certainly has a different set of warnings and I also set a specific switch /W5 [Intel C++]. Moreover, I would like to have a look at what the Intel C++ compiler calls "remark".

Let's see what kinds of messages we get from Intel C++. Here it found four similar errors where the CharUpper function is being handled (Look at the note at the end of text). Note the "locality" of the diagnosis - the compiler found just a very dangerous type conversion. Let's study the corresponding code fragment:

wchar_t *destStr = new wchar_t[len+1];
...
for (int j = 0 ; j < nbChar ; j++)
{
  if (Case == UPPERCASE)
    destStr[j] =
      (wchar_t)::CharUpperW((LPWSTR)destStr[j]);
  else
    destStr[j] =
      (wchar_t)::CharLowerW((LPWSTR)destStr[j]);
}

Here we see strange type conversions. The Intel C++ compiler warns us: "#810: conversion from "LPWSTR={WCHAR={__wchar_t} *}" to "__wchar_t" may lose significant bits". Let's look at the CharUpper function's prototype.

LPTSTR WINAPI CharUpper(
  __inout  LPTSTR lpsz
);

The function handles a string and not separate characters at all. But here a character is cast to a pointer and some memory area is modified by this pointer. How horrible.

Well, actually this is the only horrible issue detected by Intel C++. All the rest are much more boring and are rather inaccurate code than error-prone code. But let's study some other warnings too.

The compiler generated a lot of #1125 warnings:

"#1125: function "Window::init(HINSTANCE, HWND)" is hidden by "TabBarPlus::init" -- virtual function override intended?"

These are not errors but just poor naming of functions. We are interested in this message for a different reason: although it seems to involve several classes for the check, the compiler does not keep special data - it must store diverse information about base classes anyway, that is why this diagnosis is implemented.

The next sample. The message "#186: pointless comparison of unsigned integer with zero" is generated for the meaningless comparisons:

static LRESULT CALLBACK hookProcMouse(
  UINT nCode, WPARAM wParam, LPARAM lParam)
{
  if(nCode < 0)
  {
    ...
    return 0;
  }
...
}

The "nCode < 0" condition is always false. It is a good example of good local diagnosis. You may easily find an error this way.

Let's consider the last warning by Intel C++ and get finished with it. I think you have understood the concept of "locality".

void ScintillaKeyMap::showCurrentSettings() {
  int i = ::SendDlgItemMessage(...);
  ...
  for (size_t i = 0 ; i < nrKeys ; i++)
  {
    ...
  }
}

Again we have no error here. It is just poor naming of variables. The "i" variable has the "int" type at first. Then a new "i" variable of the "size_t" type is defined in the "for()" operator and is being used for different purposes. At the moment when "size_t i" is defined, the compiler knows that there already exists a variable with the same name and generates the warning. Again, it did not require the compiler to store any additional data - it must remember anyway that the "int i" variable is available until the end of the function's body.

Third-party static code analyzers

Now let's consider specialized static code analyzers. They do not have such severe speed restrictions since they are launched ten times less frequently than compilers. The speed of their work might get tens of times slower than code compilation but it is not crucial: for instance, the programmer may work with the compiler at day and launch a static code analyzer at night to get a report about suspicious fragments on the morning. It is quite a reasonable approach.

While paying with slow-down for their work, static code analyzers can store the whole code tree, traverse it several times and store a lot of additional information. It lets them find "spreaded" and high-level errors.

Let's see what the PVS-Studio static analyzer can find in Notepad++. Note that I am using a pilot version that is not available for download yet. We will present the new free general-purpose rule set in 1-2 months within the scope of PVS-Studio 4.00.

Surely, the PVS-Studio analyzer finds errors that may be referred to "local" like in case of Intel C++. This is the first sample:

bool _isPointXValid;
bool _isPointYValid;
bool isPointValid() {
  return _isPointXValid && _isPointXValid;
};

The PVS-Studio analyzer informs us: "V501: There are identical sub-expressions to the left and to the right of the '&&' operator: _isPointXValid && _isPointXValid".

I think the error is clear to you and we will not dwell upon it. The diagnosis is "local" because it is enough to analyze one expression to perform the check.

Here is one more local error causing incomplete clearing of the _iContMap array:

#define CONT_MAP_MAX 50
int _iContMap[CONT_MAP_MAX];
...
DockingManager::DockingManager()
{
  ...
  memset(_iContMap, -1, CONT_MAP_MAX);
  ...
}

Here we have the warning "V512: A call of the memset function will lead to a buffer overflow or underflow". This is the correct code:

memset(_iContMap, -1, CONT_MAP_MAX * sizeof(int));

And now let's go over to more interesting issues. This is the code where we must analyze two branches simultaneously to see that there is something wrong:

void TabBarPlus::drawItem(
  DRAWITEMSTRUCT *pDrawItemStruct)
{
  ...
  if (!_isVertical)
    Flags |= DT_BOTTOM;
  else
    Flags |= DT_BOTTOM;
  ...
}

PVS-Studio generates the message "V523: The 'then' statement is equivalent to the 'else' statement". If we review the code nearby, we may conclude that the author intended to write this text:

if (!_isVertical)
  Flags |= DT_VCENTER;
else
  Flags |= DT_BOTTOM;

And now get brave to meet a trial represented by the following code fragment:

void KeyWordsStyleDialog::updateDlg() 
{
  ...
  Style & w1Style =
    _pUserLang->_styleArray.getStyler(STYLE_WORD1_INDEX);
  styleUpdate(w1Style, _pFgColour[0], _pBgColour[0],
    IDC_KEYWORD1_FONT_COMBO, IDC_KEYWORD1_FONTSIZE_COMBO,
    IDC_KEYWORD1_BOLD_CHECK, IDC_KEYWORD1_ITALIC_CHECK,
    IDC_KEYWORD1_UNDERLINE_CHECK);

  Style & w2Style =
    _pUserLang->_styleArray.getStyler(STYLE_WORD2_INDEX);
  styleUpdate(w2Style, _pFgColour[1], _pBgColour[1],
    IDC_KEYWORD2_FONT_COMBO, IDC_KEYWORD2_FONTSIZE_COMBO,
    IDC_KEYWORD2_BOLD_CHECK, IDC_KEYWORD2_ITALIC_CHECK,
    IDC_KEYWORD2_UNDERLINE_CHECK);

  Style & w3Style =
    _pUserLang->_styleArray.getStyler(STYLE_WORD3_INDEX);
  styleUpdate(w3Style, _pFgColour[2], _pBgColour[2],
    IDC_KEYWORD3_FONT_COMBO, IDC_KEYWORD3_FONTSIZE_COMBO,
    IDC_KEYWORD3_BOLD_CHECK, IDC_KEYWORD3_BOLD_CHECK,
    IDC_KEYWORD3_UNDERLINE_CHECK);

  Style & w4Style =
    _pUserLang->_styleArray.getStyler(STYLE_WORD4_INDEX);
  styleUpdate(w4Style, _pFgColour[3], _pBgColour[3],
    IDC_KEYWORD4_FONT_COMBO, IDC_KEYWORD4_FONTSIZE_COMBO,
    IDC_KEYWORD4_BOLD_CHECK, IDC_KEYWORD4_ITALIC_CHECK,
    IDC_KEYWORD4_UNDERLINE_CHECK);
  ...
}

I can say that I am proud of our analyzer PVS-Studio that managed to find an error here. I think you have hardly noticed it or just have skipped the whole fragment to see the explanation. Code review is almost helpless before this code. But the static analyzer is patient and pedantic: "V525: The code containing the collection of similar blocks. Check items '7', '7', '6', '7' in lines 576, 580, 584, 588".

I will abridge the text to point out the most interesting fragment:

styleUpdate(...
  IDC_KEYWORD1_BOLD_CHECK, IDC_KEYWORD1_ITALIC_CHECK,
  ...);
styleUpdate(...
  IDC_KEYWORD2_BOLD_CHECK, IDC_KEYWORD2_ITALIC_CHECK,
  ...);
styleUpdate(...
  IDC_KEYWORD3_BOLD_CHECK, !!! IDC_KEYWORD3_BOLD_CHECK !!!,
  ...);
styleUpdate(...
  IDC_KEYWORD4_BOLD_CHECK, IDC_KEYWORD4_ITALIC_CHECK,
  ...);

This code was most likely written by the Copy-Paste method. As a result, it is IDC_KEYWORD3_BOLD_CHECK which is used instead of IDC_KEYWORD3_ITALIC_CHECK. The warning looks a bit strange reporting about numbers '7', '7', '6', '7'. Unfortunately, it cannot generate a clearer message. These numbers arise from macros like these:

#define IDC_KEYWORD1_ITALIC_CHECK (IDC_KEYWORD1 + 7)
#define IDC_KEYWORD3_BOLD_CHECK (IDC_KEYWORD3 + 6)

The last cited sample is especially significant because it demonstrates that the PVS-Studio analyzer processed a whole large code fragment simultaneously, detected repetitive structures in it and managed to suspect something wrong relying on heuristic method. This is a very significant difference in the levels of information processing performed by compilers and static analyzers.

Some figures

Let's touch upon one more consequence of "local" analysis performed by compilers and more global analysis of specialized tools. In case of "local analysis", it is difficult to make it clear if some issue is really dangerous or not. As a result, there are ten times more false alarms. Let me explain this by example.

When we analyzed the Notepad++ project, PVS-Studio generated only 10 warnings. 4 messages out of them indicated real errors. The result is modest, but general-purpose analysis in PVS-Studio is only beginning to develop. It will become one of the best in time.

When analyzing the Notepad++ project with the Intel C++ compiler, it generated 439 warnings and 3139 remarks. I do not know how many of them point to real errors, but I found strength to review some part of these warnings and saw only 4 real issues related to CharUpper (see the above description).

3578 messages are too many for a close investigation of each of them. It turns out that the compiler offers me to consider each 20-th line in the program (73000 / 3578 = 20). Well, come on, it's not serious. When you are dealing with a general-purpose analyzer, you must cut off as much unnecessary stuff as possible.

Those who tried the Viva64 rule set (included into PVS-Studio) may notice that it produces the same huge amount of false alarms. But we have a different case there: we must detect all the suspicious type conversions. It is more important not to miss an error than not to produce a false alarm. Besides, the tool's settings provide a flexible filtering of false alarms.

UPDATE: Note

It turned out that I had written a wrong thing here. There is no error in the sample with CharUpperW but nobody corrected me. I noticed it myself when I decided to implement a similar rule in PVS-Studio.

The point is that CharUpperW can handle both strings and individual characters. If the high-order part of a pointer is zero, the pointer is considered a character and not pointer any more. Of course, the WIN API interface in this place disappointed me by its poorness, but the code in Notepad++ is correct.

By the way, it turns out now that Intel C++ has not found any errors at all.