Intel Developer Zone Blogs

Meshcentral.com - New Mesh Agent v1.67

ylian-saint-hilaire (Intel) — June 19th 2013

Two days ago I started updating the Windows x86 Mesh Agent with the latest v1.67 version. In this latest agent, the major change is the new use of the Windows Crypto API. In the past, I would use OpenSSL for everything across platforms. This new version stull uses OpenSSL, but on Windows I now make more use of Windows Crypto API to generate and store cryptographic keys. Should make machines that use the new agent more officult to spoof. In addition, added improved support for Intel Remote Wake, the mesh agent will make use of this technology when available to make the computer wakable over the Internet. Many computers have a Trusted Platform Module (TPM) and in the 64bit version of the Windows Mesh Agent, I added support for TPM. Sadly, I don't release the 64bit version of the Mesh Agent right now, but that may come later once I get everything validated. There is not much benefits to the 64bit version, except that I allow use of newer Windows API's that would break the Mesh Agent running on Windows XP and Vista. So, in total the new mesh agent has a lot more support for Intel Platform Technologies. Below I have a picture of what the Mesh Agent looks like. Not bad for a single self-updating executable. All of the code is tightly integrated so there is very little wasted size. It's almost as tight as it can be. Click on the picture for a larger view. Ylianmeshcentral.com [[{"type":"media","view_mode":"media_original","fid":"170396","attributes":{"alt":"","class":"media-image","height":"719","style":"display: block; margin-left: auto; margin-right: auto;","typeof":"foaf:Image","width":"1045"}}]]

Title: “Intel® Xeon Phi™ coprocessor Power Management Part 2b: Package C-States, The Details”

Taylor Kidd (Intel) — June 18th 2013

