The High-level API is being implemented using the SCRUM method, where functionality is built up in stages. This way we are able to share incremental high quality releases on a regular basis. This version of the High Level API holds partial functionality but has been tested and found to be of high quality (validated against Intel AMT 3.2 and above.) The main theme of this package is an easier to use interface for developing applications for Intel® AMT.

Note: This software is provided for purposes of demonstration and experimentation only and therefore there is currently no technical support for this package.

Introduction to the High-level API Intel Management Library Technology

The Intel Manageability Library, or High Level API (HLA), provides an easier to use interface for developing applications that work with systems equipped with Intel® Active Management Technology (Intel® AMT).

The library is written in C#, for Microsoft Windows* systems and is intended to be complementary to the Intel® AMT SDK.

Features include:

This release supports the following features which have been through validation cycles:

• Hardware Asset
• Remote Control / Power
• Storage

This release includes the following components:

• HLAPI Library - HLAPI interface and implementation
• HLA_CLI - A command line tool to invoke the currently supported features
• HardwareCmdDll - A DLL for demonstrating the HardwareInventory feature, used by HLA_CLI
• PowerCmdDLL - A DLL for demonstrating the power management feature
• StorageCmdDll - A DLL for demonstrating the Storage feature
• HLA.sln - A Visual Studio 2008 solution file for building everything

Once everything is built, you can either run the command line sample directly inside a DOS prompt window, or you can modify the debug settings for the command of interest to point to your AMT system (IP address / host name), user name and password, and run the sample from within Visual Studio 2008.

Creating a C# Application:

To create a C# application that uses the HLA and runs with Intel AMT Release 6.0, add references to the following DLLs, located in the Bin in the distribution:

• HLA.sln - A Visual Studio 2008 solution file for building everything
• CIMFramework.dll
• DotNetWSManClient.dll

The DLLs and sample application require that the .NET Framework 3.0 be installed. Recompiling the source code requires Visual Studio 2008, which requires that the .NET Framework 3.5 be installed.

* Please note that the terms of the software license agreement included with any software you download will control your use  of the software.

Whether you want to get deeper mobile content than ever before, take a sneak preview of the latest tools, netbooks and apps, meet with top experts of the mobile industry, socialize at one of the many structured or informal MWC community gatherings or have a deeper insight to our new Intel AppUp Center... then Mobile World Congress 2010 is for you!

For more information please visit the official MWC web site - or just follow us on Twitter.

Read our latest Mobile World Congress related blog posts:

Intel® Parallel Amplifier

Update 2:

· Now Microsoft Windows 7* is supported.

· Several minor bugs were fixed.

Update 1:

· Added a command line interface for regression analysis. Now you can automate tests you want to run frequently. (see "About the Intel® Parallel Amplifier Command-line Interface" in the Visual Studio* integrated help)

· Better performance. Collection is faster and results finalization is faster.

· CPU time accuracy is improved for applications with short scheduler time slices.

· New data collection options, including limiting the size of the data collected.

· Compare results can now open the source view.

· Several minor bugs were fixed.

Intel® Parallel Amplifier Release Notes

When running the Intel IPP v6.1 crypto sample for OpenSSL (ipp-samples/cryptography/openssl-ipp) on Intel® Hyper-Threading (Intel HT Technology) processors, users may find the AES benchmark application reports degraded performance when compared to the non-IPP version of OpenSSL.

Cause:

This is caused by conflicting OpenMP thread model settings for Intel HT Technology systems.

The Intel IPP crypto sample for OpenSSL links with the dynamic Intel IPP libraries, by default, which enables the use of internal threading (OpenMP) in the threaded Intel IPP AES functions. To overcome this problem, which is associated with how the OpenMP threading mechanism allocates threads within the IPP library, one must adjust the number of available threads and specify the threading affinity model.

Intel HT is most effective when each thread that is sharing an HT-enabled core is performing different types of operations and processor resources on the core are under-utilized. The threaded AES functions in the Intel IPP library execute at high efficiency, consuming most of the available processor resources and performing identical operations on each thread. Thus, these multi-threaded functions generally do not fare well if they are allocated to run side-by-side on a single HT core. It is better to have these threads run on separate cores.

