Intel Software Network - Main Articles Feed

Setting H.264 encoding parameters in Intel IPP media processing samples

Thu, 09 Jul 2009 20:13:29 -0700

Intel® IPP media processing samples provide both encoding parameter files and H264EncoderParams class to allow users to set encoding parameters for H.264 encoders.

UMC::H264EncoderParams class has method "ReadParamFile". Using this function, users can read H.264 the parameters from configuration text file. Please check \audio-video-codecs\codec\h264_enc\readme.htm to understand each field of H.263 parameter files.

Users can also change UMC::H264EncoderParams class to change H.264 encoding parameters. To learn UMC::H264EncoderParams class members, please check UMC manual document (\audio-video-codecs\doc\umc-manual.pdf), Chapter 4, "Derived Classes", "UMC::H264VideoEncoder" part.

Depending on the video content, some encoding parameters(e.g number of B frames, num_ref_frames, subblock split, Cabac setting) will impact the performance and quality on targeted bit rate. Users need to balance between speed and video quality according to their application requirement.

The following are two example configuration files. One is target for encoding performance, and the other is for video qualities.

Teach Parallel! Join the Discussion.

Thu, 09 Jul 2009 18:42:14 -0700

Should we Teach Parallelism to undergraduates? Yes? Come to our online discussions to debate the how, when and where.

Title	Description	Date
Passion, Beauty, Joy, Awe and Computer Science. Dan Garcia, Lecturer SOE in the Computer Science division of the EECS department at the University of California, Berkeley.	We in academia and industry are at least a generation behind in preparing the next generation of computer scientists and engineers for parallel and many core computing. We must fundamentally reevaluate what and how we teach: data structures, algorithms, testing and more all need to be rethought in terms of parallelism. At the very least, students should take one full quarter or semester of parallelism as undergraduates. Even better, the undergraduate curriculum should be infused with parallelism inclusively. See this episode here	5/12/2009 10:00 AM 30 Minutes
Preparing Students for Ubiquitous Parallelism. Professor Daniel Ernst, University of Wisconsin, Eau Claire.	Professor Ernst has successfully introduced parallelism throughout the undergraduate curriculum at UWEC. His approach is to give students practice with the concepts behind parallel programming early and often by integrating them into existing course work. Join the discussion on this topic See this episode here	5/5/2009 10:00 AM 30 Minutes
Re-envisioning the Computer Science Curriculum. Dr. Dan Reed, Microsoft, Director of Multicore Research.	Dan Reed is Microsoft's Scalable and Multicore Computing Strategist. Join the conversation as Dan talks about how industry and academia must change to cope with the coming multiplicity of heterogeneous compute cores.	5/12/2009 10:00 AM 30 Minutes
The View from Intel Research. Dr. Tim Mattson, Intel Principal Engineer.	Dr. Tim Mattson, Intel Principal Engineer, has been an early (and vocal) proponent of thinking parallel both in industry and academia. His past work as creator of OpenMP, as well as his present research on abstractions that bridge across parallel system design, parallel programming environments, and application software give him a unique perspective on the topic of teaching parallelism. See this episode here	5/19/2009 10:00 AM 30 Minutes
Curriculum for Multi-core. Professor Matt Wolf, Research Scientist CERCS Center for Experimental Research in Computer Systems.	Multicore breaks a fundamental link in how we prepare our current and future developers – teach them to break a problem down into pieces and find a nice logical progression to solve each individual piece sequentially. A normal CS curriculum gets around to telling people about the idea of concurrent execution only as they have one foot out the door. At Georgia Tech, we've been trying to tackle this by trying to integrate bits of multi-core throughout the curriculum – introduced gently into the entry classes, and getting increasingly more focused as time goes on. This admittedly means we have to forgo teaching some things to make space in the curriculum, but so far it has been surprisingly little. See this episode here	6/2/2009 10:00 AM 30 Minutes
Common Strategies for Parallelism. Professor Wen-mei Hwu, Walter J. ("Jerry") Sanders III-Advanced Micro Devices Endowed Chair in Electrical and Computer Engineering in the Coordinated Science Laboratory of the University of Illinois at Urbana-Champaign.	We seek models that impose structure on parallel control flow and on synchronization. Current language specifications already discourage the use of data races, but do not aid the programmer in achieving this goal. A stronger guarantee is determinism, which guarantees that for a given input, the program will always produce the same output. This output is the result of an equivalent sequential execution, providing a simple semantic model. This model facilitates code development and debugging, while still exposing to the programmer a parallel performance model. Effectively, deterministic languages can ride on the advances in sequential programming, including safety, modularity, and composability. Many programs, especially a large class of transformative programs, are deterministic; however, current languages do not aid in expressing them in provably deterministic terms. We wish to explore the extent to which language support can be used to guarantee data-race-freedom, determinism, and other higher level coordination structures, in the context of modern sequential programming practices and client applications. See this episode here	6/9/2009 10:00 AM 30 Minutes
Teaching Paralleism to Students. Teaching Parallelism to faculty. Associate Professor Charley Peck, Earlham College, Richmond, IN.	As a member of the SuperComputing Conference's Education Program Steering Committee (2007-2011) he is one of a group of people developing and delivering curriculum for teaching high performance computing and computational science to undergraduate faculty and students. Charlie's student/faculty research covers how 3D Internet technology such as metaverses can be used to support science education , parallelism in the undergraduate computer science curriculum, and scaling scientific kernels to the next generation of petascale computational resources. Working with colleagues from the Education Program, Charlie is co-PI of the LittleFe project. LittleFe is a low-cost,portable, computational cluster primarily used for high performance computing and computational science education, outreach, and training. See this episode here	6/16/2009 10:00 AM 30 Minutes
HPC Centers can help support curricular change Scott Lathrop, Blue Waters Technical Program Manager for Education & TeraGrid Area Director for Education, Outreach and Training.	Scott Lathrop splits his time between being the TeraGrid Director of Education, Outreach and Training (EOT) at the University of Chicago/Argonne National Laboratory, and being the Blue Waters Technical Program Manager for Education for NCSA. Lathrop has been involved in high performance computing and communications activities since 1986. Lathrop coordinates education, outreach and training activities among the eleven Resource Providers involved in the TeraGrid project. He coordinates undergraduate and graduate education activities for the Blue Waters project. See this episode here	6/30/2009 10:00 AM 30 Minutes
Computational Sciences and Parallelism Professor Rubin Landau, Professor Emeritus of Physics, Oregon State University.	SFrom 1974-2000 Landau directed a basic research program in computational and theoretical particle physics and nuclear physics (over 80 publications) funded by the DOE and NSF. While at Oregon State University, he introduced five new undergraduate courses in Computational Physics and Science, a graduate course in Nonlinear Dynamics, and a new curriculum for graduate-level Advanced Quantum Mechanics. After gaining departmental, college, university and state approval, in 2001 Landau founded, and now directs, the B.S. Degree program in Computational Physics (CPUG). The program combines the new courses with those in the Math and CS departments to provide a multidisciplinary, research-rich approach to modern physics education. This program has received interest as a model for future physics education, and Landau regularly consults with other schools, reviews their programs, and contributes to CP development in South Africa, Colombia, Korea, Ireland and India.	6/30/2009 10:00 AM 30 Minutes
Education Outreach. Diane Baxter, Director of Education at the San Diego Supercomputer Center at UCSD.	We share a national challenge to address the lack of full participation by women and minorities in science, math, engineering, and technology graduate programs and careers. In all of our programs, we consciously and conscientiously strive to create opportunities for broadening participation in cyberinfrastructure. That takes careful listening to others' needs and creative collaboration to meet those needs.	July 21 10:00 AM 30 Minutes
Special Event. Live from New York! Are High School Whiz Kids Ready to "Think Parallel?"	Jeff Birnbaum, CTO Merrill Lynch, noted earlier this year there are few programmers in the hiring pipeline who understand parallel programming for multicore, a critical skill for the financial services sector. As many industries have clearly made the shift to multi- and many-core processing for the toughest computing challenges, education needs to follow suit, and teach parallel programming throughout computer sciences curriculum, starting at the high school level. With Mr. Birnbaum and the Brooklyn Technical High School, the Intel Academic Community has brought together 21 brilliant technical high school students in New York, to teach them the basics of parallel programming and see what they are capable of. .	July 21 10:00 AM 30 Minutes
Intel Parallel Studio as a tool for teaching Parallelism in the classroom. James Reinders, Intel Chief Software Evangelist.	Intel brings simplified, end-to-end parallelism to Microsoft Visual Studio* C/C++ developers with Intel Parallel Studio. Intel Parallel Studio eases implementation at every stage in the development cycle for designing, coding, debugging, and tuning applications. Dr. Reinders will discuss how Parallel Studio can be used by those teachong Computer and Computational Sciences.	7/28/2009 10:00 AM 30 Minutes
Parallelism in the Text: The new edition of Computer Organization and Design. David Patterson, Pardee Professor of Computer Science at the University of California at Berkeley.	Professor Patterson's book, "Computer Organization and Design" is arguably the most used text for the computer architecture course taught in every CS curricula. The new addition, with its increased focus on parallelism, as well as the content on GPUs and multithreaded multiprocessors for visual computing and other uses,will bring important changes to teaching and the introduction of parallelism. Join us for a discussion on this topic.	8/11/2009 10:00 AM 30 Minutes

