For decades, smart programmers have used both in their applications, using C where it made sense and Fortran where that made sense. This was made easier by vendor-specific extensions to Fortran that dealt with things such as case-sensitive names and pass-by-value. Extensions such as %VAL and LOC have become so ingrained into the Fortran culture that many are astonished to find that they are non-standard.

Fortran 2003 added a whole class of features for “C interoperability” to the standard, finally enabling mixed-language programming in a reasonably portable manner. I am not aware of any other major programming language standard that has extended a hand in this manner. While many Fortran programmers have warmly embraced the new features, there’s still a lot of confusion about them, and I thought it was time to try to explain the new landscape.

This is a big topic, so I am going to split it up across several posts.

Interoper-what?

First, some definitions.  The Fortran standard talks about interoperability with a “companion C processor”. (In Fortran-speak, “processor” means something that understands and runs code written in the language. For the most part, you can substitute “compiler”, but keep in mind that the compiler operates in an OS and CPU environment that may affect its behavior.) Each Fortran implementation is free to choose which C is its “companion”.  For Intel Fortran, that is Microsoft Visual C++ on Windows, and gcc on Linux and OS X. What about Intel C++?  That is also compatible with Visual C++ on Windows and gcc on Linux and OS X, so Intel Fortran will also interoperate with Intel C++.

Note that the standard says “companion C processor”, not “companion C++ processor”.  In particular, the standard references the C99 standard, or ISO/IEC 9899:1999 to be specific. The companion processors may also build C++ code, but standard interoperability assumes C. You can use C++, but must stick to what is compatible with C when interoperating with Fortran.

What is meant by “interoperability” here? F2008 says it thusly: “Fortran provides a means of referencing procedures that are defined by means of the C programming language or procedures that can be described by C prototypes…, even if they are not actually defined by means of C. Conversely, there is a means of specifying that a procedure defined by a Fortran subprogram can be referenced by a function defined by means of C. In addition, there is a means of defining global variables that are associated with C variables whose names have external linkage.”  To this, I will add that there are also means to declare Fortran variables, data structures and enumerations that correspond to similar declarations in C.

Fortran provides four major “tools” for enabling interoperability with C.  These are:

• Restrictions on which Fortran types are considered interoperable
• The BIND(C) language-binding-spec
• The ISO_C_BINDING intrinsic module
• The VALUE attribute

I frequently see people refer to all of the interoperability tools as “ISO_C_BINDING”, but this is not correct; one can use the interoperability features without using the module.

Interoperable data types

The core concept of interoperability is that something should work the same way in Fortran as it does in C. While Fortran and C each support many of the same basic data types, not everything translates cleanly.

One difference is that Fortran has the concept of “kinds”, whereas C considers these somewhat distinct types. For example, consider the Fortran INTEGER type.  C has numerous integer types, from short int to long long int, and some specialty types such as intptr_t. These may or may not have corresponding kinds in Fortran.  For each of the C integer types which might be interoperable, ISO_C_BINDING declares a named constant (PARAMETER) giving the kind number for the implementation’s equivalent INTEGER kind.

For example, there’s the simple C int type.  This corresponds to INTEGER(C_INT), where C_INT is defined in ISO_C_BINDING.  In Intel Fortran, the value is always 4, as a C int corresponds with Fortran INTEGER(4), but some other Fortran may use different kind numbers.  Using the named constant ensures portability.

More interesting is the C intptr_t type.  This is an integer that is large enough to hold a pointer (address). In Intel Fortran, this would be INTEGER(4) when building a 32-bit application and INTEGER(8) for a 64-bit application.  Intel Fortran provides different copies of ISO_C_BINDING for various platforms so you always get the right one.

Note that Fortran has no unsigned integer types, so there are no constants for C’s unsigned types. Such types are not interoperable.

You might wonder what happens if there is a “kind” of C type not supported by the Fortran implementation. The answer is that the named constant for that type is defined as -1, so you’ll get a compile-time error if you try to use it. We’ll see a use of this shortly.

Similarly, there are constants defined for REAL, COMPLEX, LOGICAL and CHARACTER.   For REAL, the standard offers the possibility of a C long double type. This is implemented in different ways by various C compilers on various platforms supported by Intel Fortran.  In gcc on 32-bit Linux, long double is an 80-bit floating type, as supported by the X87 instruction set.  Intel Fortran doesn’t support this, so there, C_LONG_DOUBLE is -1. gcc on OS X, however, defines it as a 128-bit type that is the same as Intel Fortran’s REAL(16), so C_LONG_DOUBLE is 16 there.  And on 64-bit Linux, or on Windows, long double is treated the same as double, so C_LONG_DOUBLE is 8.  As long as you use the constants for kind values and the corresponding types in C, you’ll match.

LOGICAL and CHARACTER need special treatment when it comes to interoperability.  The Fortran standard says that LOGICAL corresponds to C’s _Bool type, and defines a single kind value C_BOOL, which is 1 in Intel Fortran. But Intel Fortran, by default, tests LOGICALs for true/false differently than C does.  Where C uses zero for false and not-zero for true, Intel Fortran defaults to treating even values as false and odd values as true. If you are going to use LOGICAL types to interoperate with C, be sure to specify the –fpscomp logicals (/fpscomp:logicals) option, which changes the interpretation to be C-like.  This is included if you use –standard-semantics (/standard-semantics) – I recommend using this option any time you use Fortran 2003 (or later) features.

Now we come to CHARACTER. C does not have character strings, at least not in the way Fortran does.  Really.  It has arrays of single characters, so this is how you must represent things in Fortran.  There is a kind value defined, C_CHAR, corresponding to the C char type. But only length 1 character variables are interoperable.  I’ll talk more about that when I come to procedure arguments, but just know that it is not as dire a situation as you might think.

Derived types can also be interoperable, and that will be discussed next time when I talk about BIND(C).

There are other restrictions on interoperable variables. Scalar variables are interoperable only if their type parameters (kind and length) are interoperable (see above), they are not a Coarray, do not have the POINTER or ALLOCATABLE attribute (this may change in the future, I’ll talk about that in another post), and if character its length is not assumed nor defined by a non-constant expression. (Wait, I thought you said only length 1 was interoperable!  Patience, grasshopper…)

Arrays are interoperable if the base type meets the scalar variable requirements above, if it is explicit shape or assumed-size, and is not zero-sized. Furthermore, assumed-size arrays are interoperable only with C arrays that have no size specified. There are some additional rules on rank, in particular, C arrays with rank greater than 1 are not interoperable because they are “arrays of arrays”.

To be continued…

The next post will be dedicated to BIND(C), in all its manifestations.  “C” you then!

In a sequential program, it is not a big problem since the calculation order is exactly specified so the result is predictable and repeatable. The situation is not so clear in parallel programming.