To accommodate this need for thread isolation one must insure that the number of threads available to the OpenMP threading mechanism is equal to the number of cores, not the number of logical threads. (The default number of logical threads equals 2x the number of cores on an Intel HT processor or 1x the number of cores on a non-HT processor.) Moreover, when running the Intel IPP crypto sample on an Intel HT system, the thread scheduler must also be told to assign each crypto thread to a single core, ignoring the second HT thread available on each core. The net effect of applying these two guidelines will direct OpenMP to limit threading to the number of available cores and to spread those threads evenly over those cores.

Resolution:

There are several avenues available to address this issue. There is no “best” or “worst” solution, the best solution depends on your application and system needs.

If the multi-core processor on your system includes Intel HT (each core supports two hardware threads), for example an Intel Core i7 or Westmere processor, you should use one of the following solutions:

1. disable multi-threading by linking with the static single-threaded version of the Intel IPP library
2. disable multi-threading within the multi-threaded Intel IPP libraries by calling ippSetNumThreads(1)
3. disable Intel HT Technology on your system (usually done via a configuration switch in the BIOS)
4. configure OpenMP to use 1/2 of the available logical threads
   and set the KMP_AFFINITY environment variable as follows: KMP_AFFINITY=granularity=fine, compact,1,0

Note that the Intel IPP library overrides the OMP_NUM_THREADS environment variable, so you must use the following technique within your application to set the number of available logical threads to 1/2 the number of hardware threads:

ippGetNumThreads( &numThreads ) ;
ippSetNumThreads( numThreads/2 ) ;

See the IPP library documentation for more information regarding the above functions.

If the multi-core processor on your system does not include Intel HT (each core only supports a single hardware thread), for example an Intel Core 2 Duo or Core 2 Quad processor, you do not need to do anything. The IPP library will automatically configure OpenMP to utilize no more hardware threads than you have available on your system. You may still want to set the OpenMP affinity to a value that will optimize the IPP library for best operation on your system by setting the KMP_AFFINITY environment variable as follows:

KMP_AFFINITY=compact
or
KMP_AFFINITY=granularity=fine,compact,0,0

This will configure OpenMP to more readily exploit a shared cache, and is especially important on those processors that have multiple physical dies within a single package or those systems that have multiple sockets on the motherboard (which results in a dedicated cache per core).

More Information:

For more information on how these OpenMP directives work please see the Intel Compiler documentation pages. The section on the Thread Affinity Interface, in particular, should be helpful.

See this Intel Software Network blog entry for more information about OpenMP and the IPP library.

A new Intel IPP interface to address thread affinity is being considered for inclusion in future releases of the Intel IPP library.

To get details about the specific processor on your system, such as how many cores it contains and whether or not those cores support Intel HT, you can compile and run the CPU Information Utility found in the IPP samples (advanced-usage\cpuinfo) or visit ark.intel.com and locate your specific processor in this on-line database.

In this article, "32-bit" will refer to an application built with a compiler "for applications running on IA-32", even if it is run on a 64-bit version of Windows.  In the Visual Studio* environment, this is a "Win32" platform target.  "64-bit" refers to an application built with a compiler "for applications running on Intel 64" and run on an "x64" variant of Windows. In the Visual Studio environment, this is an "x64" platform target.  Note that 64-bit applications will not run on a 32-bit variant of Windows.

There are three kinds of memory limits:

• Static code and data - this is all the compiled code plus all static data.  In C or C++, static data is generally created by variables and structs declared at "file scope", outside of a procedure.  In Fortran, COMMON and module variables are always static.  Variables declared in main programs and in procedures may or may not be static - by default, non-ALLOCATABLE/POINTER arrays are static and scalars are not.  Any variable marked as SAVE or data-initialized is static.
• Dynamic data - this is memory that is allocated during program execution.  In or C or C++ this is usually done with malloc or new; in Fortran it is done with ALLOCATE or malloc.
• Stack data - this is memory that is allocated as a procedure is entered and deallocated when the procedure exits. In C or C++, most routine local variables and variables declared inside blocks are allocated on the stack. In Fortran, automatic arrays (with dimensions based on a dummy argument, common or module variable) are stack-allocated.  Fortran code, in particular, may create temporary copies of arrays on the stack as needed to satisfy language semantics.  In Fortran, a routine declared RECURSIVE uses stack allocation for all local variables (other than POINTER and ALLOCATABLE), and enabling OpenMP also results in variables being allocated on the stack by default.

