Visual C++ Team Blog

Deep Dive into NuGet Native (Part One)

Garrett Serack, MSFT — Tue, 18 Jun 2013 18:38:00 GMT

Howdy!

Today I thought I’d start explaining how NuGet supports C/C++ packages under the covers, and look into how one could (theoretically) manually construct a package without using the CoApp PowerShell tools.

As I mentioned before, C/C++ packages built for NuGet didn't require a whole lot of change in NuGet itself—primarily because if we had made the Package Manager do all the complex work that was necessary to hook up a project, we’d be still implementing it all a year from now.

Instead we chose to add a fairly simple (and often requested) feature to NuGet, the ability to import MSBuild project file fragments into the consuming project. Previously, some package creators had hacked their way into something similar by including an install.ps1 PowerShell script in the package. While this sort of thing was workable, it opens up an awful can of worms. As well, NuGet needed to support actually working on C++ project types and needed to shoe-horn in a new “framework type” that could represent native packages (which was simply called native ).

As of NuGet 2.5, when the package installs, it checks inside the /build/<framework> folder for files that are either called <pkgName>.targets or <pkgName>.props . If it finds a .props, it places an <Import> into the top of the project file. If it finds a .targets file, it places an <Import> into the bottom of the project file. This allows the package creator to have finer grained control as to when something is declared—and if it can get overridden in the consuming project or not.

At that point, NuGet’s involvement on how the package is integrated in the consuming project is pretty much complete. It’s now up to the package creator to craft the .targets and/or .props files in such a way enables the consuming project to effectively use the contents.

The Simplest Package

Assume for a moment that we wanted to create a very simple package that contained only a single header file, and didn’t have any .lib files and didn’t have any redistributable files (ie, .dll files).

Given a simple mysample.h file:


#pragma once
 
#include <stdio.h>
 
/* some simple function */
#define SimpleWriteString( str ) printf( str )

We then need to create the mysample.targets file that will ensure that we add the include directory into the consuming project.

 
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" >
  <ItemDefinitionGroup>
    <ClCompile>
      <AdditionalIncludeDirectories>$(MSBuildThisFileDirectory)..\..\lib\native\include\;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
      <PreprocessorDefinitions>HAS_MYSAMPLE;%(PreprocessorDefinitions)</PreprocessorDefinitions>
    </ClCompile>
  </ItemDefinitionGroup>
</Project>

A very simple mysample.nuspec file (the .nuspec file is the manifest file used by NuGet to tell what is in the package. You can find more about the .nuspec file format from the docs on nuget.org ).


<?xml version="1.0" encoding="utf-8"?>
<package>
  <metadata>
    <id>MySample</id>
    <version>1.2.3</version>
    <authors>Garrett Serack</authors>
    <owners>CoApp Project, Garrett Serack</owners>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>A sample library.</description>
    <releaseNotes>First Release of MySample library</releaseNotes>
    <copyright>Copyright 2013</copyright>
    <title>MySample Library</title>
    <summary>A sample library</summary>
    <tags>native, MySample</tags>
  </metadata>
  <files>
    <file src="MySample.h" target="\lib\native\include\mysample.h" />
    <file src="mysample.targets" target="\build\native\mysample.targets" />
  </files>
</package>

Once we have those, it's fairly trivial to build the package with just the NuGet command-line tool:


c:\MySample\> nuget pack
 
Attempting to build package from 'MySample.nuspec'.
Successfully created package 'C:\MySample\MySample.1.2.3.nupkg'

Of course if all libraries were this easy, we'd never needed to make a special tool to build packages for C++.

Next Time: We'll dig into how we hook up .lib files to the linker, and making sure that redistributable files are copied to the output directory.

Also : In case you missed it, you might want to check out the Channel 9 Interview on NuGet/C++.

Optimizing C++ Code : Overview

Jim Hogg — Wed, 12 Jun 2013 20:00:00 GMT

If you have arrived in the middle of this blog series, you might want instead to begin at the beginning.