To make the example parallel, I used the parallel_reduce template function from Intel® Threading Building Blocks (Intel® TBB):

std::vector<float> arr( N, 1.0f/(float)N );
float sum = tbb::parallel_reduce( tbb::blocked_range( arr.begin(), arr.end() ), 0.0f,
    []( const tbb::blocked_range& r, float sum ) {
        return std::accumulate( r.begin(), r.end(), sum );
    },
    std::plus<float>() );
std::cout << sum << std::endl;

As in the examples above, the code calculates the sum of N fractions, but it uses multiple processor cores if available. As it is well known, we face a disappointing fact of different results being possible for different orders of calculations. If we run it 10 times and N=1000 we will get something like this:

0.999991
1
0.999999
0.999996
0.999998
0.999998
0.999998
1
0.999997
0.999998

It’s worth mentioning that the result differs from run to run! In spite of the fact that the developer specifies the calculations – when it is calculated in parallel the order of calculation gets out of control.

On the other hand, it is not as bad as all that. Although the OS operates on threads and fills the application with indeterminism, it is still possible to manage the order of calculations. One of the new features of Intel TBB 4.0 is the parallel_deterministic_reduce template algorithm. The algorithm has the same interface as parallel_reduce except that it does not allow you to specify a partitioner. (For parallel_reduce it is possible to pass a partitioner as the last argument.) We will discuss why this restriction exists later. But for now, let’s replace the parallel_reduce with parallel_deterministic_reduce and look at how the result changes:

std::vector<float> arr( N, 1.0f/(float)N );
float sum = tbb::parallel_deterministic_reduce( tbb::blocked_range( arr.begin(), arr.end() ), 0.0f,
    []( const tbb::blocked_range& r, float sum ) {
        return std::accumulate( r.begin(), r.end(), sum );
    },
    std::plus<float>() );
std::cout << sum << std::endl;

Again run it 10 times:

1
1
1
1
1
1
1
1
1
1

The key point here is that the result is the same from run to run.

The sources of non-determinism in parallel_reduce derive from partitioning and body splitting. Let’s consider each of these subjects:

• Partitioning. The simple_partitioner determines exactly how many and which subranges are created. It splits the iteration range until each subrange is smaller than a given grain size. Thus the behavior only depends on the range size and grain size specified by the developer. However, other types of partitioning in Intel TBB are non-deterministic: to improve performance of the algorithms, range splitting provided by these partitioners depends on run-time stealing events, which we cannot predict.

• Body splitting. For performance reasons parallel_reduce minimizes body copies: it splits the body only when consecutive subranges are processed by different threads. Thus body splitting, like “advanced” partitioning, also depends on non-deterministic task stealing.

The example shows that parallel_reduce is really inapplicable for non-associative operations like floating point arithmetic. To achieve a repeatable result from a reduction with non-associative operations parallel_deterministic_reduce has been developed. From the considerations of partitioning (given above), it follows that only the simple_partitioner can be used for parallel_deterministic_reduce; and thus, no choice of an alternative partitioner is possible. Consequently, parallel_deterministic_reduce always challenges us with choosing an appropriate grain size. And smart body splitting has been disabled for the sake of deterministic behavior, so for each subrange a new body is created. This fact complicates the challenge of grain size selection even more: on the one hand, a small grain size increases the number of body copying and overall overhead, but on the other hand, a big grain size may lead to imbalance and underutilization. Fig. 1 shows the relative performance of parallel_deterministic_reduce (simple_partitioner with various grain sizes) in comparison with parallel_reduce (auto_partitioner with default grain size). An appropriate grain size provides the same performance of parallel_deterministic_reduce as parallel_reduce, - but an incorrectly chosen grain size may lead to significant performance degradation, as shown in Fig.1 at the extremes of the grain size axis.

Fig.1. Comparison of parallel_reduce (auto_partitioner) and parallel_deterministic_reduce (simple_partitioner) on Pi calculation example.

To demonstrate the split-join order behavior of parallel_deterministic_reduce, a small example is given with range [0, 20) and grain size = 5, similar to examples for parallel_reduce in the Intel TBB Reference manual:

A tree of subranges

For each right node a new body is created by the body split constructor. The slash marks (/) in the tree show where the body split is performed. Thus, for the current example the parallel_deterministic_reduce will always produce 4 subranges and 4 different bodies associated with them. Each of these subranges may be executed in parallel. When both children of a node finish, the corresponding bodies are merged: the right child body “added” to the left child body (in our examples via the std::plus<float>() binary function).

To conclude, parallel_deterministic_reduce provides a deterministic number and deterministic sizes of subranges, and it exactly defines which pairs of subranges are merged. It’s important to note that a repeatable result obtained with parallel_deterministic_reduce may still be different from that obtained via serial execution. Moreover, the results may be different for various grain sizes, since range splitting depends on the grain size. Also, the algorithm is not targeted to improve the accuracy of calculations. The exact result of 1 in the above example of fraction sum calculation has been obtained by chance. For other examples the algorithm can cause a decrease in accuracy. Overall, parallel_deterministic_reduce is not a replacement to parallel_reduce but an alternative solution for those who need repeatability.

Let’s look at two input devices here, the toggle and the pulse (or as I would have liked to have called them, the switch and the clock). A toggle sends a signal of high or low, toggling between the two states, every time it is “toggled” or flipped. A pulse continually alternates between the high and low states at a given duration. The toggle class is implemented as follows:

class toggle {
    graph& my_graph;
    signal_t state;
    overwrite_node < signal_t > toggle_node;
 public:
    toggle(graph& g) : my_graph(g), state(undefined), toggle_node(g) {}
    toggle(const toggle& src) : my_graph(src.my_graph), state(undefined),
                                toggle_node(src.my_graph) {}
    ~toggle() {}
    // Assignment ignored
    toggle& operator=(const toggle& src) { return *this; }
    sender < signal_t > & get_out() { return toggle_node; }
    void flip() {
        if (state==high) state = low;
        else state = high;
        toggle_node.try_put(state);
    }
    void activate() {
        state = low;
        toggle_node.try_put(state);
    }
};

The toggle is represented internally by an overwrite_node, because it simply needs to keep track of one most-recent state. As an input device, it doesn’t receive output from any other items, so it has no explicit input ports, only actions (flip, activate) which can alter the output state. The output port can of course be acquired via get_out, so that the toggle can be used to send signals into a circuit.

The pulse class is a little more interesting:

class pulse {
    class clock_body {
        size_t& ms;
        int& reps;
        signal_t val;
    public:
        clock_body(size_t& _ms, int& _reps) : ms(_ms), reps(_reps), val(low) {}
        bool operator()(signal_t& out) {
            rt_sleep(ms);  // our own portable sleep function
            if (reps>0) --reps;
            if (val==low) val = high;
            else val = low;
            out = val;
            return reps>0 || reps == -1;
        }
    };
    graph& my_graph;
    size_t ms, init_ms;
    int reps, init_reps;
    source_node < signal_t > clock_node;

public:
    pulse(graph& g, size_t _ms=1000, int _reps=-1) :
        my_graph(g), ms(_ms), init_ms(_ms), reps(_reps), init_reps(_reps),
        clock_node(g, clock_body(ms, reps), false)
    {}
    pulse(const pulse& src) :
        my_graph(src.my_graph), ms(src.init_ms), init_ms(src.init_ms),
        reps(src.init_reps), init_reps(src.init_reps),
        clock_node(src.my_graph, clock_body(ms, reps), false)
    {}
    ~pulse() {}
    pulse& operator=(const pulse& src) {
        ms = src.ms; init_ms = src.init_ms;
        reps = src.reps; init_reps = src.init_reps;
        return *this;
    }
    sender < signal_t > & get_out() { return clock_node; }
    void activate() { clock_node.activate(); }
    void reset() { reps = init_reps; }
};

This class is based on the source_node. It generates a signal, alternating between low and high, every ms milliseconds. There is also an option to repeat the alternation a certain number of times and then stop, which is useful for designing simulations that use a clock but also terminate. The source_node body sleeps for a duration before flipping the signal and sending it. It doesn’t begin sending signals immediately, but requires activation. In the case of a non-infinite clock (reps is set), once the pulse object has run for the given number of repetitions, it can be reset and reactivated to use it again.

Next, we discuss two output devices, the LED and the digit. The LED is simply a tiny light that is on while the signal it is receiving is high, and off when the signal is low. For simple text display, the LED looks like this: (*) when it is on and ( ) when it is off. The digit device receives a four-bit input and displays a single hexadecimal digit. For simulations, both devices have the option of continuously displaying their state as it changes, or a silent mode, which displays only when a display method is called.

class led {
    class led_body {
        signal_t &state;
        string &label;
        bool report_changes;
        bool touched;
    public:
        led_body(signal_t &s, string &l, bool r) :
            state(s), label(l), report_changes(r), touched(false)
        {}
        continue_msg operator()(signal_t b) {
            if (!touched || b!=state) {
                state = b;
                if (state != undefined && report_changes) {
                    if (state) printf("%s: (*)\n", label.c_str());
                    else printf("%s: ( )\n", label.c_str());
                }
                touched = false;
            }
            return continue_msg();
        }
    };
    graph& my_graph;
    string label;
    signal_t state;
    bool report_changes;
    function_node < signal_t, continue_msg > led_node;
 public:
    led(graph& g, string l, bool rc=false) : my_graph(g), label(l), state(undefined),
        report_changes(rc), led_node(g, 1, led_body(state, label, report_changes))
    {}
    led(const led& src) : my_graph(src.my_graph), label(src.label), state(undefined),
        report_changes(src.report_changes),
        led_node(src.my_graph, 1, led_body(state, label, report_changes))
    {}
    ~led() {}
    led& operator=(const led& src) {
        label = src.label; state = undefined; report_changes = src.report_changes;
        return *this;
    }
    receiver < signal_t > & get_in() { return led_node; }
    void display() {
        if (state == high) printf("%s: (*)\n", label.c_str());
        else if (state == low) printf("%s: ( )\n", label.c_str());
        else printf("%s: (u)\n", label.c_str());
    }
};

The led class contains a simple function_node that has no meaningful output (we use a continue_msg to indicate this) and thus no successors. Another way to implement this would be with an overwrite_node, but we would lose the report_changes functionality. Similarly, the digit class also cannot have successors, but we reused the gate base class to implement it, since it has multiple bits of input and needs to update its state whenever one of the inputs changes.

class digit : public gate < four_input > {
    using gate < four_input > ::my_graph;
    typedef gate < four_input > ::ports_type ports_type;
    typedef gate < four_input > ::input_port_t input_port_t;
    class digit_body {
        signal_t ports[4];
        unsigned int &state;
        string &label;
        bool& report_changes;
    public:
        digit_body(unsigned int &s, string &l, bool& r) : state(s), label(l), report_changes(r) {
            for (int i=0; i < N; ++i) ports[i] = undefined;
        }
        void operator()(const input_port_t::output_type& v, ports_type& p) {
            unsigned int new_state = 0;
            if (v.indx == 0) ports[0] = std::get < 0 > (v.result);
            else if (v.indx == 1) ports[1] = std::get < 1 > (v.result);
            else if (v.indx == 2) ports[2] = std::get < 2 > (v.result);
            else if (v.indx == 3) ports[3] = std::get < 3 > (v.result);
            if (ports[0] == high) ++new_state;
            if (ports[1] == high) new_state += 2;
            if (ports[2] == high) new_state += 4;
            if (ports[3] == high) new_state += 8;
            if (state != new_state) {
                state = new_state;
                if (report_changes) {
                    printf("%s: %x\n", label.c_str(), state);
                }
            }
        }
    };
    string label;
    unsigned int state;
    bool report_changes;
 public:
    digit(graph& g, string l, bool rc=false) :
        gate < four_input > (g, digit_body(state, label, report_changes)),
        label(l), state(0), report_changes(rc) {}
    digit(const digit& src) :
        gate < four_input > (src.my_graph, digit_body(state, label, report_changes)),
        label(src.label), state(0), report_changes(src.report_changes) {}
    ~digit() {}
    digit& operator=(const digit& src) {
        label = src.label; state = 0; report_changes = src.report_changes;
        return *this;
    }
    void display() { printf("%s: %x\n", label.c_str(), state); }
};

Because digit inherits from gate, it reuses gate’s get_in methods to connect to the ports of a digit object.

Here’s an example code to test out the four-bit adder. First, create a graph:

graph g;

Then, create the four-bit adder, some toggles with which to set the inputs to the adder, and a digit and an LED to display the output:

four_bit_adder four_adder(g);
std::vector < toggle > A(4, toggle(g));
std::vector < toggle > B(4, toggle(g));
toggle CarryIN(g);
digit Sum(g, "SUM");
led CarryOUT(g, "CarryOUT");

Next, connect our toggles to the input ports of the adder, and connect the adder’s output ports to the display devices:

for (int i=0; i<4; ++i) {
    make_edge(A[i].get_out(), four_adder.get_A(i));
    make_edge(B[i].get_out(), four_adder.get_B(i));
    make_edge(four_adder.get_out(i), Sum.get_in(i));
}
make_edge(CarryIN.get_out(), four_adder.get_CI());
make_edge(four_adder.get_CO(), CarryOUT.get_in());