TERMINOLOGY NOTE: Upon reading the SDG (Intel® Xeon Phi™ Coprocessor Software Developer’s Guide), you’ll find a variety of confusing names and acronyms. Here’s my decoder ring: Package Auto C3: also referred to as Auto-C3, AutoC3, PC3, C3, Auto-PC3 and Package C3 Package Deep-C3: also referred to as PC3, DeepC3, DeeperC3, Deep PC3 and Package C3 (No, I am not repeating myself.) Package C6: Also referred to as PC6 and C6 and Package C6. BACKGROUND: WHAT THE HECK IS THE “UNCORE”? Before we dig deep into package C-states, I want to give you some background about circuitry on a modern Intel processor. A natural way of dividing up the circuitry of a processor is that composing the cores -- basically that supporting the pipeline, ALUs, registers, cache, etc -- and everything else (supporting circuitry). It turns out that “everything else” can be further divided into that support circuitry not directly related to performance (e.g. PCI Express* interfacing), and that which is (e.g. the bus connecting cores). Intel calls support circuitry that directly impacts the performance of an optimized application the “Uncore”. [[{"type":"media","view_mode":"media_original","fid":"170365","attributes":{"alt":"","class":"media-image","height":"454","typeof":"foaf:Image","width":"804"}}]] Figure 0 Circuitry types on the coprocessor Since that is out of the way, let us get back to package C-states. WHY DO WE NEED PACKAGE C-STATES? After gating the clocks of every one of the cores, what other techniques can you use to get even more power savings. Here’s a trivial and admittedly flippant example of what you could do: unplug the processor. You’d be using no power, though the disadvantages of pulling the power plug are pretty obvious. A better idea is to selectively shutdown the more global components of the processor in such a way that you can bring the processor back up to a fully functional state (i.e. C0) relatively quickly. Package C-States are just that, the progressive shutdown of additional circuitry to get even more savings. Since we have already shutdown the entire package’s circuitry associated with the cores, the remaining circuitry is necessarily common to all the cores, thus the name “package” C-states. WHAT PACKAGE IDLE STATES ARE THERE? My dear readers, there are 3 package C states: Auto-C3, Deep-C3, and (package) C6. As a reminder, all these are package C-states, meaning that all the threads/CPUs in all the cores are in a HALT state. I know what you are thinking. “If all the cores in the coprocessor are in a HALT state, how can the Power Management (PM) software (SW) run?” That’s a good question. The answer is obvious once you think on it. If the PM SW can’t run on the coprocessor, where can it run? On the host, of course. [[{"type":"media","view_mode":"media_original","fid":"170364","attributes":{"alt":"","class":"media-image","height":"494","typeof":"foaf:Image","width":"760"}}]] Figure 1 Coprocessor and host power management responsibilities and control There are two parts to controlling power management on the Intel® Xeon Phi™ coprocessor, the PM SW that runs on the coprocessor, and the PM component of the MPSS Coprocessor Driver that runs on the host. See figure 1. The coprocessor part controls transitions into and out of the various core C-states. Naturally, when it is not possible for the PM SW to run on the coprocessor, such as for package Deep-C3 and package C6, the host takes over. Package Auto-C3 is shared by both. WHAT IS SHUT DOWN IN THE PACKAGE C-STATES? I was going to rewrite this table but it is so clear, I am stealing it instead. It is Table 3-2 of the Intel® Xeon Phi™ Coprocessor Software Developer’s Guide (SDG). Package Idle State Core State Uncore State TSC/LAPIC C3WakeupTimer PCI Express* Traffic PC3 Preserved Preserved Frozen On expiration, package exits PC3 Package exits PC3 Deep C3 Preserved Preserved Frozen No effect Times out PC6 Lost Lost Reset No effect Times out And for those of you who want a little more detail: Package Auto-C3: Ring and Uncore clock gated Package Deep-C3: VccP reduced Package C6: VccP is off (I.e. Cores, Ring and Uncore are powered down) TSC and LAPIC are clocks which stop when the Uncore is shutdown. They have to be set appropriately when the package is reactivated. “PC3” is the same as the package Auto-C3 state. HOW ARE IDLE PACKAGE C-STATE TRANSITIONS DETERMINED Into Package Auto-C3: You can think of the first package state, Auto-C3, as a transition state. The coprocessor PM SW can initiate a transition into this state. The MPSS PM SW can override this request under certain conditions, such as when the host knows that the Uncore part of the coprocessor is still busy. We will also see that the package Auto-C3 state is the only package state that can be initiated by the coprocessor’s power management. Though this seems a little unfair at first, upon further thinking the reason is obvious. At the start of a transition into package Auto-C3, the coprocessor SW PM routine is running and can initiate the transition into the first package state. (To be technically accurate, the core executing the PM SW can transition quickly out of a core C-state into C0 quickly) Beneath Auto-C3, the coprocessor isn’t executing and transitions to deeper package C-states are best controlled by the host PM SW. Not only is this due to the coprocessor’s own PM SW is essentially suspended, but because the host can see what is happening in a more global sense, such as Uncore activity after all the cores are gated, and traffic across the PCI Express bus. Into Package Deep-C3: The host’s coprocessor PM SW looks at idle residency history, interrupts (such as PCI Express traffic), and the cost of waking the coprocessor up from package Deep-C3 to decide whether to transition the coprocessor from a package Auto-C3 state into a package Deep-C3 state. Into Package C6: Same as the Package Deep-C3 transition but only more so. REFERENCES For those of you with a passion for power management, check out the Intel® Xeon Phi™ Coprocessor Software Developer’s Guide. It has state diagrams and other goodies. I recommend sections 2.1.13, “Power Management”, and all of section 3.1, “Power Management (PM)” for your late night reading. NEXT: AN INTUITIVE DESCRIPTION OF POWER STATES USING STICK FIGURES AND LIGHTBULBS REFERENCES Kidd, Taylor, "Intel® Xeon Phi™ coprocessor Power Management Pt 0: Introduction and inquiring minds," Intel(r) Corporation, March 24th, 2013. http://software.intel.com/en-us/blogs/2013/03/24/intel-xeon-phi-coprocessor-power-management-pt-0-introduction-and-inquiring-minds Kidd, Taylor, "Intel® Xeon Phi™ coprocessor Power Management Part 1: P-States, Reducing power consumption without impacting performance," Intel(r) Corporation, May 15th, 2013. http://software.intel.com/en-us/blogs/2013/05/15/intel-xeon-phi-coprocessor-power-management-part-1-p-states-reducing-power Kidd, Taylor, "Intel® Xeon Phi™ coprocessor Power Management Part 2a: Core C-States, The Details," Intel(r) Corporation, June 3rd, 2013. http://software.intel.com/en-us/blogs/2013/06/03/intel-xeon-phi-coprocessor-power-management-part-2a-core-c-states-the-details

What's New in the HTML5 Development Environment (June 2013 Release)

ANDREW S. (Intel) — June 18th 2013

Intel continues to improve our free HTML5 Development Environment tools. Our goal is to help you the HTML5 app developer do more with your apps with less resources. We continue to innovate on your behalf to give you the edge. Our new features include: The App Porter tool is now integrated with the XDK, unifying the development workflow for these two tools within the HTML5 Development Environment. Tizen builds are now available as a build target within the Intel HTML5 Development Environment, adding to the number of app platforms developers can build for free using the tool set. App Game Interface, the HTML5 canvas tag graphics acceleration layer for hybrid iOS and Android mobile apps has been upgraded to include more HTML5 canvas commands. App Framework, Intel's premiere mobile JavaScript UI library has been updated. Not only does it provide a clean, attractive, and responsive user experience with a minimum of code work, but it now adapts its UI based on the device and operating system the library runs on to provide a consistent look and feel. Intel is pleased to reveal App Starter, a drag and drop online UI design tool for rapidly creating your own App Framework application. Use App Starter to design the pages of your app and detail navigation elements to traverse between them.

Enabling Push Notifications for Windows Store Apps using C#

David Medawar (Intel) — June 18th 2013