Listen Live or access past episodes.

Join Paul Steinberg, Intel Academic Community Manager, and Tom Murphy, Professor of Computer Science at Contra Costa College, as they discuss this issue with experts in the academy and industry.

Our show runs live every second Tuesday at 10AM PDT. Find more here
Join us in live in the Science SIM virtual world - http://www.sciencesim.com/wiki/doku.php/gettingstarted
Visit our archive for past shows

All major manufactures of CPUs, GPUs and ASICs have moved to a many core design, yet universities and colleges are not training engineers in the parallel and concurrent disciplines needed to efficiently program on such systems. Today's computer science curriculums rarely include parallelism and when they do, many unversity and college teachers, lectures and professors are only just themselves coming up to speed on how to effectivley teach this subject.

Undergraduates need to be exposed to parallel programming techniques starting in CS1 and then need to build on the skill in every (relevant) course. This is not the case at most institutions; when they teach parallel computing at all, they often relegate it to advanced topics or elective courses. That said, there are a number of colleges and universities that have found that it is not all that difficult to incorporate it into their existing curriculum.

Your hosts:

Paul Steinberg is Academic Community Manager for the Intel Software Network.
Since joining Intel in 1999, Paul has worked as Intel Senior Technical Marketing Engineer for Java and Web Services as well as a Course Developer for Intel Software College.
Before joining Intel, Paul was project lead and writer for New Media Magazine Labs in Cambridge, Massachusetts, as well as a Solutions Developer for Progress Software.

Paul's other interests include Middle Eastern history and culture. Paul spent five years as a Research Fellow at the Harry S Truman Institute for the Advancement of Peace at the Hebrew University of Jerusalem, and six years as Visiting Scholar and Research Associate at the Center for Middle Eastern Studies at Harvard University

Professor Tom Murphy is the CS Program Chair and Director of Contra Costa College HPC Regional Education Training Center

Tom is teaching and advancing Computational Science Education. He helps lead weeklong Parallel and Distributed Programming workshops across the US through the