Almost ready to go, activate all the switches at the low state so that everything starts at zero:

for (int i=0; i<4; ++i) {
    A[i].activate();
    B[i].activate();
}
CarryIN.activate();

Now I can start flipping toggles. I’ve set digit and led to display only when requested by default, because I don’t want to see all the changes before this circuit reaches a steady state. Let’s try 8+5:

A[3].flip();
B[0].flip();
B[2].flip();

Wait for the circuit to reach a steady state:>/p>

g.wait_for_all();

Now display the results:

Sum.display();
CarryOUT.display();

And here they are:

SUM: d
CarryOUT: ( )

And with that, I’ll wrap up this blog by saying that the logic simulation example code is available as an example in Intel® TBB 4.0 Update 4, and that it has several other interesting features, like push button and constant signal input devices, NAND and NOR gates, and a D-latch circuit example. Please let us know of other interesting use cases for the or_node and any other feedback you’d be willing to give.

To begin with, I’ll first construct a one-bit full adder as in Figure 2 below:

Figure 2

The inputs are A and B, and a Carry-in bit, and the output is the sum S, and a Carry-out bit. Here is the code for the one_bit_adder class:

class one_bit_adder {
    broadcast_node < signal_t > A_port;
    broadcast_node < signal_t > B_port;
    broadcast_node < signal_t > CI_port;
    xor_gate < two_input > FirstXOR;
    xor_gate < two_input > SecondXOR;
    and_gate < two_input > FirstAND;
    and_gate < two_input > SecondAND;
    or_gate < two_input > FirstOR;
    graph& my_graph;
    void make_connections() {
        make_edge(A_port, FirstXOR.get_in(0));
        make_edge(A_port, FirstAND.get_in(0));
        make_edge(B_port, FirstXOR.get_in(1));
        make_edge(B_port, FirstAND.get_in(1));
        make_edge(CI_port, SecondXOR.get_in(1));
        make_edge(CI_port, SecondAND.get_in(1));
        make_edge(FirstXOR.get_out(), SecondXOR.get_in(0));
        make_edge(FirstXOR.get_out(), SecondAND.get_in(0));
        make_edge(SecondAND.get_out(), FirstOR.get_in(0));
        make_edge(FirstAND.get_out(), FirstOR.get_in(1));
    }
public:
    one_bit_adder(graph& g) :
        my_graph(g), A_port(g), B_port(g), CI_port(g), FirstXOR(g),
        SecondXOR(g), FirstAND(g), SecondAND(g), FirstOR(g)
    {
        make_connections();
    }
    one_bit_adder(const one_bit_adder& src) :
        my_graph(src.my_graph), A_port(src.my_graph), B_port(src.my_graph),
        CI_port(src.my_graph), FirstXOR(src.my_graph), SecondXOR(src.my_graph),
        FirstAND(src.my_graph), SecondAND(src.my_graph), FirstOR(src.my_graph)
    {
        make_connections();
    }
    ~one_bit_adder() {}
    receiver < signal_t > & get_A() { return A_port; }
    receiver < signal_t > & get_B() { return B_port; }
    receiver < signal_t > & get_CI() { return CI_port; }
    sender < signal_t > & get_out() { return SecondXOR.get_out(); }
    sender < signal_t > & get_CO() { return FirstOR.get_out(); }
};

This implementation is almost a straightforward translation of the gates and their connections into the flow graph format. The one complication is the addition of the broadcast_nodes for each of the input ports. The reason for this is simply to enable connection to a single port from outside of the adder. Since each of the inputs is connected to two gates inside of the one_bit_adder object, there is no single port associated with them automatically. Adding the broadcast_nodes enables us to provide the methods get_A, get_B and get_CI that each return a single port capable of receiving data. So, in looking at the diagram above, you can think of the three broadcast_nodes as standing in for the black junction circles that the three inputs are connected to directly.

To make the four_bit_adder class, simply chain together a set of four one_bit_adders and connect the Carry-out port of each adder to the Carry-in port of the next adder, as shown in Figure 3 below:

Figure 3

This time, the class is even more straightforward to implement, because no broadcast_nodes are needed; every input already has exactly one internal connection.

class four_bit_adder {
    graph& my_graph;
    std::vector < one_bit_adder > four_adders;
    void make_connections() {
        make_edge(four_adders[0].get_CO(), four_adders[1].get_CI());
        make_edge(four_adders[1].get_CO(), four_adders[2].get_CI());
        make_edge(four_adders[2].get_CO(), four_adders[3].get_CI());
    }
 public:
    four_bit_adder(graph& g) : my_graph(g), four_adders(4, one_bit_adder(g)) {
        make_connections();
    }
    four_bit_adder(const four_bit_adder& src) :
        my_graph(src.my_graph), four_adders(4, one_bit_adder(src.my_graph))
    {
        make_connections();
    }
    ~four_bit_adder() {}
    receiver < signal_t > & get_A(size_t bit) {
        return four_adders[bit].get_A();
    }
    receiver < signal_t > & get_B(size_t bit) {
        return four_adders[bit].get_B();
    }
    receiver < signal_t > & get_CI() {
        return four_adders[0].get_CI();
    }
    sender < signal_t > & get_out(size_t bit) {
        return four_adders[bit].get_out();
    }
    sender < signal_t > & get_CO() {
        return four_adders[3].get_CO();
    }
};

Here, the constructor makes a vector of exactly four adders, and connects the Carry-out ports to the Carry-in ports as appropriate. The multi-bit inputs and outputs have port access methods that take a bit as a parameter. So for example, to get the input port for bit 2 of input B, you would use get_B(2).

In Part 3, I will present some interesting input and output devices to add to the logic simulation library, and with those, I’ll put together a small simulation that shows the four_bit_adder in action.

Consider an AND gate. In its simplest form, it takes two inputs, and produces a single output. The first thing that comes to mind to represent this is the flow graph function_node: it could take a pair as input, and a body that computes the logical AND operation on the items in the pair, and puts out the result as its output. That might work, but let’s think a little more about how such a gate might receive its two input signals: a function_node takes a single argument, so I’d have to group the two inputs together. However, both inputs will be coming from different senders, and may not be available at the same time. Should I preface the function_node with a join_node? Possibly, but there’s still a limitation with a join_node: it gathers together the inputs and when it has received the full complement, it then sends them along as a tuple. But this still isn’t exactly the behavior I want. What I really want is when either of the inputs becomes available, the function_node should be told about it, because it will need to change its output value when any of its input values change.

Thus, the first decision about gates is this: Gates are responsive: when any input changes, the gate will check if its output needs to change. To simplify this a little, and make our flow graph have to do a little less work, I’ll make this second decision: Gates are lazy; a gate will send data to its output port only when that data differs from the previous value sent to that output port. This will certainly reduce the number of tasks doing redundant work in the graph.