Given these definitions, the following lists the limits on 32-bit and 64-bit variants of Windows:

32-bit

• Static data - 2GB
• Dynamic data - 2GB
• Stack data - 1GB (the stack size is set by the linker, the default is 1MB.  This can be increased using the Linker property System > Stack Reserve Size)

Note that on 32-bit Windows, the sum of all types of data must be 2GB or less.  The practical limit is about 1.75GB due to space used by Windows itself

64-bit

• Static data - 2GB
• Dynamic data - 8TB
• Stack data - 1GB (the stack size is set by the linker, the default is 1MB.  This can be increased using the Linker property System > Stack Reserve Size)

Note that the limit on static and stack data is the same in both 32-bit and 64-bit variants.  This is due to the format of the Windows Portable Executable (PE) file type, which is used to describe EXEs and DLLs as laid out by the linker. It has 32-bit fields for image section offsets and lengths and was not extended for 64-bit variants of Windows. As on 32-bit Windows, static data and stack share the same first 2GB of address space.

If you exceed the limit on static code and data you may see the following error when the application is linked:

LNK1248: image size ('size') exceeds maximum allowable size (80000000)

Another possibility is that the application will appear to link successfully, but when run you will see:

<program-name> is not a valid Win32 application

It is important to note that these are Windows operating system limits and are not constraints imposed by the compilers.

Resolving the Problem

If you are running a 32-bit application, you will need to switch to a 64-bit build and run on a 64-bit variant of Windows.  But even on a 64-bit variant, you must reduce the size of static data.  The best way to do that is to change to dynamic allocation for large arrays.  In C and C++ this is done with pointers and malloc.  In Fortran, replace large static arrays with ALLOCATABLE arrays and allocate them to the desired size at the start of the program. In many cases, you can replace COMMON declarations with variables declared in a module, and USE that module where you would have included the COMMON statements.  Note that you cannot use data-initialization for ALLOCATABLE arrays - such initialization must be in executable code.

If you have questions about appropriate techniques, please ask them in our user forums.

Note: you can build custom processor-specific libraries that do not require the dispatcher, but that is outside the scope of this article. Please read this IPP linkage models article for information on how to build custom versions of the IPP library.

Dispatching refers to the process of detecting CPU features at run-time and then selecting the Intel IPP optimized library set that corresponds to your CPU. For example, in the \ia32\bin directory, the ippiv8-x.x.dll library file contains version ‘x.x’ of the optimized image processing libraries for Intel® Core™ 2 Duo processors; ‘ippi’ refers to the image processing library, ‘v8’ refers to the Core 2 architecture, and ‘x.x’ refers to the library’s major version numbers.

In the general case, the “dispatcher” identifies the run-time processor only once, at library initialization time. It sets an internal table or variable that directs your calls to the internal functions that match your architecture. For example, ippsCopy_8u(), may have multiple implementations stored in the library, with each version optimized to a specific Intel® processor architecture. Thus, the p8_ippsCopy_8u() version of ippsCopy_8u() is called by dispatcher when running on an Intel Core 2 Duo processor on IA-32, because it is optimized for this processor architecture.

Note: IPP architectures generally correspond to SIMD (MMX, SSE, AES, etc.) instructions sets.

Initializing the IPP Dispatcher

The process of identifying the specific processor being used, and initialization of the dispatcher, should be performed before you make any calls into the IPP library. If you are using a dynamic link library this process is handled automatically when the dynamic link library is initialized. However, if you are using a static library you must perform this step manually. See this article on the ipp*Init*() functions for more information on how to do this.

The following table lists all the architecture codes defined by the Intel IPP library through version 6.1 of the product. Note that some of these IPP architectures have been deprecated and are no longer supported in the current version of the product. Deprecated architectures are identified in the “Notes” column of the table.

For more information regarding Intel IPP library support for the Intel® IXP4XX (IXP) and XScale processors, please see the following articles:

Intel IPP for Intel IXP Support
PXA9xx / PXA27x / XScale -- How to get Developer Support

P8/Y8 Internal Run-Time Dispatcher

Within the 32-bit p8 and equivalent 64-bit y8 architectures there is an additional "run-time" dispatching mechanism, a kind of mini-dispatcher. The Nehalem (Intel Core i7) and Westmere processor families add additional SIMD instructions beyond those defined by SSE4.1. The Nehalem processor family adds the SSE4.2 SIMD instructions and the Westmere family adds AES-NI.

