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

For early adopters we introduced support of AVX in Intel® Software Development Emulator [2], it allows you to run and check functional correctness of the code with the actual AVX instructions before hardware is available.

Today we are adding another useful piece to help those who may not be able to use new tools supporting AVX in their current development environment but plan to migrate in the future or are using a software platform which is not supported by Intel SDE. These software developers can still start programming with Intel AVX using intrinsics.

Here we are providing the C and C++ header file which emulates Intel AVX intrinsics. The AVX emulation header file uses intrinsics for the prior Intel instruction set extensions up to Intel SSE4.2. SSE4.2 support in your development environment as well as hardware is required in order to use the AVX emulation header file.

To use simply have this file included:

#include "avxintrin_emu.h"

Instead of usual:

#include <immintrin.h>

One can also create alternative immintrin.h file (which in turn includes avxintrin_emu.h) to avoid an intrusive change to the source base and then simply switch between real AVX code generation and emulation via alternating the path to include directories.

Emulation header is primarily targeting UNIX type of environments, and was tested on such with GCC and Intel C/C++ compilers. We have a strong support with other tools (compilers, assemblers and SDE) on Microsoft Windows platform, but this header file can still be used on Windows, if desired, with Intel Compiler.

Note that the AVX emulation header file is designed to allow functional correctness of an AVX implementation and not recommended for long-term usage or release in a final product. Once your development environment and hardware supports AVX, we recommend that you switch to the real AVX intrinsic header file.

Although we did our best to debug it, this file must not be considered a reference functional implementation of AVX instructions or even bug-free. Please see the current version's limitations and caveats in the beginning of the file. Please let us know about the issues you faced using it.

Example

#include "avxintrin_emu.h"  // #include <immintrin.h>

void saxpy( float a, const float* x, const float* y, float* __restrict z, size_t len )
{
    size_t i = 0;
    __m256 a_ = _mm256_set1_ps( a );

    for ( size_t len16_ = len & -16; i + 16 <= len16_; i += 16 )
    {
        __m256 x1_ = _mm256_loadu_ps( x + i );
        __m256 x2_ = _mm256_loadu_ps( x + i + 8 );

        __m256 y1_ = _mm256_loadu_ps( y + i );
        __m256 y2_ = _mm256_loadu_ps( y + i + 8 );

        x1_ = _mm256_mul_ps( x1_, a_ );
        x2_ = _mm256_mul_ps( x2_, a_ );

        x1_ = _mm256_add_ps( x1_, y1_ );
        x2_ = _mm256_add_ps( x2_, y2_ );

        _mm256_storeu_ps( z + i     , x1_ );
        _mm256_storeu_ps( z + i + 8 , x2_ );
    }

    for ( ; i < len; ++i )
        z[i] = x[i] * a + y[i];
}

References

[1] Intel AVX - http://software.intel.com/en-us/avx/

[2] Intel Software Development Emulator - http://software.intel.com/en-us/articles/intel-software-development-emulator/

Using both of these technologies at the same time has the following implications...

• Binaries under analysis of Inspector may be interrupted by dialogue boxes
  • Press the "ignore" button- execution will continue (recommended action) - note: you may have to press "ignore" multiple times - as by default this dialogue box will appear every so many instances for each unique error detected.
  • Do not press the "abort" button - as that will exit the application before Intel Parallel Inspector can give you a list of all memory errors, and Intel Parallel Inspector may report false positives as your application exited prematurely.
  • Do not press the “retry” button in the dialog box, else - the debugger will open and point you to assembly code that was "generated" as a result of running your application under the  Inspector analysis engine rather than the assembly of your application (not recommended)
• The same issue may be reported by both technologies.
• Performance will suffer as both technologies are tracking and checking memory usage

You may want to turn off the Debug Heap Manager provided by the Microsoft C runtime library.

There is only one way to "turn off" the debug heap manager... and that is:

•   Use the Release/Base version of the Microsoft C runtime library by compiling with either /MD or /MT