So, on the input side, something reports changes on any input port, and on the output side, something produces output, or not, depending on if the output value has changed. Neither of these behaviors corresponds exactly to a function_node. However, the new feature multifunction_node (formerly the Community Preview feature (CPF) multioutput_function_node) can certainly meet the output needs: it can optionally produce an output. For the input, if the title of this blog hasn’t given it away already, my choice is the or_node. The or_node will pass along any input it receives on any input port at any time, giving exactly the responsiveness I need. The or_node is currently a CPF in Intel® TBB.

Figure 1

Figure 1 illustrates this basic logic gate design. Note that the or_node takes a variable number of inputs – no need to limit it to two – and the multifunction_node takes a body that produces either no output or one output. In general, the multifunction_node can produce zero or more outputs of varying types, but for the gate implementation, zero or one output will suffice. Let’s take a look at the actual code for this, the gate template class.

First, I set up a type signal_t to represent the signal data being transferred. Since I’m allowing the gates to fire only when the output state changes, it helps to have an additional undefined state for initialization.

typedef enum { low=0, high, undefined } signal_t;

Next, I define a few potential input configurations to gates. I could go all out and add eight_input gates, but I couldn’t dredge up a use for them from the dark and rarely-visited corner of my brain where I keep the knowledge leftover from a digital logic course so many years ago.

typedef tuple < signal_t > one_input;
typedef tuple < signal_t, signal_t > two_input;
typedef tuple < signal_t, signal_t, signal_t > three_input;
typedef tuple < signal_t, signal_t, signal_t, signal_t > four_input;

Now I’m ready to set up the gate template.

template < typename GateInput >
class gate {
protected:
    typedef or_node < GateInput > input_port_t;
    typedef multifunction_node < typename input_port_t::output_type, tuple < signal_t > > gate_fn_t;
    typedef typename gate_fn_t::output_ports_type ports_type;
public:
    static const int N = std::tuple_size < GateInput > ::value;

    template < typename Body >
    gate(graph& g, Body b) : my_graph(g), in_ports(g), gate_fn(g, 1, b) {
        make_edge(in_ports, gate_fn);
    }
    virtual ~gate() {}
    virtual gate& operator=(const gate& src) { return *this; }
    sender < signal_t > & get_out() { return output_port < 0 > (gate_fn); }
    receiver < signal_t > & get_in(size_t port) {
        return gate_helper < N > ::get_inport(in_ports, (int)port);
    }
protected:
    graph& my_graph;
private:
    input_port_t in_ports;
    gate_fn_t gate_fn;
};

The class is templated by the input configuration, GateInput, so for example, I would pass in two_input if I wanted to make a gate with two inputs. Then I define two types. First, input_port_t, which is the type of the or_node that that I’ll pass the input configuration to, as specified by GateInput. Second is gate_fn_t, which is the multifunction_node that takes the output from the or_node, performs the function of the gate, and outputs a single signal_t (or nothing). These types are used to declare the actual graph nodes in_ports and gate_fn, in the private section of the class above.

The gate constructor initializes the two graph nodes, making them belong to a graph g that is passed in as a reference parameter. Additionally, the constructor takes a function object b that performs the actual logical operation on the inputs to the gate, and determines what the new output will be. So in the case of an AND gate, I would pass in a function object that computes a logical AND operation. The constructor also completes this small component by connecting the two graph nodes with the make_edge function.

In order to connect this gate to other components, I’ve provided methods to access the input ports and the output port. get_in takes a port number and returns a reference to an input port capable of receiving data, i.e. a receiver& in the flow graph jargon. It uses the gate_helper::get_inport function shown below to extract the input port to the or_node. get_out returns a reference to the output port of the multifunction_node which is capable of sending data, i.e. a sender&.

template < int N >
struct gate_helper {
    template < typename TupleType >
    static inline receiver < signal_t > & get_inport(or_node < TupleType > & in_ports, int port) {
        if (N-1 == port) return input_port < N-1 > (in_ports);
        else return gate_helper < N-1 > ::get_inport(in_ports, port);
    }
};
template < >
struct gate_helper < 1 > {
    template < typename TupleType >
    static inline receiver < signal_t > & get_inport(or_node < TupleType > & in_ports, int port) {
        return input_port < 0 > (in_ports);
    }
};

Now that I have a building block for creating a wide variety of logic gates, I’ll use it for designing an AND gate. When creating the derived class and_gate, the main purpose is to define the functor that gets passed to the gate_fn object inside the gate base class. and_body computes a logical AND operation over all the inputs to the gate, including undefined inputs, so the function is not completely trivial.

template < typename GateInput >
class and_gate : public gate < GateInput > {
    using gate < GateInput > ::N;
    using gate < GateInput > ::my_graph;
    typedef typename gate < GateInput > ::ports_type ports_type;
    typedef typename gate < GateInput > ::input_port_t input_port_t;
    class and_body {
        signal_t ports[N];
        signal_t state;
        bool touched;
    public:
        and_body() : state(undefined), touched(false)
            for (int i=0; i < N; ++i) ports[i] = undefined;
        }
        void operator()(const typename input_port_t::output_type& v, ports_type& p) {
            ports[v.indx] = or_output_helper < N > ::get_or_output(v);
            signal_t new_state=high;
            size_t i=0;
            while (i < N) {
                if (ports[i] == low)
                    new_state = low; break;
                else if (ports[i] == undefined && new_state != low)
                    new_state = undefined;
                ++i;
            }
            if (!touched || state != new_state) {
                state = new_state;
                std::get < 0 > (p).try_put(state);
                touched = true;
            }
        }
    };
 public:
    and_gate(graph& g) : gate < GateInput > (g, and_body()) {}
    and_gate(const and_gate < GateInput > & src) : gate < GateInput > (src.my_graph, and_body()) {}
    ~and_gate() {}
};

The and_body keeps track of the states of the gate’s input ports and output port. These are all initially undefined. The operator() for and_body receives the or_node output in parameter v, which indicates that data was received on one of the input ports. The input port that received data is specified in v.indx. Accessing the data from that port is a little more challenging, as the entire input tuple is passed in v.result. I wrote a helper function or_output_helper::get_or_output to select the v.indx-th port of the tuple v.result. This value is used to update the locally stored state of the appropriate port, and then the new output state is calculated. The new state is checked to see if it differs from the old state, and if so, the new state is sent out on the appropriate output port of the multifunction_node (which in this case, since there is only one output, is always port zero). Note also that the very first time a gate receives data, i.e. when touched is false, the new state is sent out even if it is not different from the initial state. This is useful when the gate is a part of a larger circuit. It allows any initial settings on input ports to propagate through the graph and register at any possible output devices that might exist.