This post explains the flow of data within the Visual C++ compiler – starting with our C++ source program, and ending with a corresponding binary program. This post is an easy one – dipping our toes into the shallow end of ocean.

Let's examine what happens when we compile a single-file program, stored in App.cpp, from the command-line. (If you were to launch the compilation from within Visual Studio, the diagram below would have to include higher layers of software; however, these end up emitting the very commands I'm about to describe).

So let's imagine we just typed: CL /O2 App.cpp

The CL stands from "Compile and Link". /O2 tells the compiler to optimize for speed – to generate machine code that runs as fast as possible. This command launches a process to execute the CL.EXE program – a "driver" that calls several pieces of software: when joined together, they process the text in our App.cpp and eventually generate a binary file, called App.exe. When executed, this binary will carry out the operations we specified in our original source file.

Let's take a stroll around the diagram above and explain what's going on.

CL.EXE parses our command-line, and checks that it makes sense. It then calls the C++ "front-end", located in C1XX.DLL (the "CXX" is meant to suggest "C++", but dates back to a time when "+" was not a legal character in file names). The FrontEnd is the part of the chain that understands the C++ language. It scans, parses and transforms your App.cpp into an equivalent tree, passed to the next component via 5 temporary files. The "language" represented by these 5 files is called "CIL", for "C Intermediate Language". Don't confuse this with the intermediate code, generated by managed languages such as C#, sometimes called "MSIL" but also, unfortunately, named "CIL" in the ECMA-335 standard.

Next, CL.EXE calls the "back-end", located in C2.DLL. We call the BackEnd "UTC", which stands for "Universal Tuple Compiler", although this name doesn't show up in any of the binaries included into Visual Studio. The BackEnd starts by converting the information from the FrontEnd into tuples – a binary stream of instructions. If we were to display them, they would look like a kind of high-level assembly language. It's high-level in the senses that:

Operations are generic. For example, a BRANCH(LE) instruction versus how it will eventually be translated, into a cmp instruction in x64 machine code
Operands are symbolic. For example, t66 denoting a temporary variable generated by the compiler, versus eax, the x64 register that will hold its value at runtime

Because we asked the compiler to optimize for speed, via the /O2 switch, the Optimize part of the BackEnd analyses the tuples and transforms them into a form that will execute faster but that is semantically equivalent – that yields the same results as would the original tuples. After this step, the tuples are passed to the CodeGen part of the BackEnd, which decides the final binary code to emit.

The CodeGen module emits App.obj as a file on disk. Finally, the Linker consumes that file, resolves any references to libraries, and produces the final App.exe binary.

In the diagram, black arrows show flow of data – text or binary. Red arrows show flow of control.

(We shall return to this diagram later in the series, when we hit the topic of Whole Program Optimization, specified to the compiler with the /GL switch, and to the Linker with the /LTCG switch. We will see the same set of boxes, but connected in different ways)

In summary:

The FrontEnd understands C++ source code. Other parts of the chain – BackEnd and Linker – are (mostly) isolated from the details of the original source language. They work upon the tuples, mentioned above, that form a kind of high-level, binary assembly language. The original source program might have been any imperative language, such as FORTRAN or Pascal. The BackEnd really doesn't care. Well, not much.