In the ideal situation, it is recommended that you use /Od with memory error analysis in Intel Parallel Inspector with the /MD or /MT runtime library selections. By default a "debug" configuration in Visual Studio will select /MDd or /MTd settings rather than the /MD or /MT settings. You would need to check these settings for each project in your solution.  Note: It can be difficult to accomplish this on large projects - as it will be difficult to have the same runtime library used in your entire application (all dll(s), lib(s), etc).

Another way, to work around this problem - is to tell the "debug" version of the heap manager to disable heap checking and reporting (tracking still occurs with this method).  This can be done using the _CrtSetDbgFlag api.  An example follows showing a code snippet which turns these features off.

#include <crtdbg.h>

main() {

int oriDbgFlag, newDbgFlag;

oriDbgFlag = _CrtSetDbgFlag(_CRTDBG_REPORT_FLAG);

newDbgFlag &= ~_CRTDBG_ALLOC_MEM_DF; //Turn this off (by default it is on)

newDbgFlag |= _CRTDBG_CHECK_ALWAYS_DF;  //Turn this on (by default it is off)

newDbgFlag &= ~_CRTDBG_CHECK_CRT_DF;  //Not needed as this is default

newDbgFlag &= ~_CRTDBG_DELAY_FREE_MEM_DF; //Not needed as this is default

newDbgFlag &= ~_CRTDBG_LEAK_CHECK_DF; //Not needed as this is default

newDbgFlag = (newDbgFlag & 0x0000FFFF) | _CRTDBG_CHECK_DEFAULT_DF; //Not needed as this is default

newDbgFlag = _CrtSetDbgFlag(newDbgFlag);

//...

For more information look for _CrtSetDbgFlag at MSDN.

Potential dialogue boxes/messages that the debug heap manager of the Microsoft C runtime library may produce, which can be suppressed using the techniques above (when under analysis of Intel Parallel Inspector):

Client hook allocation failure at file

Client hook allocation failure %hs line

Invalid allocation size:

Error: memory allocation: bad memory block type.

Client hook re-allocation failure at file %hs line.

Client hook re-allocation failure Or Error: memory allocation: bad memory block type.

Error: memory allocation: bad memory block type. The Block at 0x%p was allocated by aligned routines, use _aligned_realloc(). The Block at 0x%p was allocated by aligned routines, use _aligned_free()

Client hook free failure. HEAP CORRUPTION DETECTED: before %hs block (#%d) at 0x%p. CRT detected that the application wrote to memory before start of heap buffer.

HEAP CORRUPTION DETECTED: after %hs block (#%d) at 0x%p.

CRT detected that the application wrote to memory after end of heap buffer.

HEAP CORRUPTION DETECTED: after %hs block (#%d) at 0x%p.

CRT detected that the application wrote to memory after end of heap buffer.

_heapchk fails with _HEAPBADBEGIN.

_heapchk fails with _HEAPBADNODE.

_heapchk fails with _HEAPBADEND.

_heapchk fails with _HEAPBADPTR.

_heapchk fails with unknown return value!

HEAP CORRUPTION DETECTED: before %hs block (#%d) at 0x%p.

CRT detected that the application wrote to memory before start of heap buffer.

HEAP CORRUPTION DETECTED: before %hs block (#%d) at 0x%p.

CRT detected that the application wrote to memory before start of heap buffer.

HEAP CORRUPTION DETECTED: after %hs block (#%d) at 0x%p.

CRT detected that the application wrote to memory after end of heap buffer.

HEAP CORRUPTION DETECTED: after %hs block (#%d) at 0x%p.

CRT detected that the application wrote to memory after end of heap buffer.

HEAP CORRUPTION DETECTED: on top of Free block at 0x%p.

CRT detected that the application wrote to a heap buffer that was freed.

HEAP CORRUPTION DETECTED: on top of Free block at 0x%p.

CRT detected that the application wrote to a heap buffer that was freed.

%hs located at 0x%p is %Iu bytes long.

Bad memory block found at 0x%p.

Detected memory leaks!

Damage before 0x%p which was allocated by aligned routine