The helper function that extracts the or_node output is as follows:

template < int N >
struct or_output_helper {
    template < typename OrOutputType >
    static inline signal_t get_or_output(const OrOutputType& out) {
        if (N-1 == out.indx) return std::get < N-1 > (out.result);
        else return or_output_helper < N-1 > ::get_or_output(out);
    }
};
template < >
struct or_output_helper < 1 > {
    template < typename OrOutputType >
    static inline signal_t get_or_output(const OrOutputType& out) {
        return std::get < 0 > (out.result);
    }
};

Given an AND gate, it’s easy to see how to make OR gates and any other sort of basic logic gate from the base class gate.

As the or_node is currently a Community Preview feature, it’s a good time to have a look at it and give us your feedback.

In Part 2 of this blog, I’ll show you how to put together a variety of basic logic gates to make a four-bit adder.

There are two modes of use for this feature: basic mode and expert mode. Basic mode is straightforward and not much more complex than using a mutex. Expert mode requires some understanding of how the aggregator works, and additional coding, but can enable additional performance improvements. In this blog, I will first illustrate how to use the aggregator in the basic mode. Then I’ll give a brief overview of how the aggregator works, followed by an example of how to use the aggregator in the expert mode. Finally, I’ll examine the performance of the aggregator and suggest approaches to help decide whether or not to use it.

Side-by-side Comparison of Basic Aggregator Usage with Mutex Usage

In this simple example, I’ll compare the usage of a mutex with an aggregator to lock push and pop operations on a serial priority queue object of type std::priority_queue. This example uses C++1x features, such as lambdas, but one could use function objects instead. Fair warning: I’m interspersing code snippets below, because this blog format doesn’t allow for side-by-side code comparison. Please don’t try to use both a mutex and an aggregator to protect the same code.

First, declare the priority queue. I'll use a simple integer priority queue here:

typedef int value_type;
typedef priority_queue < value_type, std::vector < value_type > , compare_type > pq_t;
pq_t my_pq;

Declare a mutex to protect my_pq:

spin_mutex my_mutex;

Alternatively, declare an aggregator to protect my_pq:

aggregator my_aggregator;

Declare an element to push/pop from queue:

value_type elem = 42;

Now, push an element on the queue using the mutex:

{
    tbb::spin_mutex::scoped_lock my_lock(my_mutex);
    my_pq.push(elem);
}

Or, push the element on the queue using the aggregator and a lambda expression:

my_aggregator.execute( [&my_pq, &elem](){
    my_pq.push(elem);
} );

Pop an element off the queue using the mutex:

bool result = false;
{
    tbb::spin_mutex::scoped_lock my_lock(*my_mutex);
    if (!my_pq.empty()) {
        result = true;
        elem = my_pq.top();
        my_pq.pop();
    }
}

Pop an element off the queue using the aggregator:

bool result = false;
my_aggregator.execute( [&my_pq, &elem, &result](){
    if (!my_pq.empty()) {
        result = true;
        elem = my_pq.top();
        my_pq.pop();
    }
} );

How the Aggregator Works

As we see above, the usage of the aggregator in basic mode is trivially different from using a mutex. However, it is clearly working in a different way. In order to execute a critical section, you pass it to an aggregator via the execute method. When the execute method returns, the critical section has been executed, but how this happened is hidden inside the black box of the aggregator.

Looking at the header file aggregator.h that defines the aggregator, these details become clear. To use the aggregator in expert mode, you should have some familiarity with the header file, and I'll guide you through the most important features in the rest of this blog.

First note that aggregator inherits from a class aggregator_ext that takes a template parameter. Aggregator instantiates that template parameter with a simple handler defined in the header, handler_type = internal::basic_handler. We will discuss this more later.

The execute method of aggregator takes a function body as parameter, and encapsulates body in a basic_operation object, which inherits from aggregator_operation. Aggregator_operations are sent to the aggregator_ext’s mailbox where they may concurrently accumulate while they await execution. One thread, the active handler, i.e. the first thread to place an aggregator_operation in the empty mailbox, will grab all the operations that have accumulated there, effectively emptying the mailbox. It will then go through all the operations that it grabbed, and serially execute the function bodies stored in those objects. The mechanism used to execute function bodies is specified by aggregator_ext’s template parameter, which in the default case is called basic_handler.

This basic_handler is straightforward in its functioning: it is passed the list of aggregator_operations, and it loops through this list and handles each item. It makes use of a few methods on aggregator_operation to do this properly: next is used to traverse to the next operation in the list, start prepares the operation to be handled, and finish is called after the operation is handled to inform the thread waiting on the execution of the operation that the operation is completed. When all operations are handled, the active handler thread can leave the aggregator, since its own call to execute has been satisfied in the process.

The details of the synchronization that make this all possible can be found in aggregator.h. We won’t explain them fully here, because we already have enough information to proceed to use the aggregator in expert mode. It is enough to know that threads hand over critical sections to the aggregator, and one of these threads will execute all the operations serially on behalf of the other threads as a single critical section.

Using the Aggregator in Expert Mode

I’ll use the same example as before, allowing threads to safely push and pop to a serial std::priority_queue. The expert mode of aggregator allows the user to pass any sort of data in to the aggregator as an aggregator_operation via the process method (note the different method name – we were using execute in basic mode), along with an aggregating function object that is called by the active handler to perform the serial execution of operations. In this case, I’ll pass data about a push or pop operation to the aggregator via process, and provide a custom function object to perform the operations.

First, create a class derived from aggregator_operation to hold the operation data.

class op_data : public aggregator_operation {
public:
    value_type* elem;
    bool success;
    bool is_push;
    op_data(value_type* e, bool push=false): elem(e), success(false), is_push(push) {}
};

Then, create a handler to pass in as the aggregator’s template parameter:

class my_handler_t {
    pq_t *pq;
public:
    my_handler_t() {}
    my_handler_t(pq_t *pq_) : pq(pq_) {}
    void operator()(aggregator_node* op_list) {
        op_data* tmp;
        while (op_list) {
            tmp = (op_data*)op_list;
            op_list = op_list->next();
            tmp->start();
            // handle tmp here
            if (tmp->is_push) pq->push(*(tmp->elem));
            else {
                if (!pq->empty()) {
                    tmp->success = true;
                    *(tmp->elem) = pq->top();
                    pq->pop();
                }
            }
            // done handling tmp
            tmp->finish();
        }
    }
};

Now, to create an aggregator, use the aggregator_ext type name and pass this handler’s type in as the template parameter, and initialize the handler and pass it in as an argument to the constructor:

aggregator_ext < my_handler_t > my_aggregator(my_handler_t(my_pq));

To perform a push, simply create the op_data node with the push information and pass it to process:

op_data my_push_op(&elem, true);
my_aggregator.process(&my_push_op);

And to perform a pop:

bool result;
op_data my_pop_op(&elem);
my_aggregator.process(&my_pop_op);
result = my_pop_op.success;

When to use Aggregator and why use Expert Mode?

A good way to start is to compare the performance of your code using your current locking mechanism to a version of your code that uses an aggregator instead. In practice, we (developers of TBB) have often found that a mutex is sufficient and outperforms aggregator when contention on the critical region is low. For higher contention, we often find that the use of the aggregator is justified.

The aggregator provides most of its performance improvements in hot cache execution of operations on a single thread. (Recall the active handler?) Thus, the more concurrent contention on your critical region, the larger the aggregations will be that are assembled, and the greater the benefits of executing operations with a hot cache on a single thread.

If you do find that the basic aggregator improves your code’s performance, consider moving to the expert level. To begin with, you can simply transform your code as I’ve shown in the expert example above. This should result in better performance over the basic interface. The reason for this is that, in the basic interface, the function object or lambda expression you wish to execute and all the references to data that you want that code to access are stored on the stack of the thread that originated the operation. Referring back to the basic example, this means that for each operation, we look up a different reference to the same priority queue. But, in the expert example above, note that we store just a few data references in the aggregator_operation, and the code to execute the operation and references to the shared data (my_pq) are local to the aggregating functor and only need to be looked up once to handle all the operations in an aggregation. This enhances the hot cache effect by reducing the quantity of non-local stack accesses.

The expert-level usage of aggregator shown above is quite straightforward. However, you are free to handle operations in the aggregating handler in whatever manner you like. Consider the aggregation of operations an opportunity to develop new and interesting serial algorithms. This gives you a unique opportunity to make use of a kind of lookahead capability: you know the set of operations that you need to perform. For example, Intel® TBB’s concurrent_priority_queue handles the operations in two passes, performing some of them and postponing others, because some orderings of operations are more efficient than others. The only rules for processing operations in the aggregating handler are that they should all be handled, and, in some cases, there should be some serial sequence of the operations that achieves the same result (i.e. sequential consistency).

I’d like to hear about your experiences using aggregator, so if you get a chance, give it a try, and let me know how it went! You can comment here, or better yet, start a discussion on the Intel® TBB forum.

I recently attended a symposium, co-sponsored by TACC and Intel, at the Texas Advanced Computing Center (TACC) in Austin where the programming of two many-core devices were discussed. One was a research chip designed to push some limits and allow interesting research on a device that lacks many things a product would require. The research chip is known as Intel’s Single-Chip Cloud Computer (SCC). The other many-core device was, a prototype of our new Intel Many Integrated Core (MIC) Architecture, the Knights Ferry co-processor. The deadline for papers precluded inclusion of results from pre-production Knights Corner co-processors which will be the first Intel MIC co-processor products. There was a lot of whispering in the hallways about the excitement of starting work with Knights Corner co-processors.

The papers, and the half day tutorial, at the “TACC-Intel Highly Parallel Computing Symposium” all had strong elements relating to familiar parallel programming challenges: scaling and vectorization. This is because both devices are built on Intel Pentium processor cores hooked together with their design for a connection fabric on the same piece of silicon.

Simply put, they are both SMP on-a-chip (symmetric multi-processors) devices, with somewhat different design goals.

At Intel, we have been convinced that putting a familiar generally programmable SMP on-a-chip is a good idea. It has a familiarity in programmability which proves to have many benefits. SCC was built for research into many facets of highly parallel devices. Knights Corner is designed for production usage and is optimized for power and highly parallel workloads. Knights Corner is well suited for HPC applications that already run on SMP systems. Presenter after presenter who talked about using the prototype Knight Ferry mentioned how applications “just worked."

I like to say, “Programming is hard, and so is parallel programming.” It follows that making an SMP or an SMP on-a-chip get maximum performance may not quite be rocket science, but it is no walk in the park. So, there was plenty of room for the papers to discuss the challenges of tuning for any SMP system.

What was really striking was how optimizations for Knights Ferry co-processors were applicable to SMP systems in general. Several authors commented on how their work to get better scaling or better vectorization for Knights Ferry also improved the performance of the same code compiled to run on an Intel Xeon processor based SMP system.  This performance-reuse is very significant, and one presenter exclaimed “Time spent optimizing for MIC is time well spent because it optimizes your code for non-MIC processors at the same time.”

All the papers and presentations (including my keynote) are available on-line now at http://www.tacc.utexas.edu/ti-hpcs12/program

Here are some notes from a few of the talks:

Dr. Robert Harkness, gave an engaging talk entitled “Experiences with ENZO on the Intel Many Integrated Core Architecture.” I enjoyed his comment that “we always programming for the future” because they “never have enough compute power.” He looked at multiple programming models, but had the best results using the “dusty” MPI based program that he had running on an SMP before Knights Ferry. He did his work on MPICH 1.2.7p1 because Intel did not supply an MPI with the Knights Ferry systems. He said it was obsolete but very easy to build and use. He reported that one person (not a dedicated programmer) was able to build everything (a quarter million lines of code) in a single week without any application source code modifications at all. The week, it seems, was spent hunting down libraries and recompiling them including MPICH. His results scaled very well.

His conclusions (from slide 30 of his presentation) were: “Intel MIC is the best way forward for large-scale codes which cannot use the existing GPGPU model (even with directives).”

A talk by Theron Voran, with the National Center of Atmospheric Research, looked at using Knights Ferry for Climate Science. He started by saying "We have large bodies of code laying around. We don't want to rewrite in new languages for restrictive architectures." He had several good introduction slides including a comparison of accelerators vs. multicore and many-core devices.

Here the challenges of vectorization offered opportunities for future work. Compiler hints, loop restructuring and relate activities should enhance performance on Xeon-based and MIC-based SMP systems, as well as work on improving scalability on more and more cores. Even with these challenges, the authors noted “Relative ease in porting codes” (recompiling) and the belief that computational capabilities of MIC will be worthwhile.

Ryan Hulguin, with the University of Tennessee, looked at CFD solvers on Knights Ferry. He looked at two methods, one based on Euler equations (for inviscid fluid flows) and another based on the BGK model Boltzmann equation (for rarefied gas flows). Performance results showed OpenMP to be effective on Knights Ferry, and that the SMP programming challenges of vectorization and having good concurrency held true on Knights Ferry as well.

A talk on Dense Linear Algebra Factorization, from David Hudak at the Ohio Supercomputing Center, talked about Heterogeneous Programming Challenges. David is a Wolverine working in a Buckeye world. My heart goes out to him. I really enjoyed his separation of short-term issues that distract us from the real long-term challenges that will stay with us.