Creating two additional internal versions of the IPP library for the SSE4.2 and AES-NI instructions would be very space inefficient, so they are bundled as part of the SSE4.1 library. When you call a function that includes, for example, AES-NI optimizations, an additional jump directs your call to the AES-NI version within the p8/y8 library. Because the enhancements affect the optimization of only a small number of IPP functions, this additional overhead occurs infrequently and only when your application is executing on a p8/y8 architecture processor.

Additional information regarding dispatching and how it relates to non-Intel processors can be found here. How to identify your specific processor is described here. To correlate a processor family name with an Intel CPU brand name, use the following web site: ark.intel.com.

Processor Architecture Table

The following table was copied from an Intel Compiler Pro options article describing some compiler architecture options. It contains a list of Intel processors showing which processors support which SIMD instructions. For the latest table please refer to the original article; it gets updated on a regular basis. Please note that the behavior of the Intel Compiler SIMD dispatcher described in that article does not apply to the Intel IPP library.

The Intel IPP library dispatching mechanism behaves differently than that found in the Intel Compiler products, and may also behave differently than other Intel library products.

SSE4.2
Intel® Core™ i7 Processors
Intel® Xeon® 55XX series

SSE4.1
Intel® Xeon® 74XX series
Quad-Core Intel® Xeon 54XX, 33XX series
Dual-Core Intel® Xeon 52XX, 31XX series
Intel® Core™ 2 Extreme 9XXX series
Intel® Core™ 2 Quad 9XXX series
Intel® Core™ 2 Duo 8XXX series
Intel® Core™ 2 Duo E7200

SSSE3
Quad-Core Intel® Xeon® 73XX, 53XX, 32XX series
Dual-Core Intel® Xeon® 72XX, 53XX, 51XX, 30XX series
In tel® Core™ 2 Extreme 7XXX, 6XXX series
Intel® Core™ 2 Quad 6XXX series
Intel® Core™ 2 Duo 7XXX (except E7200), 6XXX, 5XXX, 4XXX series
Intel® Core™ 2 Solo 2XXX series
Intel® Pentium® dual-core processor E2XXX, T23XX series

SSE3
Dual-Core Intel® Xeon® 70XX, 71XX, 50XX Series
Dual-Core Intel® Xeon® processor (ULV and LV) 1.66, 2.0, 2.16
Dual-Core Intel® Xeon® 2.8
Intel® Xeon® processors with SSE3 instruction set support
Intel® Core™ Duo
Intel® Core™ Solo
Intel® Pentium® dual-core processor T21XX, T20XX series
Intel® Pentium® processor Extreme Edition
Intel® Pentium® D
Intel® Pentium® 4 processors with SSE3 instruction set support

SSE2
Intel® Xeon® processors
Intel® Pentium® 4 processors
Intel® Pentium® M

IA32
Intel® Pentium® III Processor
Intel® Pentium® II Processor
Intel® Pentium® Processor

• Set up persistent queries for information that can be run on demand when time is available.
• Reduce redundant computation by better understanding what information is required.
• Prioritize queries to ensure that more time is spent on the information that is most important to the AI.

The Existing System

• Further batching up all the sub-jobs that use identical data to increase cache coherence.
• Removing the overhead of indirection for each sub-job when those jobs can be handled in batches.

• 80% of the queries run by the system in the worst-case frames are redundant. With each actor working independently to find cover, each actor often requests the same LoS calculation as another actor looking for similar cover from the same threat.
• 27% of the frames don't have enough processing to be worth parallelizing. The way an AI actor behaves in a world means it won't continuously require information, because most of the time is simply spent following a course of action.
• 8% of the frames have too much processing to do, so certain calculations must be delayed. When actors wait until the last moment to request information for decisions, you get spikes. You can spread these computations out, but doing so causes unpredictable lags in the behavior.

A Sensory Reasoning System

• It avoids redundant computation by centralizing all of the independent queries of all the actors.
• It can set up sensory jobs in anticipation of the information being required before it's even needed to reduce delays.
• It caches recent information so that there's no need to cap the number of queries made each frame, particularly when lots of queries are made at the same time!