SC and National Computational Science Institute. He is member of the SC07-11 Education Program steeringcommittee the SC07-09 Education Program, making it a year-round effort, complete with a student programming contest. Through this process he has designed, built, and refined an inexpensive, portable computational cluster (http://LittleFe.net).
Follow Tom's Blog here.

Intel(R) Parallel Inspector Comparison with Intel(R) Thread Checker

Thu, 09 Jul 2009 16:08:18 -0700

The following table can help you decide which tool to use:

	Intel® Parallel Inspector	Intel® Thread Checker
Threading errors - Data races and Deadlocks	√	√
Does not require special build or source code	√	√
Memory errors	√
Easier to learn and reuse	√
Low overhead analysis	√
Improved scalable analysis without serializing the app	√
Windows* standalone		√
Linux* support		√
Licensing	Single User	Single User & Floating
Support	forum support premier support option	unlimited premier support & 1 year product updates

Intel Thread Checker is still the right choice for developers who need:

Analysis outside of Visual Studio (standalone version)
Floating licenses
Unlimited, secure, formal support
Ability to check Linux applications

Optimizing Software Applications for NUMA

Thu, 09 Jul 2009 14:28:18 -0700

Download Article

Download Optimizing Software Applications for NUMA [PDF 83KB]

Introduction

In this brief technical paper, we provide an overview of the NUMA shared memory architecture and describe various techniques for optimizing application memory performance within a NUMA-based system. In particular, we discuss the role of processor affinity, memory allocation using implicit operating system policies, and the use of the system API's for assigning and migrating memory pages using explicit directives.

The Basics of NUMA

NUMA, or Non-Uniform Memory Access, is a shared memory architecture that describes the placement of main memory modules with respect to processors in a multiprocessor system. Perhaps the best way to understand NUMA is to compare it with its cousin UMA, or Uniform Memory Access.

In the UMA memory architecture, all processors access shared memory through a bus (or another type of interconnect) as seen in the following diagram:

UMA gets its name from the fact that each processor must use the same shared bus to access memory, resulting in a memory access time that is uniform across all processors. Note that access time is also independent of data location within memory. That is, access time remains the same regardless of which shared memory module contains the data to be retrieved.

In the NUMA shared memory architecture, each processor has its own local memory module that it can access directly and with a distinctive performance advantage. At the same time, it can also access any memory module belonging to another processor using a shared bus (or some other type of interconnect) as seen in the diagram below:

What gives NUMA its name is that memory access time varies with the location of the data to be accessed. If data resides in local memory, access is fast. If data resides in remote memory, access is slower. The advantage of the NUMA architecture as a hierarchical shared memory scheme is its potential to improve average case access time through the introduction of fast, local memory.

Modern multiprocessor systems mix these basic architectures as seen in the following diagram:

In this complex hierarchical scheme, processors are grouped by their physical location on one or the other multi-core CPU package or "node". Processors within a node share access to memory modules as per the UMA shared memory architecture. At the same time, they may also access memory from the remote node using a shared interconnect, but with slower performance as per the NUMA shared memory architecture.

Server platforms like Intel® Xeon® using the Intel® Core i7 processors provide an example of this complex memory architecture, and for this reason our discussion will center on it henceforth. Note that such platforms employ a fast interconnect technology known as Intel® QuickPath Interconnect (QPI) to mitigate (but not eliminate) the problem of slower remote memory performance.

NUMA Advantages and Risks

The advantage of the NUMA shared memory architecture is its potential to reduce memory access time in the average case. By providing each node with its own local memory, memory accesses can take place in parallel and avoid throughput limitations and contention issues associated with a shared memory bus. In fact, memory constrained systems can theoretically improve their performance by up to the number of nodes on the system. For example, a memory-constrained dual processor system could conceivably double its performance if processors could access memory in a fully parallelized manner.

The downside of the NUMA architecture, however, is the cost associated when data is not local to the processor. In the NUMA model, the time required to retrieve data from an adjacent node within the NUMA model will be significantly higher than that required to access local memory. Furthermore, the time required to retrieve data from a non-adjacent node may be even higher, complicating memory performance and generating a hierarchy of access time possibilities. In general, as the distance from a processor increases, the cost of accessing memory increases.²

The key issue in determining whether the performance benefits of the NUMA architecture can be realized, then, is data placement. The more data can effectively be placed in memory local to the processor that needs it, the move overall access time will benefit from the architecture. Conversely, the more data fails to be local to the node that will access it, the more memory performance will suffer from the architecture. For this reason, the NUMA architecture can be said to provide the potential to reduce overall memory access times. To realize this potential, strategies are needed to ensure smart data placement. An application that effectively manages such placement is one that has been "optimized for NUMA", is "NUMA-aware", or is "NUMA-friendly".

Strategies for NUMA Optimization

Two key notions in managing performance within the NUMA shared memory architecture are processor affinity and data placement.

Processor Affinity

Affinity refers to the persistence of association with a particular resource instance, despite the availability of another instance for the same purpose. Consider the case of processor affinity. Today's complex operating systems assign application threads to processor cores using a scheduler. A scheduler will take into account system state and various policy objectives (e.g., "balance load across cores" or "aggregate threads on a few cores and put remaining cores to sleep") and match application threads to physical cores accordingly. A given thread will execute on its assigned core for some period of time and then wait as other threads are given the chance to execute. If another core becomes available, the scheduler may choose to migrate the thread to insure timely execution and meet its policy objectives.

Thread migration from one core to another poses a problem for the NUMA shared memory architecture because of the way it disassociates a thread from its local memory allocations. That is, a thread may allocate memory on node 1 at startup as it runs on a core within the node 1 package. But when the thread is later migrated to a core on node 2, the data stored earlier becomes remote and memory access time significantly increases.

Enter processor affinity. Using a system API, or by modifying an OS data structure (e.g., affinity mask), a specific core or set of cores can be associated with an application thread. The scheduler will then observe this affinity in its scheduling decisions for the lifetime of the thread. For example, a thread may be configured to run only on cores 0 through 3, all of which belong to quad core CPU package 0. Henceforth, the scheduler will choose among these alternatives without migrating the thread to another package.

Exercising processor affinity insures that memory allocations remain local to the thread(s) that need them. Several downsides, however, should be noted. In general, processor affinity may significantly harm system performance by restricting scheduler options and creating resource contention when better resources management could have otherwise been used. For example, affinity restrictions may prevent the scheduler from assigning waiting threads to unutilized cores during a particular interval. Or, low priority threads may adversely impact high priority threads due to affinity restrictions that prevent adjustments through the use of additional cores. Processor affinity restrictions may even hurt the application itself when additional execution time on another node would have more than compensated for a slower memory access time.

Such downsides imply the need to think carefully about whether processor affinity solutions are right for a particular application and shared system context. Note, finally, that processor affinity APIs offered by some systems support priority "hints" and affinity "suggestions" to the scheduler in addition to explicit directives. Such suggestions may insure optimal performance in the common case yet avoid constraining scheduling options during periods of high resource contention.

Data Placement Using Implicit Memory Allocation Policies

In the simple case, many operating systems transparently provide support for NUMA-friendly data placement. When a single-threaded application allocates memory, the processor will simply assign memory pages to the physical memory associated with the requesting thread's node (CPU package), thus insuring that it is local to the thread and access performance is optimal.

Alternatively, some operating systems will wait for the first memory access before committing on memory page assignment.2 To understand the advantage here, consider a multi-threaded application with a start-up sequence that includes memory allocations by a main control thread, followed by the creation of various worker threads, followed by a long period of application processing or service. While it may seem reasonable to place memory pages local to the requesting thread, in fact, they are more effectively placed local to the worker threads that will access the data. As such, the operating system will observe the first access request and commit page assignments based on the requester's node location.

These two policies together illustrate the importance of an application programmer being aware of the NUMA context of the program's deployment. If the page placement policy is based on first access, the programmer can exploit this fact by including a carefully designed data access sequence at startup that will generate "hints" to the operating system on optimal memory placement. If the page placement policy is based on requester location, the programmer should insure that memory allocations are made by the thread that will subsequently access the data and not by an initialization or control thread designed to act as a provisioning agent.

Multiple threads accessing the same data are best co-located on the same node so that the memory allocations of one, placed local to the node, can benefit all. This may, for example, be used by prefetching schemes designed to improve application performance by generating data requests in advance of actual need. Such threads must generate data placement that is local to the actual consumer threads for the NUMA architecture to provide its characteristic performance speedup.

It should be noted that when an operating system has fully consumed the physical memory resources of one node, memory requests coming from threads on the same node will typically be fulfilled by sub-optimal allocations made on a remote node. The implication for memory-hungry applications is to correctly size the memory needs of a particular thread and to insure local placement with respect to the accessing thread.

For situations where a large number of threads will randomly share the same pool of data from all nodes, the recommendation is to stripe the data evenly across all nodes. Doing so spreads the memory access load and avoids bottleneck access patterns on a single node within the system. ³

Data Placement Using Explicit Memory Allocation Directives

Another approach to data placement in NUMA-based systems is to make use of system APIs that explicitly configure the location of memory page allocations. An example of such APIs is the libnuma library for Linux.¹

Using the API, a programmer may be able to associate virtual memory address ranges with particular nodes, or simply to indicate the desired node within the memory allocation system call itself. With this capability, an application programmer can insure the placement of a particular data set regardless of which thread allocates it or which thread accesses it first. This may be useful, for example, in schemes where complex applications make use of a memory management thread acting on behalf of worker threads. Or, it may prove useful for applications that create many short-lived threads, each of which have predictable data requirements. Pre-fetching schemes are another area that could benefit considerably from such control.

The downside of this scheme, of course, is the management burden placed on the application in handling memory allocations and data placement. Misplaced data may cause performance that is significantly worse than default system behavior. Explicit memory management also presupposes fine-grained control over processor affinity throughout application use.

Another capability available to the application programmer through NUMA-based memory management APIs is memory page migration. In general, migration of memory pages from one node to another is an expensive operation and something to be avoided. Not only is there the cost of migrating the data, but all associated memory references must be discovered and modified to observe the new mapping. As the remapping is taking place, pages must be removed from operating system page lists and detached from normal swapping mechanisms.

Having said this, given an application that is both long-lived and memory intensive, migrating memory pages to re-establish a NUMA-friendly configuration may be worth the price.3 Consider, for example, a long lived application with various threads that have terminated and new threads that have been created but reside on another node. Data is now no longer local to the threads that need it and sub-optimal access requests now dominate. Application-specific knowledge of a thread's lifetime and data needs can be used to determine whether an explicit migration is in order.

Finally, the API may provide functions for obtaining page residency or for examining memory access behavior under the current configuration. Such tools may provide the means to implement a monitoring scheme that makes explicit migration adjustments when memory accesses within the NUMA context fall below a defined threshold.

Summary

NUMA, or Non-Uniform Memory Access, is a shared memory architecture that describes the placement of main memory modules with respect to processors in a multiprocessor system. The advantage of the NUMA architecture as a hierarchical shared memory scheme is its potential to improve average case access time through the introduction of fast, local memory. To realize the potential of NUMA systems, however, careful data placement is needed. The more data can effectively be placed in memory local to the processor that needs it, the more overall access time will benefit from the architecture.

In this brief technical paper, we have described various strategies and considerations for ensuring optimal data placement within a NUMA-based system. In particular, we have discussed the role of processor affinity, memory allocation strategies that use implicit operating system page placement policies, and the use of the system API's for assigning and migrating memory pages using explicit directives.

References

Drepper, Ulrich. "What Every Programmer Should Know About Memory". November 2007.
Intel® 64 and IA-32 Architectures Optimization Reference Manual. See Section 8.8 on "Affinities and Managing Shared Platform Resources". March 2009.
Lameter, Christoph. "Local and Remote Memory: Memory in a Linux/NUMA System". June 2006.

Author Bio

David E. Ott is a Senior Software Engineer with Intel's Software Solutions Group. He joined Intel in 2005 as a middleware systems engineer for the Technology and Manufacturing Group. Currently, David focuses on power and virtualization aspects of enterprise server platforms. David holds M.S. and Ph.D. degrees in Computer Science from the University of North Carolina at Chapel Hill.

Intel® Advanced Vector Extensions: Pixel Format Conversions

Thu, 09 Jul 2009 08:29:18 -0700

Download Article

Download Intel® Advanced Vector Extensions: Pixel Format Conversions [PDF 1.7MB]

Introduction

Intel® Advanced Vector Extensions (Intel® AVX) is a 256 bit instruction set extension to Intel® Streaming SIMD Extensions (Intel® SSE) and is designed for applications that are floating point intensive. Intel® AVX extends all the 16 XMM registers to 256-bits (YMM registers), thus essentially doubling the width of existing XMM registers which leads to improved performance and power efficiency over 128-bit SIMD instructions. Intel® AVX introduces distinct destination argument that results in fewer register copies, better register use, smaller code size, and other benefits. Intel® AVX also introduces several new instructions for blending and rearranging data in the YMM registers.

This document describes techniques to optimize pixel format conversion routines (commonly used in image processing applications) using the new Intel® AVX extensions. The two conversions demonstrated here are RGB to RGBA and RGBA to RGB. Though, R, G, B, and A components can be different data type in different applications, we only discuss single precision floating point (SP FP) components. The Intel® AVX performance is compared against the scalar version of the conversion routines on the same simulator. The Intel® AVX versions are implemented in compiler intrinsics and the code was compiled using the Intel® C Compiler that supports Intel® AVX intrinsics.

This paper will describe only the Intel® AVX implementation of the format conversions.

The RGB-to-RGBA and RGBA-to-RGB conversion algorithms make use of the Intel® AVX instructions VPERMILPS, VPERM2F128, and VBLENDPS to rearrange, and mask off data when copying from the source to the destination buffers.

RGB to RGBA

The destination and source pixel buffers are aligned to 32-byte boundaries and the conversion routines expect them to be so. The following figure depicts the arrangement of the source and destination buffers in memory, for n pixels. In this figure R0 is at a lower address than G0, and so on. In order to use aligned load and store in Intel® AVX implementation for better performance, destination and source pixel buffers should be aligned on 32-byte boundary in the memory. The Intel® AVX conversion routines make assumption that both destination and source are aligned on a 32-byte boundary.

Figure 1: Arrangement of source and destination pixels in memory

Each YMM register is 256-bit wide which allows us to load and store eight SPFP values at a time. In each iteration of the loop we load multiple source values, rearrange the data, and insert the alpha value (in this example, 1.0) and store the result to the destination address.

Since the conversion is from a 3-channel pixel to 4-channel pixel, we could have loaded twelve SP FP values from the source (four RGB pixels) and written sixteen SP FP (four RGBA pixels) values per iteration. Doing so will force us to use unaligned loads since in the next iteration we have to load pixels from an offset of twelve from the source address. There will be severe performance penalties when the unaligned accesses cross cache-line boundaries. Hence we will try to avoid unaligned loads altogether by unrolling the loop twice to load eight RGB pixels.

The algorithm is implemented in four steps, computing two destination pixels at each step. We first load eight single precision FP values starting from the source address using the _mm256_load_ps() aligned load intrinsic. The values are then shuffled to a temporary YMM register using _mm256_permutevar_ps() intrinsic with a control mask of {0,1,2,0,0,0,1,0} so that the R0, G0, B0, G1, and B1 are copied to their corresponding locations in the destination. Next R1 is broadcast using _mm256_broadcast_ss() to a temporary YMM register and the result is blended using a mask of 16 (00 01 00 00) with the output from the shuffle operation. Finally, the alpha value (1.0) is blended with the result from previous blend operation using a mask of 136 (10 00 10 00) to produce destination pixels zero and one. The result is written to the memory starting at the address of the destination using _mm256_store_ps(). The following figure illustrates this step (Step1).

Figure 2: RGB to RGBA Step1

The next eight FP values are loaded and shuffled with the eight values previously loaded using the intrinsic _mm256_permute2f128_ps() with a control mask of 33 (00 10 00 01) to produce an intermediate result. This intermediate result is shuffled using _mm256_permutevar_ps() intrinsic with a control mask of {2,3,0,0,1,2,3,0}, blended with B2 and the alpha value to get the destination pixels two and three. These steps are illustrated below (Step2).

Figure 3: RGB to RGBA Step2

The next eight FP values are loaded from an offset of sixteen from the start of the source address and shuffled with the eight FP values loaded in Step2 using an appropriate control mask. These resulting values are in turn shuffled again and blended with R5 and the alpha values, producing destination pixels four and five as illustrated below (Step3).

Figure 4: RGB to RGBA Step3

The final set of eight FP values is loaded from an offset of twenty four from the source address. These values are shuffled, blended with B6 and the alpha to produce destination pixels six and seven. These steps are illustrated below (Step4).

Figure 5: RGB to RGBA Step4

The source and destination addresses are incremented by twenty four and thirty two respectively. Steps Step1, Step2, Step3, and Step4 are repeated for the remainder of pixels.

The figure below shows the source code that demonstrates the above steps.

// 8 RGB ==> RBGA per iteration

// [G2 R2 B1 G1 , R1 B0 G0 R0]
__m256 pixel23 = _mm256_load_ps((float *)(srcPix));

// [* B1 G1 *, * B0 G0 R0], ctrl = [0,1,0,0, 0,2,1,0]
__m256 pixel01 = _mm256_permutevar_ps(pixel23, ctrl);		

// [R1 R1 R1 R1 , R1 R1 R1 R1]
__m256 pixelTemp = _mm256_broadcast_ss((float *)(srcPix+3));

// [*  B1 G1 R1 , *  B0 G0 R0], mask = 00 01 00 00
pixel01 = _mm256_blend_ps(pixel01, pixelTemp, 16);			
		
// [1. B1 G1 R1 , 1. B0 G0 R0], mask = 10 00 10 00
pixel01 = _mm256_blend_ps(pixel01, alphaOne, 136);	
_mm256_store_ps((float *)(dstPix), pixel01);  

// [R5 B4 G4 R4 , B3 G3 R3 B2]
__m256 pixel45  = _mm256_load_ps((float *)(srcPix+8));		

// [B3 G3 R3 B2 , G2 R2 B1 G1]  mask = 00 10 00 01		
pixel23 = _mm256_permute2f128_ps(pixel23, pixel45, 33);	
	
// [* B3 G3 R3, * * G2 R2], ctrl2 = [0,3,2,1, 0,0,3,2]
pixel23 = _mm256_permutevar_ps(pixel23, ctrl2);				

// [B2 B2 B2 B2 , B2 B2 B2 B2]
pixelTemp = _mm256_broadcast_ss((float *)(srcPix+8));		

// [*  B3 G3 R3 , *  B2 G2 R2], mask = 00 00 01 00
pixel23 = _mm256_blend_ps(pixel23, pixelTemp, 4);	
pixel23 = _mm256_blend_ps(pixel23, alphaOne, 136);			
_mm256_store_ps((float *)(dstPix+8), pixel23);  

// [B7 G7 R7 B6, G6 R6 B5 G5]
__m256 pixel67  = _mm256_load_ps((float *)(srcPix+16));		

// [G6 R6 B5 G5, R5 B4 G4 R4]  mask = 00 10 00 01
pixel45 = _mm256_permute2f128_ps(pixel45, pixel67, 33);		
// [*  B5 G5 *, * B4 G4 R4]
pixel45 = _mm256_permutevar_ps(pixel45, ctrl);		


// [R5 R5 R5 R5 , R5 R5 R5 R5]		
pixelTemp = _mm256_broadcast_ss((float *)(srcPix+15)); 

// [* G6 R6 R6, * B4 G4 R4]		
pixel45 = _mm256_blend_ps(pixel45, pixelTemp, 16);	
pixel45 = _mm256_blend_ps(pixel45, alphaOne, 136);			
_mm256_store_ps((float *)(dstPix+16), pixel45);  

// [* B7 G7 R7, * * G6 R6]
pixel67 = _mm256_permutevar_ps(pixel67, ctrl2);						
// [B6 B6 B6 B6 , B6 B6 B6 B6]
pixelTemp = _mm256_broadcast_ss((float *)(srcPix+20));		

// [* B7 G7 R7, * B6 G6 R6]		
pixel67 = _mm256_blend_ps(pixel67, pixelTemp, 4);			
pixel67 = _mm256_blend_ps(pixel67, alphaOne, 136);
_mm256_store_ps((float *)(dstPix+24), pixel67);

Figure 6: Intel® AVX RGB to RGBA conversion code

RGBA to RGB

Figure 7: Arrangement of source and destination pixels in memory

In each iteration of the loop we load multiple source pixels, rearrange the data, and remove the alpha value and store the result to the destination address.

Since the conversion is from a 4-channel pixel to 3-channel pixel, we need to load sixteen SP FP values from the source (four RGBA pixels) and write twelve values (four RGB pixels) per iteration. Doing so will force us to use unaligned stores since in the next iteration we have to write the result at an offset of twelve from the destination address. As explained before we will avoid all unaligned accesses by unrolling the loop twice thus writing twenty four values (six RGB pixels) at a time.

We first load sixteen SP FP values starting from the source address by invoking the _mm256_load_ps() aligned load intrinsic twice. The pixels are then rearranged using a combination of _mm256_permutevar_ps() and _mm256_permute2f128_ps() instrinsics and the intermediate results blended using an appropriate mask to produce the first set of destination FP values. The following figure illustrates this step (Step1).

Figure 8: RGBA to RGB Step1

The next set of eight FP values are loaded and using a series of _mm256_permute2f128_ps(), _mm256_permutevar_ps(), _mm256_blend_ps() and _mm256_broadcast_ss() intrinsics and blending with previously loaded values the next set of eight destination values are produced, as illustrated below (Step2).

Figure 9: RGBA to RGB Step2

In the third step (Step3), source RGBA pixels six and seven are loaded from an offset of twenty four from the source address and shuffled and blended with the previously loaded pixels four and five using a series of _mm256_permute2f128_ps(), _mm256_permutevar_ps(), and _mm256_blend_ps() intrinsics to produce the last set of destination values for the current iteration. The following figure depicts this step.

Figure 10: RGBA to RGB Step3

The source and destination addresses are incremented by thirty two and twenty four respectively. Steps Step1, Step2, and Step3 are repeated for the remainder of pixels.

The figure below shows the source code that demonstrates the above steps.

// 8 RGBA ==> 8 RGB conversion per iteration

// [A1 B1 G1 R1 , A0 B0 G0 R0]		
__m256 pixel01 = _mm256_load_ps((float *)(srcPix));				

// [*  *  B1 G1 , *  B0 G0 R0] 
__m256 pixelTmp = _mm256_permutevar_ps(pixel01, ctrl1);			

// [A3 B3 G3 R3 , A2 B2 G2 R2]
__m256 pixel23 = _mm256_load_ps((float *)(srcPix)+8); 

// [A2 B2 G2 R2 , A1 B1 G1 R1], 0x21 = 00 10 00 01
__m256 pixel12 = _mm256_permute2f128_ps(pixel01, pixel23, 0x21); 

// [G2 R2 *  *  , R1 *  *  * ]
pixel12 = _mm256_permutevar_ps(pixel12, ctrl2);					

// [G2 R2 B1 G1 , R1 B0 G0 R0], 0xC8 = 11 00 10 00
pixel01 = _mm256_blend_ps(pixelTmp, pixel12, 0xC8);
_mm256_store_ps((float *)(dstPix), pixel01); 

// [B2 B2 B2 B2 , B2 B2 B2 B2]
pixelTmp = _mm256_broadcast_ss((float *)(srcPix)+10);		

// [A5 B5 G5 R5 , A4 B4 G4 R4]
__m256 pixel45 = _mm256_load_ps((float *)(srcPix)+16);		

// [A4 B4 G4 R4 , A3 B3 G3 R3]
__m256 pixel34 = _mm256_permute2f128_ps(pixel23, pixel45, 0x21); 

// [*  B4 G4 R4 , B3 G3 R3 * ]
pixel23  = _mm256_permutevar_ps(pixel34, ctrl3);				

// [*  B4 G4 R4 , B3 G3 R3 B2],  0x1 = 00 00 00 01
pixel23  = _mm256_blend_ps(pixel23, pixelTmp, 0x1);			

// [R5 R5 R5 R5 , R5 R5 R5 R5]
pixelTmp = _mm256_broadcast_ss((float *)(srcPix)+20);			

// [R5 B4 G4 R4 , B3 G3 R3 B2], 0x80 = 10 00 00 00
pixel23  = _mm256_blend_ps(pixel23, pixelTmp, 0x80);
_mm256_store_ps((float *)(dstPix)+8, pixel23); 

// [A7 B7 G7 R7 , A6 B6 G6 R6]
__m256 pixel67 = _mm256_load_ps((float *)(srcPix)+24);					

// [A6 B6 G6 R6 , A5 B5 G5 R5]
__m256 pixel56 = _mm256_permute2f128_ps(pixel45, pixel67, 0x21); 

// [*  *  *  B6 , *  *  B5 G5]
pixel56 = _mm256_permutevar_ps(pixel56, ctrl4);					

// [B7 G7 R7 *  , G6 R6 *  * ]
pixel67 = _mm256_permutevar_ps(pixel67, ctrl5);					

// [B7 G7 R7 B6 , G6 R6 B5 G5], 0xEC = 11 10 11 00
pixel56 = _mm256_blend_ps(pixel56, pixel67, 0xEC);			
_mm256_store_ps((float *)(dstPix)+16, pixel56);

Figure 11: Intel® AVX RGBA to RGB conversion code

Results

Two implementations of the conversions - a scalar C++ implementation, and the 256-bit Intel® AVX implementation - were compared for performance on the Intel® AVX simulator. An average of three runs for each implementation is computed and compared for runtime performance. The following table shows the speedup achieved by the 256-bit version.

Conversion	Speedup vs scalar	Num. pixels
RGB to RGBA	2.73X	512
RGBA to RGB	2.14X	512

References and Resources

http://software.intel.com/en-us/avx/

Accessing an IA-32 DLL from a native Itanium® Architecture Process

Wed, 08 Jul 2009 17:25:19 -0700

By Clayne Robison, Intel Software Solutions Group, Server ISV Enabling
Porting to Itanium architecture: Avoiding dependencies on 3^rd-party IA32 libraries by using COM or other out-of-process marshalling mechanisms.

Abstract/Overview

Porting an application to the Intel Itanium architecture has many benefits, including the ability to take advantage of 64-bit address space and the architecture's explicit parallelism. However, complex applications often depend on components developed 3rd-party software sources, a dependency that puts the porting project at risk.

An analysis of these dependencies may lead to the question: "Is it possible to use an IA32 DLL from within a native Itanium architecture process?" Unfortunately, none of the operating systems currently ported to the Intel Itanium architecture allow this. However, IA32 libraries can be accessed from native Itanium architecture processes provided the IA32 libraries are loaded into a separate process space, and some marshaling mechanism is in place.

This source code demonstrates how an IA32 DLL can be used by a native Itanium architecture process using COM.

Target Audience

Enterprise application developers

Sample Category:

Operational Example Code. A complete Microsoft Visual Studio* workspace with three projects.

Implementation Language:

C++/COM

Target Hardware & Software Platforms

Hardware Systems: Itanium Architecture
Operating Systems: Windows*, NET 64.
Compilers: Microsoft Visual C++ 6.0 SP5 with Microsoft Platform SDK (November 2001)

Additional Information

The project includes instructions on how to build all binaries on a Win32 system using Microsoft Visual C++ 6.0 (SP5) with the November 2001 Platform SDK. Once all binaries are built, they can be run on a Win64 system. All binaries can also be run on a Win32 system (with the exception of the native Itanium architecture test application.)

Download Code Sample

Announcing Version 2.1 of Intel® Graphics Performance Analyzers

Wed, 08 Jul 2009 14:29:33 -0700

New features added to Intel® Graphics Performance Analyzers (Intel® GPA)

Intel is pleased to announce Intel® Graphics Performance Analyzers 2.1.

This version includes a number of significant new product features that have been added at the request of developers and publishers worldwide. These new features will allow you to more quickly and easily identify and resolve performance bottlenecks in your game or graphics application. If you have used GPA in the past or are just using it for the first time, it is recommended that you download this updated version, and start using it for your game optimization tasks.

Key GPA Links:

Summary of New features in Intel® GPA 2.1:

System Analyzer

Additional DX metrics
Single-step frames
Hot-Key Frame Capture

Frame Analyzer

New Metrics per draw call
- Vertex Shader Duration
- Pixel Shader Duration
Stacked bar chart (Vertex Shader and Pixel Shader time within GPU duration)
Configuration of bar chart for both X and Y axis
Pixel history -- Select any pixel in any render target
Per render target overdraw visualization
Buffer viewing options (render target, texture)
- Mouse wheel zoom
- View single R,G, or B channel
- View alpha channel
- Histogram + clamping
Export metrics per selected draw calls to .csv file
Disable Draw Call Experiment

Intel® Graphics Performance Analyzers, Version 2.1 Feature Overview

GPA 2.1 System Analyzer:

Additional DX Metrics (outlined in green below) - on a per-frame basis, allows for users to understand in greater detail what is happening in each frame with a complete set of DX metrics:

DX State Block Applies
DX State Block Captures
DX Render Target Changes
DX Render Target Clears
DX Color Fills
DX Surface Updates
DX Stretch Rects
DX Surface Locks
DX Volume Locks
DX Surface Lock Time
DX Volume Lock Time

Single Step Frame Capture

Pause, then single step to the exact frame you want to capture. Then press the capture button -- allows you to capture the frame you see.

Capture in-game via Hot-Key

Overview:

Simply hit the hot-key at any point during game execution on the game machine to capture a DX frame.
End-user configurable Hot-Key

Example shots captured through Hot-key

GPA 2.1 Frame Analyzer

Pixel History - allows you to select any pixel in any render target in the render target viewer and to see all draw calls that have affected that pixel in a new tab (the following screen shot shows usage of pixel selection from an overdraw visualization so that you can select "hot" pixels).

Vertex & Pixel Shader Duration metric - Vertex and pixel shader durations have been added as metrics for all devices. The screenshot below shows both metrics at the same time in the erg bar chart with vertex shader duration selected as the x-axis metric and pixel shader duration selected as the y-axis metric.

Overdraw per Render Target - The benefit of this feature is that it allows you to find areas of the scene that are really expensive from an overdraw perspective and then determine exactly which draw calls are affecting that overdraw and exactly which draw calls are causing the majority of the overdraw.

Buffer Histograms with Clamping - Buffer histograms are now a slide out option for any buffer displayed (render target or texture). This enables you to see the color channels as well as the alpha channel of any buffer and allows you to either manually clamp the highlights or shadows or auto clamp through a single button press. Clamping enables you to expand the dynamic range of the buffer as you view it so you can see portions of the buffer that might be hard to differentiate due to similar values.

Export Draw Call Subset to CSV - This is a great feature set that allows for the export at the draw call level to a CSV file that can be managed in an external application, such as Microsoft Excel*. This is a selection based feature as well, meaning that if you select one draw call you will export one draw call; or if you select the entire frame you will export the entire frame.

Exported to CSV file:

Disabled Draw Call Experiment - Allows you to experiment with various draw calls and see which ones are causing the bottleneck and how you can improve performance

Disabled Draw Calls:

The Experiments tab showing Disabled Draw calls (ergs):

Additional information:

For additional information please check out the forums and knowledge base articles on the GPA website (links are located at the top of this document). For more detailed information on all the features of GPA 2.1, please refer to the user's guides and FAQ, also linked above.

* Other names and brands may be claimed as the property of others.

Prana Studios leverages Intel® Xeon® Processor 5500 Series to get better 3D animation rendering

Wed, 08 Jul 2009 01:40:23 -0700

Introduction: Prana Studios is a leading Animation house based out of Mumbai and Los Angeles. Prana's core business is focused on four main areas: Long-form CG content, location based entertainment, game cinematics, and feature film effects. They began collaborating with Intel to resolve a technical challenge they were facing while working on an ongoing animation movie co-produced with a leading Bollywood Studio.

The Challenge: The technical challenge was to resolve the renderer performance of displacements and 3D motion blur in the Improving SitexGraphics* Air* product .

The Solution: To meet this challenge, the Prana* team explored Air* multi-core software optimizations and also evaluated the latest hardware platform powered by the Intel® Xeon® processors 5500 series with its Intel® Hyper-Threading Technology (Intel® HT Technology).

The Impact: The performance of Air* renderer was significantly higher on the Intel® Xeon® processor 5500 series-based machine as compared to the earlier generation of the hardware with the Intel® Xeon® processor 5355 series-based platform. The Air* renderer showed phenomenal performance improvement on the Intel® Xeon® processor 5500 series with average gains of 1.8X with Intel® HT Technology ON and 1.45X with Intel® HT Technology OFF as compared to the older generation Intel® Xeon® processor 5355 series-based platform.

Application Optimizations in Air* Software: During evaluation of the Intel® Xeon® processor 5500 series-based platform, the Prana* team found some scalability issues with the Air* renderer when moving from 8-thread to 16-threadexecution. This feedback was given to the SitexGraphics* what? Group?, who investigated the threading issues in the Air* renderer and released a fix that enabled 16-thread execution on the Intel® Xeon® processor 5500 series-based platform (with the Intel® HT Technology feature ON).

Deploying the Intel® Xeon® Processor 55xx Series-based Platform: Performance of Air* renderer was evaluated using workloads that constituted foliage, fur and texture scenes. Performance measurements on the Intel® Xeon® processor 5500 series-based platform were done with both Intel® HT Technology ON and OFF. It was found that the Intel® Xeon® processor 5355 series-based platform took 199, 871, and 728 seconds? while the Intel® Xeon® processor 5500 series-based platform took 137, 616, and 527 seconds with Intel® HT Technology OFF (8-thread execution) and 93, 495, and 419 seconds respectively, with Intel® HT Technology ON (16-thread execution) for rendering the 3 workloads. Therefore, optimum rendering performance was achieved on the Intel® Xeon® processor5500 series-based platform with the Intel® HT Technology ON (Ref Fig. 1).

The average performance gains on the Intel® Xeon® processor 5500 series-based platform with Intel® HT Technology OFF and ON were 1.45X and 1.8X respectively, when compared to the Intel® Xeon® processor 5355 series-based platform.

Fig. 1: Lower is better

"Good things" about Intel® Xeon® processor 5500 series: Intel® Xeon® processor-based servers provide reliable, efficient, and proven performance, designed from ground up to meet data-demanding enterprise requirements. The Intel® Xeon® processors are the ideal choice for business-critical computing.

Configuration of the machines tested:

Intel® Xeon® processor 5355 series-based Platform
• Hardware: Dual Processors Intel® Xeon® CPU 5355 Series @ 2.66GHz with 8GB FBD2 800MHz RAM
• OS: Windows* XP* Professional x64 Edition v5.2.3790 Service Pack 2 Build 3790
• Software Stack: Maya*2008 Ext2 (32-bit), MayaMan* 2.0.15 (32-bit), SitexGraphics* Air* 8.09 (32-bit)

Intel® Xeon® processor 5500 series-based Platform
• Hardware: Dual Processors Intel® Xeon® CPU 5560 Series @ 2.8GHz with 8 GB DDR3 1066MHz RAM
• OS: Windows XP Professional x64 Edition v5.2.3790 Service Pack 2 Build 3790
• Software Stack: Maya*2008 Ext2 (32-bit), MayaMan* 2.0.15 (32-bit), SitexGraphics* Air* 8.09 (32-bit)

*Other names and brands may be claimed as the property of others.

OMP abort: Initializing libguide.lib, but found libguide40.lib already

Tue, 07 Jul 2009 22:20:25 -0700

Symptom(s):
OMP abort: Initializing libguide.lib, but found libguide40.lib already initialized.

This can cause performance degradation.

Set environment variable KMP_DUPLICATE_LIB_OK=TRUE if you want your program to continue in this case.

Cause:

mkl_c.lib is one of mkl static library interface. It defines libguide.lib as a default library for resolution of threading library calls. But other Intel® software such as Intel® IPP, Intel® C++ Compiler and Intel® OpenCV defined libguid40.lib as default. So the error arises because of the duplicate initialization of libguide.lib when using static MKL library and other Intel software at the same time.

Solution:

You could use linker switch /nodefaultlib:libguide.lib and link with libguide40.lib by adding the option to the link line or in project option.

For example, link users.obj mkl_c.lib /nodefaultlib:libguide.lib libguide40.lib. This will stop mkl_c.lib from defining libguide.lib as a default library for resolution of threading library calls.

Operating System:

Windows* XP Professional, Windows* XP Home Edition, Windows* XP Tablet PC Edition, Windows* XP Media Center Edition

Intel® Visual Fortran Compiler Documentation not available from Help menu in Visual Studio 2008 Shell*

Tue, 07 Jul 2009 17:11:34 -0700

Reference Number : DPD200137640

Version : 11.1

Operating System : Windows

Problem Description : When using Intel® Visual Fortran with Microsoft Visual Studio 2008 Shell*, the compiler documentation is not available from the help menu. There is a menu option, Help > Intel Visual Fortran Compiler Pro > Intel Visual Fortran Compiler Help which opens the Microsoft Document Explorer but there is no Intel® Visual Fortran Compiler documentation displayed.

Resolution Status : This is a known issue that may be resolved in a future product release. This issue occurs when Intel Visual Fortran with Visual Studio 2008 Shell is installed on a system that has had Visual Studio 2005 Premier Partner Edition (VSPPE) previously installed. The workaround is to uninstall the Intel Compilers, Visual Studio 2008 Shell, and VSPPE and then reinstall Visual Studio 2008 Shell and the Intel Compilers.

[DISCLAIMER: The information on this web site is intended for hardware system manufacturers and software developers. Intel does not warrant the accuracy, completeness or utility of any information on this site. Intel may make changes to the information or the site at any time without notice. Intel makes no commitment to update the information at this site. ALL INFORMATION PROVIDED ON THIS WEBSITE IS PROVIDED "as is" without any express, implied, or statutory warranty of any kind including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. Independent companies manufacture the third-party products that are mentioned on this site. Intel is not responsible for the quality or performance of third-party products and makes no representation or warranty regarding such products. The third-party supplier remains solely responsible for the design, manufacture, sale and functionality of its products. Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others.]

Intel Software Network - Main Articles Feed

Setting H.264 encoding parameters in Intel IPP media processing samples

Teach Parallel! Join the Discussion.

Dan Garcia, Lecturer SOE in the Computer Science division of the EECS department at the University of California, Berkeley.

Professor Daniel Ernst, University of Wisconsin, Eau Claire.

Dr. Dan Reed, Microsoft, Director of Multicore Research.

Dr. Tim Mattson, Intel Principal Engineer.

Professor Matt Wolf, Research Scientist CERCS Center for Experimental Research in Computer Systems.

Common Strategies for Parallelism.Professor Wen-mei Hwu, Walter J. ("Jerry") Sanders III-Advanced Micro Devices Endowed Chair in Electrical and Computer Engineering in the Coordinated Science Laboratory of the University of Illinois at Urbana-Champaign.

Associate Professor Charley Peck, Earlham College, Richmond, IN.

Scott Lathrop, Blue Waters Technical Program Manager for Education & TeraGrid Area Director for Education, Outreach and Training.

Professor Rubin Landau, Professor Emeritus of Physics, Oregon State University.

Diane Baxter, Director of Education at the San Diego Supercomputer Center at UCSD.

James Reinders, Intel Chief Software Evangelist.

David Patterson, Pardee Professor of Computer Science at the University of California at Berkeley.

Intel(R) Parallel Inspector Comparison with Intel(R) Thread Checker

Optimizing Software Applications for NUMA

Download Article

Introduction

The Basics of NUMA

NUMA Advantages and Risks

Strategies for NUMA Optimization

Summary

References

Author Bio

Intel® Advanced Vector Extensions: Pixel Format Conversions

Download Article

Introduction

RGB to RGBA

RGBA to RGB

Results

References and Resources

Accessing an IA-32 DLL from a native Itanium® Architecture Process

Announcing Version 2.1 of Intel® Graphics Performance Analyzers

Prana Studios leverages Intel® Xeon® Processor 5500 Series to get better 3D animation rendering

OMP abort: Initializing libguide.lib, but found libguide40.lib already

Intel® Visual Fortran Compiler Documentation not available from Help menu in Visual Studio 2008 Shell*

Common Strategies for Parallelism.

Professor Wen-mei Hwu, Walter J. ("Jerry") Sanders III-Advanced Micro Devices Endowed Chair in Electrical and Computer Engineering in the Coordinated Science Laboratory of the University of Illinois at Urbana-Champaign.