Suppose that a nurse is assisting a patient in some hospital room and that the patient’s doctor is somewhere else in the facility. The nurse gathers vitals for the patient and enters the information into the computer. The nurse would like for the doctor to get this information “on the fly” without having to pull him or her into the room to look at the computer. Solution? Push notifications! What could happen is that when the vitals are entered, the doctor receives a push notification from some cloud service, wherever he or she may be. Thus, this is an example where cloud services enhance efficiency. Pretty cool, huh? Now, the fun part. How does a developer write code to enable push notifications? Well, this process requires some work, at least for the first time setup, which I’ll cover in detail. In this blog, I will mainly focus on the setup required for push notifications. For brevity, the server backend code for the final step of actually sending push notifications to client(s) is left out and is assumed to already exist. Let’s start off with the following overview on push notifications: http://msdn.microsoft.com/en-us/library/windows/apps/hh913756.aspx. The term Windows Push Notification Services (WNS) is defined in the link. Essentially, for all of this magic to work, we have three components that must communicate - Client side: Receives notifications, receives URI channel, sends URI channel to cloud service - Cloud service: assumed to be the developer’s server backend. This will push notifications using the URI channel provided to it - WNS: set of notification APIs provided as a service from Microsoft. Sends notifications to client, receives authenticated request to push notification from cloud service Pay close attention to the section titled “Registering your app and receiving the credentials for your cloud service.” The section starts by explaining that the developer’s app must be registered with the Windows Store Dashboard. This requires getting a developer account. The following link tells you how: http://msdn.microsoft.com/en-us/library/windows/apps/hh868184.aspx. It isn’t necessary to complete all the dashboard steps to start sending push notifications. After I completed the minimum steps, here is what I am presented with after clicking the shown “edit” button below: Figure 1: Dashboard Main Page (snapshot taken from appdev.microsoft.com) Figure 1 above shows the minimum steps (marked with checks) that I needed to go through in order to complete the prerequisites for sending push notifications. For the “packages” section, Microsoft runs automatic validation on your app package. After two attempts, I managed to get validation complete after both changing my project build from debug to release along with making sure that the names defined in the project manifest file matched what was specified in the dashboard. Once the dashboard steps are completed, Microsoft provides two key pieces of information that the developer must keep secure and accessible to the cloud service: a secret string, and an SID string. When the cloud service wishes to push notifications to client(s) via WNS, the cloud service will use these two strings to authenticate with WNS. In return, WNS provides the cloud service an access token which is used for subsequent requests until it expires. The details for authenticating your app with WNS are found here: http://msdn.microsoft.com/en-us/library/windows/apps/hh465407.aspx. Now, once the developer has completed the above steps for the cloud service (developer’s server backend), the client proceeds with requesting a URI channel. Check out this link for a breakdown: http://msdn.microsoft.com/en-us/library/windows/apps/hh868221.aspx. To receive notifications, here is sample code for how the client requests a URI channel: String SERVER_URL = http://my.serverURL.info.tm:8080 … public static async void requestUriChannel() { PushNotificationChannel channel = null; try { channel = await PushNotificationChannelManager.CreatePushNotificationChannelForApplicationAsync(); sendChannelToServer(SERVER_URL, channel); //see below implementation } catch (Exception ) { // Could not create a channel. } } Figure 1: Acquiring a Channel URI (Code Based on Sample Code Provided at http://msdn.microsoft.com/en-us/library/windows/apps/hh868221.aspx )*** Once the client has received a URI channel, it sends the channel to the server (server implementation not discussed in this blog) using a HTTP POST request. Just in case, here is a good explanation regarding POST requests: http://en.wikipedia.org/wiki/POST_(HTTP). The following sample code could be an example as to how the client sends the channel URI to the cloud service: private static async void sendChannelToServer(String serverUrl, PushNotificationChannel channel) { // Create the web request. HttpWebRequest webRequest = (HttpWebRequest)HttpWebRequest.Create(serverUrl); webRequest.Method = "POST"; webRequest.ContentType = "application/x-www-form-urlencoded"; byte[] channelUriInBytes = System.Text.Encoding.UTF8.GetBytes("ChannelUri=" + channel.Uri); try { // Write the channel URI to the request stream. Stream requestStream = await webRequest.GetRequestStreamAsync(); requestStream.Write(channelUriInBytes, 0, channelUriInBytes.Length); // Get the response from the server. WebResponse response = await webRequest.GetResponseAsync(); StreamReader requestReader = new StreamReader(response.GetResponseStream()); String webResponse = requestReader.ReadToEnd(); } catch (Exception ) { // Could not send channel URI to server. } } Figure 2: Sending the Channel URI to the Cloud Service (Code Based on Sample Code Provided at http://msdn.microsoft.com/en-us/library/windows/apps/hh868221.aspx )*** Finally, at some point, the cloud service may elect to use the provided channel URI to send out a toast notification to client(s). As one would guess, the cloud service gets this done by sending an HTTP POST request (with access token provided for authentication) to WNS. This cloud server backend could be C# code, a python script, etc. and is left as exercise to the reader. I hope that this blog was helpful and detailed enough to get you started with push notifications for Windows Store apps. If there any questions/comments, please, don’t hesitate to reply. Thanks for reading! ***This sample source code is released under the Microsoft Limited Public License (MS-LPL) and is released under the Intel OBL Sample Source Code License (MS-LPL Compatible)