1. In each frame, the reasoning system makes sensory queries to acquire information about the cover locations for which it's trying to determine the validity. These queries are based on the known threats-for instance, the Red actors patrolling in the world. See Figure 3.
2. The sensory system returns delayed results for the LoS queries as processed by the ray test jobs that were described in the previous article [1]. As this information becomes available, the reasoning system processes it.
3. The reasoning stores information about each cover location based on the threats. In this case, the cover validity is calculated per "faction," although it could be done individually (at the cost of more computation).
4. When the high-level AI needs new cover, it can look up the cover suitability for its faction and process the information further to pick a final cover point. The reasoning system tries to guarantee that the cover validity remains as up to date as possi-ble. See Figure 4.
5. As the AI actors hide in cover, they can ascertain the validity of any cover point simply by looking up the value in the reasoning system. In fact, this particular example is best employed using an event-driven notification rather than polling.

Parallel Implementation

// This sequential phase is run before the parallel Sensory update.
void ReasoningSystem::preUpdate()
{	
	size_t coverCount = m_CoverLocations.size();

	// Loop through the pre-allocated queries.  This is the maximum allowed
	// number of queries this frame.
	for (size_t i=0; i<m_Queries.size(); ++i)
	{
		// Pick the next location via round-robin.
		CoverLocation& cover = m_CoverLocations[m_iCurrentIndex++ % coverCount];
		
		// Setup a query for known enemies; only one used here.
		CoverLineOfSightQuery& q = m_Queries[i];
		Actor& enemy = findNearestEnemy(cover);
		m_Query.setTargetPosition(enemy.getPosition());
		m_Query.setSourcePosition(cover.getPosition());
		m_Query.setCover(cover);

		// This LoS calculation will be processed in parallel later.
		m_pSensorySystem->addQuery(q);
	}

} // preUpdate()


/** NOTE: The parallel SensorySystem::update() will be called in the meantime. **/


// This phase is run sequentially after the sensory results are available.
void ReasoningSystem::postUpdate()
{
	for (size_t i=0; i<m_Queries.size(); ++i)
	{
		CoverLocation& cover = m_Query.getCover();
		cover.setVisibility(m_Query.getVisibility());
		m_pSensorySystem->removeQuery(q);
	}

} // postUpdate()

CoverLocation* MyBehavior::selectCover()
{
	CoverLocations locations;
	findNearbyCoverLocations(locations);
	for (size_t i=0; i<locations.size(); ++i)
	{
		CoverLocation& cover = locations[i];
		if (m_pReasoningSystem->isCoverValid(cover))
		{
			return &cover;
		}
	}
	return NULL;

} // selectCover()

Results

• (a) Small and frequent spikes that cause minor delays in the queries when they are capped per frame
• (b) Sustained processing within the capped range, which does not cause any particular delays (These are ideal conditions for efficiency.)
• (c) Large spikes when actors request LoS queries at the exact same time, which must be dealt with if the frame rate is to be kept constant
• (d) An equally large lag in the results from the LoS calculations because of the capping of the queries per frame
• (e) Spikes on top of a sustained period of processing also cause multiple frames of lag-up to eight or more

Discussion

Summary

References

About the Author

Let's get to it already!

private void tweetBasicAuth(string myMessage)
{
    //this is the URL where a user sends an update
    string tweetURL = "http://twitter.com/statuses/update.xml?";

    //building out the querystring to include the message in the status field
    string tweetMsg = tweetURL + "status="+ myMessage; 
   
    HttpWebRequest tweetRequest = (HttpWebRequest)WebRequest.Create(tweetMsg);
    tweetRequest.Method = WebRequestMethods.Http.Post;

    //Set the username and password from where it is stored
    //Reminder: passwords should be accessed as little as possible
    tweetRequest.Credentials = new NetworkCredential(textBoxUsername.Text, textBoxPasswd.Text);

    tweetRequest.ContentType = "application/x-www-form-urlencoded";

    try
    {
        //If the response is normal, we close it.  
        //If it generates an exception we handle it in the catch.
        HttpWebResponse tweetResponse = (HttpWebResponse)tweetRequest.GetResponse();
        tweetResponse.Close();

    }
    catch (Exception e)
    {
        //Put your exception catching code here.
        //A bad username/password will generate a 401 response 
        //resulting in this exception being thrown.
        MessageBox.Show("Exception Generated: " + e.Message);

    }
}

Extending from Twitter to Facebook

Take it and make it yours!

About the Author