The talk compared a QR factorization implemented in OpenMP with a Cilk Plus implementation. Both performed well. The authors emphasized that guidance to Vectorize and use lots of tasks, proved to work.

I’ve written more than I set out to write, so I’ll stop here. The SCC related papers were very interesting as well, ranging from Tim Mattson’s overview of the program to papers showing research results from investigations using SCC. The other MIC related papers are all worthy as well, including an excellent paper on early experiences with MVAPICH2 doing Intra-MIC MPI communication. Amazing things you can do on an SMP on-a-chip… it runs a real Linux after all!

It is very common for demos to start with an ‘ssh’ (shell) to one of the Knights Ferry processors… and then running the application natively from the command line. SMP on-a-chip, indeed.  Too bad I can’t convince Intel to name it that.  Even if I did, it would probably be chipSMP™ model 8650plus XS. Nevermind, Knights Corner is fine by me.

The papers and talks can be at http://www.tacc.utexas.edu/ti-hpcs12/program

In support of the recent announcement of the 3^rd Generation Intel® Core™ Processors, Intel has released the Intel® SDK for OpenCL* Applications 2012. For the first time, OpenCL* developers using Intel® architecture can utilize compute resources across both Intel® Processors and Intel® HD Graphics Driver 4000/2500

From a person who, for the last couple of years has closely followed the emergence of the OpenCL standard, this announcement was something worth waiting for.  Less than a year ago, on this blog, I posted the news that the Intel® OpenCL SDK 1.1 gold  was released,  This was the first production OpenCL implementation from Intel targeting Intel® processors on Windows* OS. This current announcement is special, the Intel SDK for OpenCL Applications 2012 now supports not only the CPU but also the Intel HD Graphics 4000/2500 for Windows* 7 users.  We’ve come a long way in a year.

OpenCL on the 3^rd Generation Intel® Core Processor Family extends Intel’s line of tools and APIs on Intel platforms and adds interoperability with other graphics APIs like DirectX*, OpenGL* and Intel® Media SDK, directly on the Intel HD Graphics device.

So what else is new in this release?

• A Single OpenCL* platform enables shared context for OpenCL applications running on both the CPU and Intel HD Graphics 4000/2500. The OpenCL platform with both CPU and HD Graphics devices is available seamlessly on the Intel® HD Graphics Drivers.
• Interoperability with the Intel Media SDK with no memory copy overhead
• Improved performance for OpenCL applications running on Intel® Xeon® Processors and Intel® Core™ Processors. This CPU support is also available for Linux* OS developers.
• Intel® SDK for OpenCL* applications development tools includes an offline compiler and a step-by-step OpenCL Kernel debugger (for CPU) integrated in Microsoft Visual Studio* 2010 integrated development environment.
• 10 OpenCL code samples, three of them new, are now available for independent download.

The list above is just a sample of what is available with this new SDK. I recommend you read the product brief or watch the introduction video to get started with this new SDK.

Download the SDK for free at www.intel.com/software/opencl and begin optimizing your applications for the 3^rdGeneration Intel® Core™ Processors today.

Don’t forget to follow us on Twitter at @IntelOpenCL

The attacthed video demonstrates how this tool can be used (and where to go get it.) The user may decide that their environment calls for more configuration that what they get from this tool. Here is a tip that the average developer may not know:

Along with the ACU Wizard, there is also a Configurator Command Line Interface (that's right - you can push scripts down to your client and have them run locally. If you require Admin Control Mode rather than Client Control mode, there is a command for that too. If you require TLS Communications, you can apply that once your system has AMT Enabled as well (if there is an API in the SDK, there is nothing you can't change about your AMT Configuration once Intel AMT has been enabled.)

You can download the most current version of the Intel SCS HERE (note that soon it will be refreshed with Intel SCS 8.0)

The following video demonstrates how to quickly configure an Intel AMT Client using the ACU Wizard.

If you've ever dual booted a system before, the procedure for doing it for Windows 8 is not all that different. In summary, all you need to do is create a new partition for Windows 8, install it on that partition, and then edit your new boot menu if you want to keep Windows 7 as the default OS.

Step One: Download and burn the Windows 8 Consumer Preview

• Assuming that you downloaded the Consumer preview ISO image from the link above, you can use the “ Microsoft Windows 7 USB/DVD Download Tool to either burn the ISO image to a DVD disc or a USB drive. The tool is free, and very small, and installation instructions are available in the site itself and are very simple. Of course if you prefer to use other burning software like ImgBurn, you can do that too.

Step Two: Create a New Partition

• Before you start, make sure to make a backup of your data and files. We will be creating new partitions and installing a new OS, so anything could go wrong, and you don't want to lose your everything. For paranoid people like me, I like taking "bare metal" backups of my systems with a wonderful open source and free tool called Redo Backup. A bare metal backup takes a complete image of your hard drive, with all of its partitions. That way, I am able to restore my entire system the way it was exactly if needed. Going into more details about backups however is another topic.

• When you're ready, from within Windows 7, we will create some space for Windows 8 by using Windows' Disk Management. Click on the Start Menu and right click on "Computer", then click "Manage", and in the window that appears, click on "Disk Management" in the left sidebar.

• Find your system hard disk in the graphical list that appears in the bottom pane. Right-click on it and then click "Shrink Volume". 20 GBs is a reasonable size that is not too small and not too big for the new Windows 8 partition, so shrink it down so you have at least 20GB of space left on the end of the drive, and click OK. Of course if you think you need more than 20 GB (if you are going to do intensive development and/or testing), or less than 20GB (if you don’t have enough space on your Windows 7 partition), then please feel free to choose a different size.

• Then, click on the "Unallocated" block of that drive that appears and click "New Simple Volume". Click Next on the next few windows until you reach the "Format Partition" window. Here, give it a volume label you'll recognize (like "Windows 8") and click Next. It should format the drive for you. Now you're all set to install Windows 8.

Step Three: Install Windows 8

• Now reboot your system, and go into your BIOS settings (for most systems, you need to press F2 or DEL). Now make sure your computer is set to boot from CD or USB as a first priority (depending on what medium you have decided to use earlier). This may be different from system to system though. Now reboot.

• Now you should boot into the Windows 8 installer. It looks very similar to the Windows 7 installer, so it should be familiar. Pick your language and hit "Install Now”.

• Enter the Product Key available on the Windows 8 Consumer Preview download page.

• Now choose "Custom" when asked what type of install you'd like to perform. Then find the new partition you created on the list of drives shown. Make sure it's the right one, because remember, you are about to write over whatever is on it.

• Hit "Next" and let the installer do its thing. When you're done, your computer should reboot into Windows 8. It'll probably reboot one more time after it does, then you will see the Windows 8 Start screen.

Step Four: Make Windows 7 the Default OS Again