Go Parallel

Dmitry Vyukov — June 18th 2013

This is a first post in a series of posts about parallel programming with Go language. What is Go? You may ask. Go is a language with the cutest mascot ever: [[{"type":"media","view_mode":"media_preview","fid":"170345","attributes":{"alt":"","class":"media-image","height":"180","style":"display: block; margin-left: auto; margin-right: auto;","typeof":"foaf:Image","width":"180"}}]] As you may see, it also supports parallel programming: [[{"type":"media","view_mode":"media_large","fid":"170350","attributes":{"alt":"","class":"media-image","height":"211","style":"display: block; margin-left: auto; margin-right: auto;","typeof":"foaf:Image","width":"298"}}]] as well as concurrent programming: [[{"type":"media","view_mode":"media_original","fid":"170351","attributes":{"alt":"","class":"media-image","height":"212","style":"display: block; margin-left: auto; margin-right: auto;","typeof":"foaf:Image","width":"800"}}]] I am sure you are already excited by the language. But wait, there is more to it! I am not going to give you a tutorial about the language. The language is simple enough, so if you know a pair of other imperative languages, it should take you half an hour to write your first program. You can try Go right in your browser, and there is also an online tour of Go. There are several features that make Go especially good for parallel programming: Parallel programming with Go is simple. As simple as with Cilk or OpenMP, way simpler than with pthreads. Go primitives are simple yet complete. This means that you don't have limitations of strictly nested parallelism as with Cilk. Go is well suited for IO and concurrent processing. This means that you can easily integrate the parallel part with other parts of the system without resorting to using several languages or libraries. And in the end, Go is just a good modern language with a rich standard library. Go concurrency model is based on goroutines and channels. Goroutines are threads, except that you can not join them. Channels are typed FIFO queues for goroutine communication and synchronization. You start goroutines by prefixing a function call with ‘go’ keyword: [cpp] go myfunc(1, 2) [/cpp] or using an anonymous function: [cpp] go func(x, y int) { ... }(1, 2) [/cpp] You create channels with make function: [cpp] c := make(chan int) [/cpp] send to channels using an arrow pointing into the channel: [cpp] c <- 42 [/cpp] and receive from channels using an arrow pointing from the channel: [cpp] x = <-c [/cpp] Let’s put it all together to calculate sum and difference of two numbers in parallel: [cpp] func main() { // Generate two random numbers. x := rand.Int() y := rand.Int() // Create channels for sum and difference. sum := make(chan int) dif := make(chan int) // Start a goroutine to calculate the sum. go func() { sum <- x + y // Send the result to channel. }() // Start a goroutine to calculate the difference. go func() { dif <- x - y // Send the result to channel. }() // Receive the results from the channels and print. fmt.Printf("sum=%v dif=%v\n", <-sum, <-dif) } [/cpp] You can play with the program here. Calculating sum and difference of two integers in parallel is not very useful. Let's consider a more realistic program, it calculates Pi using parallel Monte Carlo method: [cpp] func main() { nThrow := flag.Int("n", 1e6, "number of throws") nCPU := flag.Int("cpu", 1, "number of CPUs to use") flag.Parse() runtime.GOMAXPROCS(*nCPU) // Set number of OS threads to use. parts := make(chan int) // Channel to collect partial results. // Kick off parallel tasks. for i := 0; i < *nCPU; i++ { go func(me int) { // Create local PRNG to avoid contention. r := rand.New(rand.NewSource(int64(me))) n := *nThrow / *nCPU hits := 0 // Do the throws. for i := 0; i < n; i++ { x := r.Float64() y := r.Float64() if x*x+y*y < 1 { hits++ } } parts <- hits // Send the result back. }(i) } // Aggregate partial results. hits := 0 for i := 0; i < *nCPU; i++ { hits += <-parts } pi := 4 * float64(hits) / float64(*nThrow) fmt.Printf("PI = %g\n", pi) } [/cpp] See the program in action here. Note how the Go program avoids inversion of control and callback hell. It all fits into the main function and you can read it from top to bottom. In the next blog we will consider how to implement parallel divide-and-conquer and pipeline pattern with Go. Stay tuned!

Re-imagining Apps for Ultrabook™ (Part 6): Multi-Device Design

Lauren Dankiewicz (Intel) — June 18th 2013

I'm happy to announce the sixth part of our Re-imagining Apps for Ultrabook™ video series is now available. In this episode, we'll review the new technologies in Ultrabook computers that allow us rethink what desktop application design can be. Then we'll look at how Ultrabooks applications fit in to new multi-device use cases. Today it's not just one device that defines our computing experience, it's multiple devices and how they're used together to get things done. Consider more than half of laptop owners in the United States also own a smartphone. A third of smartphone owners have a tablet and an increasing number of people -more than one in ten- have all three. In Multi-Device Design we'll look at how we can design Ultrabook™ applications to live this new cross device reality. [embed]http://software.intel.com/en-us/videos/re-imagining-apps-for-ultrabook-part-6-multi-device-design[/embed] Multi-Device Design Resources In the video I mention a number of resources that are listed below for quick access. Revolutionary User Interfaces by Horace Dediu Mobile Devices and News Consumption by Pew Research Center The New Multi-Screen World Study by Google Screen Mirroring Awareness by NPD Group Cross Device Design Patterns by Luke Wroblewski Developing for Ultrabook™ by Intel About the Series The Re-imagining Apps for Ultrabook™ video series introduces new ways of thinking about the design and development of desktop applications and offers practical design advice to help developers take advantage of new opportunities in Intel’s Ultrabook devices. Part 1: Touch Interfaces Part 2: Touch Targets Part 3: Touch Gestures Part 4: Location Detection Part 5: Device Motion About Your Host Luke Wroblewski is an internationally recognized digital product leader who has designed or contributed to software used by more than 700 million people worldwide. He was co-founder and CPO of Bagcheck (acquired by Twitter in 2011), chief design architect at Yahoo! Inc., and is the author of three popular Web design books including his most recent: Mobile First. Luke is a contracted vendor with Intel; opinions expressed are his own and do not necessarily represent Intel's position on any issue.

Gabe Newell of Valve on Game Development and Perceptual Computing

Wendy Boswell (Intel) — June 17th 2013

Recently, Valve’s Gabe Newell (steampowered.com) sat down with the Intel video team to talk about his impressions of perceptual computing, game development, and how one technology (Miracast) is set to change the gaming user experience as we know it. [embed]http://youtu.be/Apv8aJqhANM[/embed] Different screens for different folks Most people these days have several different screens in their house: laptops, desktops, tablets, television sets, etc. Newell mentions that it would be nice to take advantage of screens in all of these different places, and references Miracast as a good solution to distribute gaming opportunities and computing access: “Miracast™ is a groundbreaking solution for seamlessly displaying video between devices, without cables or a network connection. Users can do things like view pictures from a smartphone on a big screen television, share a laptop screen with the conference room projector in real-time, and watch live programs from a home cable box on a tablet.” – Wi-fi.org, “Wi-Fi Certified Miracast” “With the support of game-makers and device manufacturers, even the most complex and addicting games have the potential to become social events, whether its friends each using their own devices in one person’s living room or strangers engaging in interactive games from different parts of the world. If a game-maker knew that the user had a two-screen display — a tablet mirrored to a TV, for instance — it could customize a popular game with extra goodies, such as alternative views or detailed maps that provide a leg-up over opponents.” – Broadcom.com, “A Miracast-Enabled Future: Next-Gen “Screencasting” Brings Your Content to Life” Here’s a great demo of how this technology works: [embed]http://youtu.be/MmEMqbZD2Ls[/embed] Newell notes that Miracast has the potential to “improve value proposition and usability”. Users can participate in great gaming experiences with each other all over their home, but they can also get on the Internet, watch movies or listen to music on streaming services, and all of this in a collaborative fashion with other users. This is a great solution for people who are looking for a more integrated experience. Perceptual computing=game development future In the second half of the video, Newell talks about the possibilities of perceptual computing as related to game development. PCs and form factors have made fantastic improvements in the last few years, which makes the work of a software developer ever more challenging as they race to keep up with new technology and expected experiences. That’s where perceptual computing comes in. Perceptual computing offers great opportunities for different forms of input that create entirely new experiences in gaming. New kinds of input – like measured heart rate, perceived emotional state, contextual environmental cues, hand and eye movements, etc. – are where new gaming experiences are going. Intel has a very deep interest in perceptual computing; in fact, a large investment in this field was just recently announced at Computex. Intel announced that Intel Capital will be creating a $100 million Intel Capital Experiences and Perceptual Computing Fund over the next two to three years in order to support developments in this rapidly moving field: "Devices with human-like senses – the ability to see, hear and feel much like people do – has long been a subject of science fiction but is now within reach given recent innovations in compute power and camera technology," said Arvind Sodhani, president of Intel Capital and Intel executive vice president. "This new fund will invest in start-ups and companies enabling these experiences, helping them with the business development support, global business network and technology expertise needed to scale for worldwide use." The main objective in perceptual computing is the user experience, according to Newell. Developers want to create a compelling, engaging experience for their users, and perceptual computing can provide a funnel to do that. Newell points out that one of the most useful tools for developers out there is the Intel Perceptual Computing SDK, which coders can use to create new and exciting experiences for their users. To support this kit, Intel also made available the Creative* Interactive Gesture Camera. This innovative SDK gives developers the ability to fully integrate innovative facial and voice recognition, gesture controls, and alternative reality features into imaginative applications. It is absolutely free and can be downloaded at intel.com/software/perceptual. The future of development If you’re a developer, what do you think of Newell’s talk? Do you agree with him on where he believes game development is headed, or do you have a different opinion? Give us your thoughts in the comments section below.

Finding the right fit for your application on Intel® Xeon and Intel® Xeon Phi™ processors

CJ Newburn (Intel) — June 16th 2013

Not all applications are created equal. Some are chomping at the bit to harvest as much parallelism as a target platform can provide. Those may be good candidates for running on an Intel® Xeon Phi™ Coprocessor. Other applications are scalar (not vectorized) and sequential (not threaded). They won't even make full use of an Intel Xeon processor, much less an Intel Xeon Phi Coprocessor. Before moving to a highly-parallel platform, the developer-tuner needs to expose enough parallelism to hit the limits of the Intel Xeon platform. Once the demand for threads and vectors or memory bandwidth exceeds what an Intel Xeon processor can deliver, an Intel Xeon Phi coprocessor has the potential to provide further performance improvements. Assessing whether an application holds promise for showing compelling performance with a given platform, or currently exposes enough parallelism to make ready use of it, is a challenge that faces many developers today. An application may have potential, but that potential may not yet be fully realized. And the cability of platforms to harvest that potential may change over time, such that an application may not have a good fit for the first implementation in a processor family, but a later generation of the same family may be able to offer compelling performance for the same code. At ISC13, I'm giving a theater presentation and chalk talk seeking to address the following questions that we tend to have as application developers and tuners: When would I need an Intel Xeon Phi coprocessor vs. an Intel Xeon processor? How do I tell whether my application is a good fit for a Intel Xeon Phi Coprocessor? What should my expectations be for the speedup I can achieve? What do I need to do to make the application sign on "extreme hardware?" How do I develop a good intuition about this? Here's a link to the ISC13 theater presentation and chalk talk. Check back here for updates to that content. I've also worked with my colleage Chao Mei to prepare a lab that works through these issues. It goes step by step, with make files, reference solutions, VTune project files and even an answer key, so you can make use of it as a beginner. The link to will be here, as soon as I've had a chance for some others to try it out. I strongly believe that we need to make our developer and analysis tools more powerful, effective and intuitive if we're to help motivate developers to do the hard work of parallelizing their applications, regardless of platform. Have fun exposing and harvesting extreme parallelism! You might also check out a related "right for me" blog. I hope to see you at the theater presentation, Wed. June 19 at 1:20pm in the Intel booth at ISC, with a chalk talk to follow. CJ Newburn Performance and Feature Architect, Intel

Going Local to Become Global: The Benefits of Localizing Software

Eliana Penzner (Intel) — June 14th 2013

Most road maps for software development include a marketing plan that will expand the audience for the app, but few include a strategy for localization. Localization moves beyond simple translation, and results in an app that can be used seamlessly by a native speaker. It also expands the software’s audience by opening up markets in other locations. Though translators and developers often share a common goal, their processes can be at odds leading to a rocky localization process. We spoke with Antonio J Espinosa, chief operations officer of Transifex, to get an overview of localization from a company on the front lines of localization, and to get his suggestions on creating a smoother localization process for everyone. Getting Started with Localization Localization begins with translation. There are plenty of good translation tools out there, but many of them cannot deduce the meaning of homonyms or provide the syntax of a native speaker. "A successful localization project will result in a piece of software that is native to the location in both its language and operability,” said Espinosa. There are three approaches to localization: manual, automated and hybrid. Manual localization means an actual team of people will localize the app. This process will produce a very accurate app, but can be slow and expensive. The automated process utilizes computer software to translate but it can be imprecise and will not fully reflect the native language. A hybrid solution, such as the one Transifex offers, incorporates the best of both manual and automated localization, which can provide accurate translations in less time. Building Your Localization Strategy “Ideally businesses and developers will integrate localization into the initial planning of the software, but localization can occur at any time with planning,” said Espinosa. According to the “Getting Stared with Localization” white paper by Transifex, a comprehensive localization strategy will incorporate the following characteristics: Transparency, seamless integration, efficiency, agility, security and privacy and intuition. “A localized app should be both native to the market in which it’s introduced, and remain true to the original vision of the software itself. Developers and localization managers should provide oversight of the project. The localization system must remain nimble and react to requested changes quickly and efficiently.” Continuous Localization with Transifex Transifex is a continuous localization platform for the software industry. “It was built for developers by developers,” said Espinosa. When the founder of Tranisfex was a student in England, he wanted to localize his software, but found that the process was slow and inefficient. He then built an open source localization, which was very successful. “The localization process must be made as painless as possible,” said Espinosa. “Developers want to continue moving forward and building and updating software. Localization can feel like a step back in the development process. Transifex makes localization easier for developers by integrating with the most prevalent file formats and it adapts to the production flows for each team.” “Because the software industry has expanded to all corners of the globe, localization is a requirement,” said Espinosa. Planning for localization should happen early in the development process, but it can occur at any time. When creating a localization strategy and finding tools to manage the process, creating an app that appears native to the location and maintaining the original spirit of the app must be a priority. When done successfully, localization can expand a software’s reach and audience and lead to more sales and recognition of an app. To learn more about Transifex, visit their website.

Monitoring Intel® Transactional Synchronization Extensions with Intel® PCM

Roman Dementiev (Intel) — June 14th 2013

After applying a new technology (a new processor, a hardware accelerator, a new instruction, etc) besides measuring the immediate performance delta one requires a method to verify that this technology has been applied correctly and efficiently. Intel® Transactional Synchronization Extensions (Intel® TSX - instructions for speculative execution of critical sections protected by locks) are not an exception here. In fact the 4th generation Intel® Core™ processors (with Intel TSX) introduced special hardware monitoring capabilities to measure the success of Intel TSX execution and to provide information about speculation failures. These capabilities are documented in Intel® 64 and IA-32 Architectures Optimization Reference Manual and already supported by TSX Linux perf profiler and Intel® Performance Counter Monitor (Intel® PCM). Intel PCM is a simple open-source monitoring API and a collection of sample tools based on it (running on Windows, FreeBSD, MacOS X and arbitrary/old Linux kernels). In this blog I will show a few examples how Intel PCM TSX tool can be used. Building Intel PCM-TSX Tool On Windows, Intel PCM-TSX tool (pcm-tsx.exe) can be build using the MS Visual Studio project in the PCM-TSX_Win directory of the PCM package (please also see WINDOWS_HOWTO.rtf for instructions on obtaining a required Windows kernel driver). On all other supported operating systems running the 'make' command in the main PCM directory builds pcm-tsx.x executable. Measuring Basic Transactional Success A first step after enabling Intel TSX in the application is to measure basic transactional success. The measurement is similar to the Linux "perf stat -T": [plain] ./pcm-tsx.x ./program Intel(r) Performance Counter Monitor: Intel(r) Transactional Synchronization Extensions Monitoring Utility Copyright (c) 2013 Intel Corporation Executing "./program" command: Time elapsed: 42 ms Core | IPC | Instructions | Cycles | Transactional Cycles | Aborted Cycles | #RTM | #HLE | Cycles/Transaction 0 0.58 47 M 81 M 33 M (40.81%) 127 K ( 0.16%) 7239 0 4583 1 1.13 3278 K 2905 K 0 ( 0.00%) 0 ( 0.00%) 0 0 N/A 2 0.84 3831 K 4566 K 2659 K (58.24%) 1460 ( 0.03%) 576 0 4617 3 0.74 33 M 45 M 32 M (70.23%) 85 K ( 0.19%) 7233 0 4446 ------------------------------------------------------------------------------------------------------------------- * 0.66 88 M 134 M 68 M (50.56%) 214 K ( 0.16%) 15 K 0 4519 [/plain] The outputs reports a few metrics for each of the cores and also aggregated metrics for the whole system. The metrics are IPC (instructions per cycle), number of instructions and cycles, the number of cycles that were executed in a transaction, the number of transactional cycles that were aborted, the number of started RTM speculations, the number of started HLE speculations and the average number of transactional cycles per transaction (average transaction length). When the % transactional cycles is low the program may not spend much time in critical sections or the locks are not enabled for TSX lock elision. Also the goal of TSX tuning is normally to make % aborted cycles as small as possible, that is to make the commit rate of transactions as large as possible. One can also run pcm-tsx.x in background to your application: pcm-tsx.x <update_delay_in_seconds> Counting Abort Reasons with Intel TSX Events Processors with TSX have hardware monitoring events that can be used to build transaction abort reason distribution. The list of TSX events can be obtained by running pcm-tsx without any parameters: [plain] Usage: pcm-tsx.exe (delay | "external_program") [-C] [-e event1 ] [-e event2 ] [-e event3 ] [-e event4 ] <delay> - delay in seconds between updates. Either delay or "external program" parameters must be supplied "external_program" - start external program and print the performance metrics for the execution at the end -C - output in csv format (optional) -e eventX - monitor custom TSX event (up to 4) - optional. List of supported events: RTM_RETIRED.START Number of times an RTM execution started. RTM_RETIRED.COMMIT Number of times an RTM execution successfully committed RTM_RETIRED.ABORTED Number of times an RTM execution aborted due to any reasons (multiple categories may count as one) RTM_RETIRED.ABORTED_MISC1 Number of times an RTM execution aborted due to various memory events RTM_RETIRED.ABORTED_MISC2 Number of times an RTM execution aborted due to uncommon conditions RTM_RETIRED.ABORTED_MISC3 Number of times an RTM execution aborted due to HLE-unfriendly instructions RTM_RETIRED.ABORTED_MISC4 Number of times an RTM execution aborted due to incompatible memory type RTM_RETIRED.ABORTED_MISC5 Number of times an RTM execution aborted due to none of the previous 4 categories (e.g. interrupt) HLE_RETIRED.START Number of times an HLE execution started. HLE_RETIRED.COMMIT Number of times an HLE execution successfully committed HLE_RETIRED.ABORTED Number of times an HLE execution aborted due to any reasons (multiple categories may count as one) HLE_RETIRED.ABORTED_MISC1 Number of times an HLE execution aborted due to various memory events HLE_RETIRED.ABORTED_MISC2 Number of times an HLE execution aborted due to uncommon conditions HLE_RETIRED.ABORTED_MISC3 Number of times an HLE execution aborted due to HLE-unfriendly instructions HLE_RETIRED.ABORTED_MISC4 Number of times an HLE execution aborted due to incompatible memory type HLE_RETIRED.ABORTED_MISC5 Number of times an HLE execution aborted due to none of the previous 4 categories (e.g. interrupt) TX_MEM.ABORT_CONFLICT Number of times a transactional abort was signaled due to a data conflict on a transactionally accessed address TX_MEM.ABORT_CAPACITY_WRITE Number of times a transactional abort was signaled due to limited resources for transactional stores TX_MEM.ABORT_HLE_STORE_TO_ELIDED_LOCK Number of times a HLE transactional region aborted due to a non XRELEASE prefixed instruction writing to an elided lock in the elision buffer TX_MEM.ABORT_HLE_ELISION_BUFFER_NOT_EMPTY Number of times an HLE transactional execution aborted due to NoAllocatedElisionBuffer being nonzero. TX_MEM.ABORT_HLE_ELISION_BUFFER_MISMATCH Number of times an HLE transactional execution aborted due to XRELEASE lock not satisfying the address and value requirements in the elision buffer. TX_MEM.ABORT_HLE_ELISION_BUFFER_UNSUPPORTED_ALIGNMENT Number of times an HLE transactional execution aborted due to an unsupported read alignment from the elision buffer. TX_MEM.ABORT_HLE_ELISION_BUFFER_FULL Number of times HLE lock could not be elided due to ElisionBufferAvailable being zero. TX_EXEC.MISC1 Counts the number of times a class of instructions that may cause a transactional abort was executed. Since this is the count of execution, it may not always cause a transactional abort. TX_EXEC.MISC2 Counts the number of times a class of instructions that may cause a transactional abort was executed inside a transactional region TX_EXEC.MISC3 Counts the number of times an instruction execution caused the nest count supported to be exceeded TX_EXEC.MISC4 Counts the number of times an HLE XACQUIRE instruction was executed inside an RTM transactional region [/plain] The following example shows how to estimate the number of aborts due to conflicts, the total number of transactional buffer overflows, TSX-unfriendly instructions and others for RTM execution. [plain] pcm-tsx.x ./program -e RTM_RETIRED.ABORTED -e RTM_RETIRED.ABORTED_MISC1 -e TX_MEM.ABORT_CONFLICT -e RTM_RETIRED.ABORTED_MISC3 Intel(r) Performance Counter Monitor: Intel(r) Transactional Synchronization Extensions Monitoring Utility Executing "./program" command: Time elapsed: 9549 ms Event0: RTM_RETIRED.ABORTED Number of times an RTM execution aborted due to any reasons (multiple categories may count as one) (raw 0x4c9) Event1: RTM_RETIRED.ABORTED_MISC1 Number of times an RTM execution aborted due to various memory events (raw 0x8c9) Event2: TX_MEM.ABORT_CONFLICT Number of times a transactional abort was signalled due to a data conflict on a transactionally accessed address (raw 0x154) Event3: RTM_RETIRED.ABORTED_MISC3 Number of times an RTM execution aborted due to HLE-unfriendly instructions (raw 0x20c9) Core | Event0 | Event1 | Event2 | Event3 0 8707 K 8701 K 8810 K 0 1 0 0 0 0 2 1 0 0 0 3 8247 K 8242 K 9231 K 0 -------------------------------------------------- * 16 M 16 M 18 M 0 [/plain] The number of conflicts can be directly read as Event 2 (TX_MEM.ABORT_CONFLICT) and the number of aborts due to RTM unfriendly instructions as Event 3 (RTM_RETIRED.ABORTED_MISC3). To obtain the total number of transactional buffer overflows one computes ~= RTM_RETIRED.MISC1 - TX_MEM.ABORT_CONFLICT. Note that multiple abort signals may count as one in a different category (e.g. TX_MEM.ABORT_CONFLICT > RTM_RETIRED.ABORTED_MISC1 is possible). The other aborts are ~= RTM_RETIRED.ABORTED - RTM_RETIRED.MISC1 - RTM_RETIRED.MISC3. To look further into the reasons of the other aborts one chooses different TSX events from the list above. TSX Tuning The next step in the TSX tuning process is to find the source of aborts in the application code (the code that "kills" transactions): here one needs to use a sampling profiler with TSX PEBS support (best for synchronous aborts: TSX-unfriendly instructions, faults, etc) and/or the TSX emulator (for some synchronous aborts and asynchronous aborts which are conflicts and transactional buffer overflows). Once found look into Intel TSX enabling and optimization recommendations (Chapter 12) for methods to avoid the aborts. Best regards, Roman