The Optimize part of the BackEnd transforms tuples into more efficient forms that will run faster. Such transformations, we call optimizations. (We should really call them "improvements", because there may be other improvements that produce even faster-running code – we just aim to get close to that ideal. However, someone coined the term "optimization" a few decades ago, and we're stuck with it) There are dozens of such optimizations, with names like "constant folding", "common sub-expression elimination", "hoisting", "invariant code motion", "dead code elimination", "function inlining", "auto vectorization", etc. For the most part, these optimizations are independent of the eventual processor on which the program will execute – they are "machine-independent" optimizations.

The CodeGen part of the Backend decides how to lay out the runtime stack (used to implement function "activation frames"); how to make best use of the available machine registers; adds details that implement function calling conventions; and transforms the code to make it run even faster, using its detailed knowledge of the target machine. (As one tiny example, if you ever look at assembly code – for example, using the Disassembly window in Visual Studio (Alt+8) whilst debugging code – you may notice instructions like xor eax, eax used to set EAX to zero, in preference to the more obvious move eax,0. Why? Because the XOR form is smaller (2 bytes instead of 5) and executes faster. We might well call this a "micro-optimization", and wonder whether it's worth the bother. Recall the proverb: "Look after the pennies and the pounds will look after themselves"). In contrast to the Optimize part, CodeGen is aware of the processor architecture on which the code is going to run. In some cases, it will even change the order in which machine instructions are laid out – a process called "scheduling" – based upon its understanding of the target processor. Oh, I'd better explain that a bit more: CodeGen knows whether it is targeting x86 or x64 or ARM-32; but it's rare that is can know the specific micro-architecture the code will run on - Nehalem versus Sandy Bridge, for example. (see the /favor:ATOM switch for a case where it knows more detail)

This blog will focus on the Optimize part of the compiler, with scant mention of the other components that make up the chain – FrontEnd, CodeGen or Linker.

This post has introduced lots of jargon. I'm not intending that you make total sense of it all at this point: this post is an overview, sprinkled with ideas that hopefully pique your interest, and ensure you'll come back next time, where I will start to explain all of that jargon.

Next time, we will look at perhaps the simplest optimization and how it works – the one called "constant folding".

C++ REST SDK 1.0.0 is now available

Sana Mithani — Tue, 04 Jun 2013 18:11:00 GMT

Since our last release, the C++ REST SDK team has been working on improving the overall quality of the SDK to transition out of the beta phase. We are excited to announce that the C++ REST SDK has reached release quality and that v1.0.0 is now available for download! With the recent NuGet support for C++ projects, we’ve also decided to also release the C++ REST SDK as a NuGet package. You can now download the SDK directly into Visual Studio through the NuGet package manager. This release stabilizes several APIs and fixes multiple customer-reported issues.

Please visit us on CodePlex to learn more about the C++ REST SDK, explore the source code, and download the latest release.

Thank you for your continued support and encouragement. We would love to hear your feedback and feature requests for our upcoming releases. Please take a few minutes to fill out this survey and share your thoughts. We will share the results on CodePlex next week.

Optimizing C++ Code

Jim Hogg — Wed, 29 May 2013 20:00:00 GMT

Introduction

Hi, my name is Jim Hogg and I am a Program Manager, working in the Visual C++ compiler team in Microsoft, based on the main campus here in Redmond. More specifically, I work in the part of the compiler that optimizes your code, to make it run faster, or to make it smaller, or a mixture of the two.

In this series of blog posts, I will explain some of the optimizations that make your code run faster. I'll include examples, with measurements of how much gain various optimizations might deliver. I'll then describe some of the more recent optimizations that the team has added, transforming your code in amazing, non-obvious ways.

Who is this blog aimed at? Anyone that is interested in how compilers work. Anyone that wonders how a compiler can possibly make the code you wrote run faster than "what the original C++ code says". And, on the opposite side, some of the patterns that prevent or inhibit optimization: armed with this knowledge, you might tweak your source code to allow the optimizer more freedom, and make your program run faster.

What are the pre-requisites to follow along with this blog? Some knowledge of programming in C or C++. (Most of the examples I will use can be understood in C. Only towards the end will I examine optimizations that are specific to C++ code – such as "de-virtualization"). Ideally, you should be able to read 64-bit assembler code: that way, you can really see the transformations the optimizations make. But this is not a hard requirement – I'll aim to provide insights without digging all the way down to the binary machine code that the compiler generates.

I will create a Table-of-Contents here for all of the blog posts in this series, updating as I publish each post.

Introduction (this post)
Overview – the process of compiling C++ code
Constant-Folding
Dead Code Elimination
. . .
. . .
Function Inlining
. . .
. . .
Whole-Program Optimization (Link-Time Code Generation)
. . .

Profile Guided Optimization (PGO) – Under the Hood

Ankit Asthana — Tue, 28 May 2013 06:59:00 GMT

To introduce myself I am Ankit Asthana and I am the program manager for the backend C++ compiler. In my last few blogs I provided an introduction to what PGO is all about along with case studies which covered how Profile Guided Optimization (PGO) is used to make real world applications such as SAP NetWeaver and Windows PHP faster. In this blog I would like to talk about how PGO works under the hood and helps produce faster code. So let us take a look at how PGO helps the compiler backend in building an optimized version of an application. Once we know how PGO optimizations work, we can understand how PGO makes applications faster. So let's get started!

How does PGO help build leaner and faster native applications?

Carrying on from my first blog let us take a look at the following code snippets again:

To recall, PGO helps optimize the application by leveraging profile data collected from running performance centric user scenarios. PGO'izing an application requires three basic steps (Instrument, Train and Optimize). Instrumenting an application means building with special compiler/link flags which insert probes into the generated code. These probes then when hit during the training phase collect data providing information on which branch was taken in the whichBranchIsTaken code snippet or what is the usual value of *p in the devirtualization code snippet as an example. This data collected by probes in the training phase is dumped into a database file *.pgd which is then supplied to the compiler as an input for the optimize phase of PGO.

During the optimize phase of PGO, the data collected in the database file is used as an input for a list of optimizations (table 1, below). Although the database file is used as an input for many optimizations, inlining and layout based PGO optimizations provide majority of the performance gains so let us take a look at how the training data collected helps in better inlining and layout based decisions.


Full and Partial Inlining	Function Layout	Speed and Size decision
Basic Block Layout	Code Separation	Virtual Call Expansion
Switch Expansion	Data Separation	Loop Unrolling

Table 1: Some optimizations gaining from PGO

Inlining decisions for PGO are based upon call graph path profiling. Simply put, the basic mantra behind using call graph path profiling for inlining decisions is to understand the behavior of a function being called from a specific call path. This is important as the behavior of a function call from one-call path may be drastically different from another call path. Having information on which call path is hotter helps in better inlining decisions as the optimizer only inlines frequent call paths hence minimizing the code bloat due to inlining but still gaining performance by inlining hotter call paths. Take a look at the example given below:

Figure 1a: Sequence of calls to function 'bar' from 'goo', 'foo' and 'bat'

Example depicted in figure 1a above illustrates function calls being made to function 'bar' from function 'goo', 'foo' and 'bat'. The number on the edge denotes how many times function 'bar' is called from function 'goo', 'foo' and 'bat' respectively. So the edge from function 'goo' to function 'bar' denotes that function 'bar' was called 10 times from function 'goo' for a given PGO training session. Now call graph path profiling is all about finding out the behavior of a function call from a specific call path. So figure 1a will be further broken down into figure 1b.

                                      Figure 1b: Sequence of calls to function 'bar' from 'goo', 'foo' and 'bat'
                                                          Sequence of calls to function 'baz' from 'bar'

Analyzing figure 1b it becomes obvious that the major benefit will come from inlining function 'bar' into 'bat' given the higher frequency 'i.e. 100' of calls made from 'bat' to 'bar'. Additionally it also is somewhat obvious that the other major advantage will come from inlining 'baz' into 'bar' given the high frequency of calls made to function 'baz' from call paths 'goo-bar' and 'foo-bar'. The impact of pgo-inlining for the above scenario is shown below in figure 1c.

.
Figure 1c: Impact of PGO inlining, 'bar' is inlined into 'bat' and 'baz' is inlined into 'bar'.

Inlining decisions are made before layout, speed vs size decisions and all other optimizations. Now from my last blog, let us recall the output (figure 2) of an optimized PGO build.

'Speed vs. Size' decisions are based on post-inliner dynamic instruction count. Code segments (i.e. functions) with higher dynamic instruction count are optimized for speed whereas code segments with lower dynamic instruction counts are optimized for size. In the build output shown in figure 2 above 6 of 3619 (0.17%) profiled functions will be compiled for speed, and the rest of the functions will be compiled for size is a result of this decision making process. The speed and size decisions are followed by 'Block Layout' and 'Live and Scenario dead code separation' optimization. Basic blocks are ordered so that most frequent paths fall through (figure 3). Live and Scenario dead code separation is performed to minimize working set and improve code locality. Code (functions/blocks) which are scenario dead (i.e. not exercised in the training scenario) are placed in a special section (figure 4).

Finally, based on the post-inliner and post-code-separation, call graph profile data function layout is performed. Only functions in the live sections are laid out. Dead blocks are not included. The overall strategy behind function layout is that functions which are strongly connected (calling each other with high frequency) are put together. A call is supposed to have achieve page locality if the callee is located in the same page. Take a look at the example in figure 6 below:

Figure 6: Function layout based upon call graph and profile data

Some other optimizations that are performed based upon the training data are switch case expansion and virtual call speculation. The switch case expansion optimization uses the most common value of the switch expression that PGO collects and pulls it out of the switch construct. Take a look at how the code snippet presented at the start of this blog will be optimized using the PGO data when switch case expansion optimization is performed.

Similarly, if a virtual call, or other call through a function pointer, frequently targets a certain function, profile-guided optimization can insert a conditionally-executed direct call to the frequently-targeted function, and the direct call can be inlined.

Wrap up

Although Profile Guided Optimization (PGO) is a complex technology, this blog should provide you folks an idea on the usefulness of profile guided optimization and how PGO works under the hood to make plethora of products more performant. In my future blogs I will try to cover a best practices guide which covers common pitfalls and highlights some tips and tricks for PGO users. So stay tuned! Additionally, if you would like us to blog about some other PGO-related scenarios please let us know.

New Channel 9 video on the Visual Studio 3D Starter Kit now online

Jennifer Leaf [MSFT] — Fri, 24 May 2013 17:50:00 GMT

If you’re interested in DirectX development, head on over to Channel 9, where there’s a new video about the Visual Studio 3D Starter Kit. This time, Roberto Sonnino interviews Gokhan Sengun, who’s created the Virtual Experiment Laboratory app, which is the first known app on the Windows Store that was built using the Starter Kit - at least, that wasn’t built by a Microsoft employee. :) Gohkan shares some tips on using the Starter Kit, and also some great demos of the Visual Studio Shader Designer.

To learn more about the Visual Studio 3D Starter Kit, check out our previous introduction to the Starter Kit, the 3-part series on the Visual C++ blog and the accompanying video (part 1, part 2, part 3, Channel9 video), or just download the Starter Kit directly.

If you’re working on an app using the Starter Kit, we’d love to hear from you. Leave us a note in the comments!

Image Processing with C++ AMP and the .NET Framework

Eric Battalio — Tue, 21 May 2013 16:28:00 GMT

Image processing is a computational task that lends itself very well to GPU compute scenarios. In many cases the most commonly used algorithms are inherently massively parallel, with each pixel in the image being processed independently from the others. As a result, image processing toolkits have been early adopters of the new GPGPU programming model. Many of these mass-market toolkits, however, can be more accurately described as image manipulation packages that offer "image-in, image-out" capabilities; in other words, for each operation there is an input image and a resulting output (manipulated) image. In contrast, an image processing workflow differs from this in that the goal is usually the portrayal or extraction of analytical information which is determined after some multi-step processing workflow. These workflows are commonly employed in scientific and technical industries like medical imaging.

For the last two years, Core Optical Inc. has been building an image processing toolkit for the .NET framework called PrecisionImage.NET. Internally it centers around two separate execution branches, one targeting multicore CPUs and the other targeting GPU execution. While the CPU branch is a fully-managed CLS-compliant implementation leaning heavily on the .NET framework's excellent built-in thread pool, the GPU branch is implemented using Microsoft's brand new C++ AMP compiler.

We had two requirements when choosing the GPGPU tool we would use for that branch of our toolkit. First, the generated code needed to be vendor agnostic so that a decision to use our SDK wouldn't overly restrict our customer's choice concerning graphics hardware. The current minimum platform for C++ AMP is DirectX 11, a version that will soon be ubiquitous among modern GPUs from Intel, Nvidia and AMD. Secondly, since we focus on the Microsoft developer stack we needed something that would play nicely with the .NET framework. Obviously C++ AMP is the best bet in this regard since it's produced by Microsoft.

For a v1 product we've found C++ AMP to be both solid and easy to program to. Although Microsoft doesn't produce an official managed wrapper, accessing AMP in .NET was a straight forward matter of P/Invoking from our existing C# code base. To keep the surface area between the two to a minimum, we stuck with our managed code for the CPU fallback and condensed the various operations of the SDK into hundreds of compact AMP kernels compiled in combinations of single/double precision and 32/64-bit implementations. In almost all cases we found the simpler untiled model readily met our speedup goals. When this wasn't the case, we were able to produce a tiled version that met our performance objectives with minimum drama.

To demonstrate the performance of the GPU branch we decided to compare the speed of two operations running on a 6-core CPU (multithreaded managed code) versus the C++ AMP version running on two different GPUs from Nvidia. The first operation was chosen as an ideal case for GPU implementation and consisted of a 2D convolution using a large kernel implemented using AMP's simple untiled model. The second was chosen as for its unsuitability to GPU processing and was implemented using the tiled model. Even when including the overhead of marshalling arguments from managed to native code, and memory copying to/from the GPU, we saw huge gains (60x) in the first test case. Perhaps more surprising were the gains achieved in the second, less suitable, test case – up to 7x – an indication of the quality of the AMP compiler. Based on our experience to date, if you are a developer considering using AMP from a managed code base we can recommend it without reservation.

Currently, one aspect of C++ AMP imposes a performance limitation (acknowledged by Microsoft) for our particular use cases: redundant memory copying between CPU and GPU. This is partly imposed by hardware and partly by software. Since our SDK is designed to allow the easy assembly of processing chains, the overhead of these redundant memory copies can add up quickly. Microsoft has stated that this behavior needs improvement, and all our AMP kernels are using the array_view abstraction to take advantage of the improvement when it arrives. This will be a welcome enhancement to the AMP implementation, especially given AMD's recent announcement of their hUMA architecture initiative. With both the hardware and software pieces falling into place soon, we should see a whole new generation of image processing software with unprecedented power and flexibility.

Speed up Windows PHP Performance using Profile Guided Optimization (PGO)

Ankit Asthana — Wed, 08 May 2013 17:38:00 GMT

To introduce myself I am Ankit Asthana and I am the program manager for the backend C++ compiler. In my last two blogs I provided an introduction to what Profile Guided Optimization (PGO) is all about and a case study which illustrates how PGO is used to make SAP NetWeaver faster. In this blog I would like to present the story about how PGO is used make official Windows PHP binaries faster. Stephen Zarkos (Program Manager for Windows PHP) has been kind enough for providing the content for this blog.

After reading this blog you folks should be able to further understand and use this case study to introduce PGO for your applications. In addition to this, for experienced PHP users, this blog post should serve as an optimization opportunity to further optimize Windows PHP performance for their specific workloads. So let's get started!

As most of you probably already know PHP is a server side scripting language designed for web development but also used as a general purpose programming language. PHP is heavily used today and it powers millions of websites and webservers. In addition to this PHP is also used to power a plethora of open source content management system (CMS) such as Joomla, WordPress and Drupal.

The effort to PGO'ize the Windows PHP binaries was led by Microsoft Open Source Technology (OSTC) group. OSTC's primary goal is to work with open-source communities to help their software interoperate with or run better on Windows Server and Windows Azure. To be precise, this is not the only group at Microsoft that works with open source but amazingly these days is only one of many. A few examples of projects this group works on are PHP on Windows, Openstack with Hyper-V, CoApp (coapp.org) and the Linux Integration Services for Hyper-V and Azure.

Why Windows-PHP team used Profile Guided Optimization (PGO)?

Over the past several years, Microsoft and its partners have worked diligently with the PHP community to improve the experience PHP developers and users have on Windows Server and Windows Azure. As a result newer versions of PHP (i.e. PHP 5.4) for Windows include dramatic improvements that come from a deep collaboration between the PHP Core Maintainers and Microsoft. One factor attributing to a faster Windows PHP 5.4 and 5.5 is Profile Guided Optimization (PGO). The overall goal with this collaboration is to improve PHP on Windows and enable Windows specific capabilities in a way that provides PHP users the same (or better, if possible) capabilities that they see on other platforms.

After having tested the water with using PGO for Windows PHP 5.3, the team was finally able to incorporate PGO for Windows PHP 5.4. Performance is a primary goal for the Windows PHP team which served as the key reason behind PGO'izing the PHP binaries on Windows. PGO provided an important opportunity to optimize the performance of the PHP interpreter without changing any functional behavior.

What are the 'key steps' performed by the Windows PHP team for PGO'izing Windows PHP binaries?

Revisiting my previous blogs, there are essentially three steps required in PGO'izing an application (Instrument, Train and Optimize). Remember the 'Instrument' and 'Optimize' steps require an 'LTCG:PGINSTRUMENT' and 'LTCG:PGOPTIMIZE' build respectively (for more information please take a look at my last blog post).

The steps to PGO'ize Windows PHP binaries are essentially in-line with PGO'izing any generic application and are as follows:

Creating an Instrumented build of Windows PHP binaries (i.e. the Instrumentation Phase)

For those of you who would like to get some firsthand experience in doing this, creating an instrumented version of the Windows PHP binaries requires user to pass the additional '--enable-pgi' parameter to the PHP configure script. After running the configure script just rebuild with 'nmake snap'. For more detailed instructions on how to set this up take a look at this blog post.
Collecting Training Data (i.e. the Train Phase)

This step can be as simple as setting up PHP with IIS or Apache with your PHP application and then accessing the application via a web-browser. A good training session should exercise workflows that your users will hit most often. The Windows PHP team currently trains by having a number of PHP applications preconfigured, for both IIS and Apache (on Windows) and then exercising these applications via requesting specific pages (usually several times for the most used pages) in order to get wide coverage. As of today, the Windows PHP team trains with every snapshot and release build of PHP binaries.

Snapshot builds can happen multiple times a day (depending on the number of commits on that particular day). Every snapshot for PHP 5.4, 5.5 and the Master branch is automated where the build automation goes through the process of creating the instrumented binary, setting up IIS and Apache, running through a series of applications to produce the training data, copying those back to the PHP build directory and then finally rebuilding the optimized PHP.

The end result of the training phase is the "*.pgc" files which are essentially training data files that contain all the information required by the 'Optimize phase'. You need to copy these files back into your PHP build directory for the next phase of the build.
Building optimized Windows PHP binaries (i.e. the Optimize Phase)

A user can build an optimized version of PHP binaries following the simple steps listed below:
a. Copy the *.pgc files back to your PHP build directory
b. Run the command "nmake --clean-pgo" to clean your build directory (but not the .pgc files)
c. Re-run the configure script, but remove the "--enable-pgi" parameter and instead add the "--with-pgo" parameter
d. Run "nmake" and then "nmake snap" to build the final optimized PHP

This entire process can take several hours, depending upon the speed of your build machine. For best results (i.e higher build throughput and maximum PGO performance gains), use Visual Studio 2012 RTM.

What were the 'key challenges' faced by the Windows PHP team while PGO'izing Windows PHP binaries?

The work for PGO'izing PHP began as a proof of concept exercise. The Windows PHP team did some work several years ago to test PGO and see how they can leverage it for PHP. This exercise was useful in finding the following few key challenges which the team addressed when enabling PGO for PHP 5.4:

How to train the PHP binaries: At first it was difficult for the Windows PHP team to understand how best to train the PHP Windows binaries. In particular, 'what training scenarios to run?', 'how long to train for?' and 'what kind of applications to train with?'
Absorbing longer build times: To save man hours, every part of the 'Windows PHP PGO build process was automated. Adding PGO to the build process was a fairly easy exercise, but the main challenge here was to deal with the additional build times required. Given the Windows PHP has various builds (thread-safe, non-thread, and now x86 & x64 for PHP 5.5) to absorb the additional build times they needed to add more/faster build systems, and improve their build automation to support concurrent builds.
Additional quality assurance required: Validating the effectiveness of your PGO training scenario is essential and plays a major part in obtaining maximum performance gains. Good testing is still the key to the success of PGO in PHP. At the time PHP 5.4 was released the Windows PHP team had pretty good test automation and hence were able to identify issues where using PGO changed the behavior of PHP. These issues observed were then mitigated by the use of #pragma statements.

What are the performance gains received by the Windows PHP team by PGO'izing their binaries?

For testing PHP performance, applications such as Drupal, Mediawiki, Wordpress and Joomla are deployed on IIS and Apache webservers. These applications are then stressed using load agents and various metrics such as transactions per second (TPS) are recorded and reported. To better demonstrate the performance improvements we can see with PGO, the 'TPS' for these applications with/without PGO'ized PHP binaries is listed in the table below:

Table 1: Performance gain for applications leveraging PGO'ized Windows PHP 5.5

As you can see some of these results are pretty impressive! A detailed summary of these results which includes some of the gritty details used to generate these results can be found here.

Wrap up

Although Profile Guided Optimization (PGO) is a complex technology, I hope this blog provides you further evidence on the usefulness of PGO and does a fair job in explaining how the Windows PHP team PGO'ized the Windows PHP binaries. In my future blogs I will go over how PGO works under the hood to provide the performance gains enjoyed by a plethora of products out there.

So stay tuned! Additionally, if you would like us to blog about some other PGO-related scenarios or are just curios and have a few more questions about PGO please feel free to reach out to me. I will do my best to answer them.

NuGet for C++ and the Northwest Hackathon

Garrett Serack, MSFT — Wed, 08 May 2013 17:16:00 GMT

Howdy!

My name is Garrett Serack, I'm not actually part of the Visual C++ team--I actually work as a Senior Software Development Engineer in Microsoft's Open Source Technology Center, which is part of Windows Server. I have a distinctly different job than most here at Microsoft-I work to get Open Source software running better on Windows and Azure.

A little over a week ago, I released the beta version of the CoApp PowerShell tools that let us generate NuGet packages for C and C++ libraries.

Over the next few weeks, I'll try to explain what the heck goes on under the covers when creating packages for Visual C++, how you can exploit all of the power of Visual Studio in C/C++ packages and in the process, explore what it would take to manually create packages without the tools.

Today however, I'm here for a slightly different purpose: We're having an Open Source "Hackathon" here on campus this Friday and Saturday (May 10th and 11th), and I'm offering the opportunity for anyone interested in building C/C++ packages with NuGet to come on out, learn, code and have a good time. I'll be on hand all day and into the evening Friday and Saturday hacking away, and helping out anyone who's interested.

Also, folks from the the NuGet team itself will be around, so if you have questions for them, you know where they will be!

We're gonna have a ton of food, prizes, drinks, and a lot of fun. If you're into Open Source, and are in the area, I'd love to have you come out, hang around and write some code!

Don't forget to register!

Fix: Visual Studio 2012 Update 2 breaks Windows XP targeting with ATL and/or statically linking MFC

Eric Battalio — Tue, 07 May 2013 22:25:00 GMT

Recently, some of our customers reported a bug in Visual Studio 2012 Update 2 that breaks Windows XP targeting with C++ in some scenarios. Specifically, applications using ATL and/or statically linking with MFC will get the following error when run on Windows XP:

"The procedure entry point InitializeCriticalSectionEx could not be located in the dynamic link library kernel32.dll."

This issue has been fixed in Visual Studio 2012 Update 3 RC1. If you encounter this issue, please download and install this update.