The central issue in the flaw is that secret prime numbers generated to create the crypto keys must be generated randomly. The findings indicate that in some cases the prime numbers were not generated in a random enough way, which lead to crypto keys having prime factors in common.

According to Intel’s Greg Taylor, and George Cox (see Behind Intel's New Random-Number Generator), researchers have managed to devise pseudo, random-number generators that are considered cryptographically secure. But you must still start them off using a special seed value; otherwise, they'll always generate the same list of numbers. And for that seed, you really want something that's impossible to predict.

Enter Intel’s digital random number technology, code named Bull Mountain. Bull Mountain is a hardware based digital random number generator which will be released this year when the processor, code named “Ivy Bridge” is launched. Bull Mountain allows digital random numbers to be generated at near clock cycle speeds and with a very high degree of randomness or “entropy” as the crypto folks say it. Using such highly random seeds in the cryptographically secure pseudo random-number generators could help allay the concerns raised by this new research into the RSA flaws.

For more information, you can download the Intel® Bull Mountain Software Implementation Guide and code samples here.

A wide variety of ways exist for addressing these kinds of security challenges and Intel offers technologies to assist in the battle.  For probably the most sane and scalable way of addressing security issues, at least for enterprise applications, I would recommend that you jump over to Blake Dournaee's (Intel) blogs "Using a Service Gateway to Protect against the OWASP Top 10" and "How about a Security Layer?".  The idea of a Security Layer on a Service Gateway is truly the most comprehensive way to tackle these kinds security issues. 

Never-the-less, some enterprise shops may be unwilling to re-architect their legacy systems using the security layer approach and some developers are targeting client applications.  What tools and techniques can these developers use to mitigate security bugs?  For those developers I offer the following:

 I had a chat with Julian Horn, who is Intel's architect on the compiler team for the Static Security Analysis (SSA) tool.  SSA comes as part of the Intel compiler (C/C++/Fortran) and is available for Linux* and Windows*.  SSA identifies various coding errors such as memory and resource leaks, pointer and array errors, incorrect use of OpenMP* directives, and incorrect use of Cilk Plus language features.  SSA also identifies security errors such as buffer overflows and boundary violations, use of uninitialized variables and objects, incorrect usage of pointers and dynamically allocated memory, dangerous use of unchecked input, arithmetic overflow and divide by zero, and misuse of string, memory, and formatting library routines.

I was curious what kind of security flaws that SSA could find. Specifically, I wanted to know if it could help developers to mitigate any of the most dangerous software errors as identified by the Common Weakness Enumeration (CWE) community sponsored by Mitre.

After an email exchange with Julian, and pouring over the descriptions of the top twenty-five security bugs as reported by CWE, I determined that the Intel SSA could help to mitigate at least two of the top five errors listed.  Coming in at error number two is "OS Command Injection", and at number three was "Classic Buffer Overflow". How can SSA mitigate these errors?

Identification and Mitigation of CWE Top Error #2 (OS Command Injection)
OS Command Injection is an error type that really should be checked on both server and client side applications.  The essence of this error, or potential attack, is that, sometimes, your application is a bridge linking an outsider to the internals of your operating system. If your application simply passes un-trusted inputs to be fed into a command string that you pass to a system call, then your application can inadvertently wreak all kinds of havoc on the system. The recommended mitigation step is to validate all inputs to your application.

A simple minded BAD example, in "C", might be issuing a system call to delete a file that a user types in.

          // user inputs a filename to be deleted
          scanf (“%s”, str);                        // buffer overflow
          sprintf (cmd, "del %s", str);   // another buffer overflow
          system(cmd);                             // OS command injection, due to not validating the input

What happens if the user types into the input *.* rather than a normal filename?  Since the input has not been validated and was passed right to the OS, then clearly deletions unintended by the developer would occur. 

Analyzing your code for un-validated input is known as taint analysis – tainted input means un-validated input.  CWE recommends doing a taint analysis to identify where in your code you are not validating input, and then take steps to remove the taint.

Intel's Static Security Analysis tool uses a taint analysis algorithm to detect whether or not an unknown input has been compared against another value.  There are various rules under which taintedness is propagated from one variable to another.  One rule is that when a value is compared against another value this removes the taint.  If an untested value is used in a “dangerous” context, then you get an error reported by SSA.

The logic here is that a comparison is considered sufficient to sanitize the value.  The example below demonstrates the idea of tainted variable, x.  When x is used blindly with no comparisons done on it to check it validity, SSA flags this value as tainted:

          x = input;
          a[x] = 0;   // SSA identifies use of tainted value x

The example below uses a comparison operator to check the input value x, so it is considered untainted now by SSA:

          x = input;
          ok = (x < 10);     // comparison un-taints the value x
          if (ok) a[x] = 0;

This "good" example might still have some issues with it, the checking is not extensive, but at least the developer went to some effort to validate the input.

The key take away here is to use tools to find un-validated inputs and then add the necessary validation around each of these inputs.

Identification and Mitigation of CWE Top Error #3 (Classic Buffer Overflow)
Michael Howard & David LeBlanc, in their book Writing Secure Code, 2nd edition, identify the buffer overflow (AKA buffer overrun) as public enemy number one.  The Common Weakness Enumeration list is kinder, listing this issue as the number three most dangerous error.  It is well known that certain "C" functions are unsafe because they are vulnerable to buffer overflow attacks. These functions should be replaced with safe counterparts : strcpy, strncpy, strcat, and gets, among others. 

The buffer overflow terminology comes from the idea that if you continue to pour water into a finite sized container, the container will eventually overflow. In computer terms, the analogy means that copying too much text into a finite sized array, will cause the extra text in the buffer to spill over into areas of memory that the developer did not intend.  These areas of memory get corrupted with the excess text and malicious coders use this to exploit your application and potentially run malicious code within the confines of your application's process. I found the following buffer overflow example insightful, though I didn't want to copy it here in its entirety and will simply link to it instead.  It demonstrates how an overflow attack can occur and is found on an MSDN blog by Robert Horvick.

Other strains of buffer overflow can occur in some types of formatted input.  The biggest issue here is when the "%s" input format is used. This format specifier is generally regarded as unsafe. In the Intel Parallel Studio XE evaluation guide on Static Security Analysis (SSA), there is a nice example of SSA detecting a buffer overflow in a fscanf function. In this case, SSA indicates that it found an "unsafe format specifier," which is essentially a condition that can lead to buffer overflow.  The code snippet from this guide is as follows:

          // example that would allow buffer overflow  
          char data[255];
          fscanf(dfile, "%s", data);
          if (strcmp(data, string) != 0) {
                fprintf(stderr, "parse: Expected %s, got %s \n", string, data);
          }

The call to fscanf uses an input descriptor string with a “%s” format specifier. This reads input characters up to the next newline and stores the data in the array “data”. There is no guarantee that the number of characters read will not overflow the bounds of the array, so this statement could corrupt memory.  SSA reported this as an error and the developer should follow up by making code changes using an alternative format specifier such as the "%255s"  to limit the number of characters read in.  The corrected code should be something like this:

          // example that corrects the undesired  buffer overflow  condition
          char data[255];
          fscanf(dfile, "%255s", data);
          if (strcmp(data, string) != 0) {
                fprintf(stderr, "parse: Expected %s, got %s \n", string, data);

For similar tips on how to protect your code through defensive programming, read this article by McGraw & Viega, Make your software behave: Preventing buffer overflows.

The key take away here, in addition to validating all  inputs, is to find unsafe “C” functions and format specifiers, and replace them with safe alternatives .

What should a developer do?
The security bugs discussed above are two of the most dangerous and prevalent according to CWE.  These bugs affect client applications that are run on laptops, desktops, ultrabooks, as well as enterprise applications on web servers, application servers, database servers and more.  Developers are urged to find these kinds of bugs using tools such as Intel Static Security Analysis, and then make it a practice to validate all inputs and to replace unsafe functions (strcpy, strncpy, strcat, and gets, among others)  with safe counterparts.  To learn more about steps you can take as a developer to reduce your exposure to security attacks go to the Department of Homeland Security's Build Security In website or visit the Common Weakness Evaluation site.

Oh, and did I mention that enterprise developers  should  jump over to Blake Dournaee's (Intel) blogs "Using a Service Gateway to Protect against the OWASP Top 10" and "How about a Security Layer?" to learn an even better way to secure your systems?

For more complete information about compiler optimizations, see our Optimization Notice.

Okay - so what is the Advanced Encryption Standard (AES)?

AES is a standard that defines how to encrypt plain text using an encryption key. It is implemented with the RijnDael (pronounced Rhine Dahl) algorithm. One cool thing about AES is that even though this algorithm is completely open for examination, it is possible to encrypt a plain text message with it that is very, very difficult to break. This is possible because the algorithm takes the plain text message you want to encyrpt, and merges it in a certain way with a secret key. As long as the key is kept private, the encrypted message has proven to be safe from being broken, at least to this point in time. So the algorithm is completley known, but as long as the key is protected, messages encoded with it are virtually safe from eves dropping.

So who cares?
So what kind of software developers might use AES? and who might benefit from the new AES-NI? There may be more than you think at first: developers who write code that that use secure socket layer (SSL), database engines, whole disk encryption applications, files compression applications, VoIP, instant messaging, email, virtualization software, electronic payment systems, virtual private networks, and list goes on. To learn more about who might use AES see this wiki article on AES instruction set or this article on AES-NI analysis on Tom's Hardware.

So how does AES (Rijndael) work?
To understand how the AES (Rijndael) algorithm works I highly recommend that you look at Jeff Moser's "A Stick Figure Guide to the Advanced Encryption Standard (AES) - A play in 4 acts". This creative, stick figure, cartoon approach is the best method I have seen for communicating how AES works - five stars Mr. Moser!

My stick figure image below is an icon tribute to the excellent efforts of Mr. Moser in laying bare the essense of AES.

Thanks Mr. Moser!

What is AES-NI - second answer
Now consider that the six AES-NI from Intel provide two instructions to accelerate encrypting a round, two instructions for decryping a round, and two more instructions to accelerate the generation of round keys. In summary, the six new instructions provide a faster way to crunch through the Rijndael algorithm (AES). Curious to know more? Read more about it in my friend, Jeff Rott's, blog. Jeff wrote an excellent blog on Intel® Advanced Encryption Standard Instructions (AES-NI), in which he introduces the six instructions, describes the benefits, and introduces ways to actually implement these in your code (plus references).

So how can you implement AES-NI in your code?
As long as you are using one of the following compilers (or later) you can get direct access to the instructions:
AES-NI are supported by version 11 of the Intel C/C++ compiler, and also by Microsoft* Visual Studio* 2008 Service Pack 1 and by gcc version 4.4.
You can implement it the hard way using MASM or inline assembly. Or you can make it easier on yourself and use compiler intrinsics (just be sure to include wmmintrin.h or intrin.h). See Martyn Corden's Post here on Compiling with AES-NI. Another approach is to use a library such as OpenSSL or Intel's IPP to implement AES-NI - Jeff has references ;-)

If you really want to dig in and see the reference and code snippets read Intel's Shay Gueron's in-depth whitepaper called "Intel® Advanced Encryption Standard (AES) Instructions Set". See Shay's abstract and whitepaper link here.

Finally - if you want a complete understanding of AES, much more than you will find in a Wiki article or blog, then check out the following book. "The Design of Rijndael" is the definitive book on the subject, written by the Rijndael creators.

Optimization Notice
Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice.

Notice revision #20110804

In my new role, I have been learning about many of Intel’s security technologies and am excited about bringing these technologies to light in my blogs, and Intel Software Network TV.

To see why I am excited, and a little daunted with my new tasks, take a look at a couple of clips of Mooly Eden at Intel’s recent Intel Developer Conference. These technologies are amazing ,…but there is so much ground that they span! The first clip showcases Intel’s Anti Theft technologies (starting at 31:10 mark and ending at 34:57). Here Mooly invited McAfee co president, Todd Gebhart, to the stage to discuss McAfee’s Anti Theft which allows a user to lock their laptop or even wipe their data by issuing a poison pill in the event that their laptop is stolen. Then Mooly introduced a new technology called Intel Identity Protection Technology (IPT) . To showcase this technology, Mooly had a hacker, garbed in a ninja costume, attempt to use a key logger and frame grabbing software to attempt to hack, demo presenter, Mark’s bank transaction. In this amazing clip, the hacker successfully grabs the username and password to Mark’s bank account, using a nefarious keylogger. BUT – the hacker cannot capture or generate a third authentication token which has been set up between Mark & his bank. The hacker is thwarted from any mischievous activity by IPT. Using this IPT technology, a random layout pin pad is generated and displayed to Mark, which allows Mark to send an additional credential to the bank in order to authenticate the transaction. Mark’s bank account is safe! See this part of the clip at 35:08 to 38:44. If you want to learn even more, see Intel’s Ned Smith’s IPT foils at 2011 Kerberos conference.

I plan to be interviewing experts from various corners of Intel to help describe these technologies in more detail. We will also be working to bring API’s to light with Software Developer Guides, tech briefs, and whitepapers, videos and more.

I also hope to keep one eye on new developments in the security space in the rest of industry to help articulate security, virtualization and manageability trends that I see developing.

To learn more about what occurred at IPDPS take a look at Lauren Dankiewicz' blog where she lays out the conference processing with links to video coverage of various keynotes and panels.

I listened attentively to the panel which looked back on 25 years in parallel and distributed computing. I cannot adequately summarize each panelists view but I have included a link to the broadcast so you can view & hear these opinions first hand. The panel consisted of:
Moderator: Yves Robert, Ecole Normale Supérieure de Lyon, France
Panelists:
William (Bill) Dally, Stanford & NVIDIA
Jack Dongarra, University of Tennessee & Oak Ridge National Laboratory
Satoshi Matsuoka, Tokyo Institute of Technology, Japan
Rob Schreiber, HP Labs, Palo Alto, CA
Arnold Rosenberg from University of Massachusetts, Amherst
Uzi Vishkin, University of Maryland

Speakers were asked to address what went right, what went wrong, what were the striking events and the big surprises which have arisen in the past 25 years. My thoughts about this panel session are included below and I encourage readers to watch the video for this panel discussion to formulate their own take-aways.

Some of the positive vibes from this panel included how the last 25 years have seen impressive gains in performance as a result of parallelism. LINPAC numbers have improved from 70 -80 flops on a single 1980’s vintage 6800 based processor on LINPAC 30 years ago, to 1.2 PetaFlops today - a 150 trillion fold increase. Advances during these same years have demonstrated the value of parallel computing to an audience much wider than the typical IPDPS audience and the need for parallel education is being noted by key panelists at the conference.

Rob Schreiber, a mathematician, gave a list of necessary ideas that historically had to be tested but which he contends were bad ideas from the past. Among these ideas were Amdahl's law, "weak scaling" AKA Gustafson-Baris Law, Automatic Parallelization via compilers, High Performance Fortran, RISC & VLIW architectures, external accelerators (GPGPU).

I disagree with Rob's contention that “weak scaling” supported by Gustafson-Baris was a bad idea. I think history has proven Gustafson-Baris right - the clear trend in computing has been to make simulations more real, more detailed, solve larger more complicated problems. Yes we all strive hard to do this in real time as well. Bill Dally from Stanford also took exception with "weak scaling". Dally said that people don't want a bigger version of "angry birds", the popular Smartphone app. Since most of our personal compute devices have many cores now days, he cited an example of a phone that has 70-80 cores (depending on how you define a core), he contends that we need to tackle “strong scaling”, making existing applications faster to make parallelism useful to users. His contention is that strong scaling is the big challenge going forward and he argues that we cannot continue to rest on weak scaling to come to our rescue going forward. Again, I disagree with him on this point. I think the ability to do new things, solve harder problems, to make apps behave in ever more real ways with greater resolution has been a clear historical trend and ultimately is what end users care about. My counter to Bill's "Angry Birds" argument is that I believe people don't care if MS Word runs any faster, but they do care about access to detailed medical imaging that might prevent invasive surgical procedures.

Bill did make what I thought was a excellent point: most parallel systems today are really serial or nearly serial processors bolted together through their IO channels and as a result communication has microsecond level latency that programmers have to contend with. This makes the programming parallel systems much harder because programmers now have four parallel programming challenges to deal with rather than simply three. The "easy" three are parallelism, locality, load balance. The tough challenge is programming around differing latency issues that are man-made artifacts. He pointed to examples of his own work at MIT years ago that demonstrated that short latency communication is possible at an architectural level (see his J Machine work).

I also agree with Dally’s premise that academia, even at his own institution at Stanford has not focused appropriately on parallel computing and the state has been "appalling". He argued that a single course on parallel computing was insufficient and cited an example of a typical algorithms course which still taught complexity theory as if Floating Operations were important! He says FLOPs are NOT important! What matters is data movement. This implies there is much to be done to revamp today's algorithms courses to make them useful for real applications on real architectures.

Rob's inclusion of external accelerators (think GPGPU) as a bad idea from the past may need some explanation. His argument rests on how difficult they have been to program in the past - his term is PITB - to program. He said they have historically always been faster than the CPU's of the day but have also been PITB to use. He did say, however, that when these accelerators have been integrated into the main CPU they became easier to program – case in point floating point accelerators.

The past 25 or so years in computing have been an exciting time and now new and lofty challenges are cropping up, such as the ever increasing impact of power consumption, how to minimize data movement and improve communication speed and lower latency, among others. Stay tuned for my review of the panelist views of the next 25 years.

Bob C

 I had not found any examples in web search of anyone using OpenMP to parallelize a game.  Turns out it was relatively easy to parallelize this game demo using OpenMP tasks with some signal handling.  The advantage is of using OpenMP , and my reason for wanting to give it a try, is the ability to incrementally parallelize a portion of the code and if you run into problems at run time you can comment a single line of code or not compile with the /OpenMP switch – this gets the developer back to the serial baseline, whenever this is needed.   This lets a developer test relatively quickly parallel strategies in code.  For example, I was able to test the effect of adding the Physics->update, AI->Update etc to the list of parallel tasks – this lead to race conditions so I commented out the two OpenMP pragmas and went about my subsequent investigations. But this is getting ahead of my story…

Undaunted at the lack of examples, I decided to try my hand at using OpenMP Tasks to try to parallelize the DestroyTheCastle Game demo that Intel engineers put together for GDC several years ago.  At first I stumbled around trying to figure out just how to parallelize it. I decided to take an approach similar to the way the Intel engineers has previously used Windows QueueUserWorkItem in the original game demo to queue up tasks using event handlers to coordinate when stages of work were completed and thus ready for rendering.

This approach essentially makes tasks out of the Physics, AI, and Particle calculates.  In the serial baseline of the code, these “tasks” are done one after the other in sequential order.  By using OpenMP tasks I was able to do these three tasks concurrently and achieve a nice speedup.

I was not all that sure OpenMP was even a sensible choice for parallelizing a game because games are inherently event driven with event handlers all over the place and so they feel rather unstructured.  OpenMP requires structured block of code to parallelize.  A parallel region must have only on entrance and one exit possible to be a valid parallel region and the compiler will complain otherwise.  So how do you make such an event based application “structured” for the purposes of OpenMP?  In this case I created the parallel region inside the WinMain routine which is found in ParallelDemo.cpp. The OpenMP parallel region starts near the top of WinMain and ends near the bottom of WinMain.  I then immediately placed a single region within the parallel region so that only a single thread really operated WinMain.   Well, you ask, how does that help?  Remember that the parallel region sets up a pool of threads, the single construct is a worksharing construct that allows only one thread operate the enclosing single region.  So what I have done by using this trick is really just create a pool of threads for me to use at other locations in the code, but meanwhile I did not affect the behavior of the WinMain sequence of instructions.

After building the above mods to with OpenMP and running the code to verify that the app still behaved similarly to the serial baseline, I went on to place OpenMP tasks at strategic points in the code.  The Version of ParallelDemo.cpp that contains the parallel/serial region trick is called ParallelDemoOpenMPSolutionActivity1.cpp. 

After adding OMP Task directives around calls to the Physics, AI, and Particle tick methods I realized that I needed a way to synchronize when the tasks were compete and thus ready for rendering.  I decided to use OMP Taskwait clauses at strategic locations in the code to ensure that all tasks were complete prior to rendering.  Turns out, due to the event based nature of the game, I had to sprinkle OMP Taskwait clauses at all points where the code could exit.  So I had to include taskwaits in the various event handlers such as MsgProc, KeyboardProc, etc.  Failing to do this caused the app to crash when doing such things as bringing up menus, switching in and out of multi-threaded mode, etc.

I saved this level of mods to ParallelDemoOpenMPSolutionActivity2.cpp.  It represents the fully OpenMP parallelized version of the code.  Unfortunately, I did not see any speed up at this point.  I had to go back and do a little tuning, mainly ridding myself of one call to taskwait in OnFrameMove and replacing it with some event handling routines built with RestEvent,SetEvent and WaitForSingleObject.  A little playing around with Intel® Parallel Studio Amplifier helped me identify that I was over synchronized and I decided to try the synchronization scheme used with the Windows threading QueueUserWorkItem approach, where some event handlers were used to indicate when tasks were completed. 

In the new approach, saved as ParallelDemoOpenMPSolutionActivity3.cpp, I created an array of event handlers named s_hTickDoneEvent.  There is an array element for each event I care about, Physics, AI, and Particles.  In this new approach, the event handlers are used to keep track of the state of each task.  The event for Physics is reset prior to executing the Physics->tick task and the event is set when the task is complete.  AI->tick and Particles->tick is handled in a similar fashion, each having event handlers reset prior to tick, the set immediately afterwards.

It turns out that a big performance gain is achieved by removing only one omp taskwait – the one at the top of FrameMove. Replacing it with calls to WaitForSingleObject, which waits for the associated event handler to become set, gave a nice sppedup. Due diligence then required in order to create and destroy the events and to reset them and set them around each of my three tasks.  When these steps are complete the code shows a decent speedup.

To evaluate my performance, I ran the demo loop by pressing the “B” key in the demo.  All frame rates were measured when the graphics were set to the maximum dimensions on my 22 inch screen. I recorded the minimum framerate and maximum frame rate but from a user experience perspective, minimum frame rates were what really made the demo feel fast or slow so I will restrict my metrics here to just minimum frame rates. My rough performance results on my Intel® Core™2 Quad CPU Q6600 @2.40GHz running Windows XP professional & using DirectX 9.0c are as follows:

11 FPS:    Serial baseline minimum frame rate
12 FPS:    OpenMP Tasks & Taskwaits
60 FPS:    OMP Task w Event signals
99 FPS:    Windows QueueUserWorkItem with Signal Handling

So while the original QueueUserWorkItem with Signal handling approach was the fastest threading methodology, the OMP Tasks & Taskswaits modified with a bit of signal handling was not far behind.  The advantage of the OMP method however, is that I could easily get back to my serial base version by just commenting out the #pragma omp statements or else just not compiling with the OpenMP switch.  The other advantage was that I was able to quickly try other parallel strategies quickly.  I was able to see the effect of adding Physics->Update & AI->Update  to the task list.  It will also afford me the ability to use data decomposition using OMP For at some point in future investigations.

A short powerpoint gives an overview of the Destroy The Caste demo and the OpenMP parallelism approach. This presentation as well as all the code and solution & project files for this example is accessible at http://software.intel.com/en-us/courseware/course/category.php?id=37.  Download it and see I there are other enhancements you can make to this code and if you use this in your class please post to my blog to let me know!

The activities put students in the place of procesor cores and had them perform tasks in parallel. These activities proved to be popular among many of the students at the camp, however, some of the more advanced students did express that they felt the exercsies could seem childish.

My personal observation is that these exercises laid an excellent foundation that was built upon later with actual computer lab activites using OpenMP and Threading Building Blocks.

The activities are best done in groups of 4 or 5 individuals but even two in a single group can.

Without further ado - here is my promised write up:

Thinking Parallel

These role playing activities are designed to get you start thinking in parallel. They will also expose you to some terminology & concepts that we will use throughout the rest of the boot-camp. Many of these exercises were inspired from Chapter two if James Reinders’ book “Intel Threading Building Blocks”.

Objectives
The objectives for the following five exercises are to:
1) Explore domain & task decomposition using a mailer example.
2) Learn about race conditions and two ways to mitigate them.
3) Learn what a critical section does
4) How a reduction can eliminate a race condition.

Activity 1 – Explore Domain Decomposition

In this activity, each member of your team or group will play the role of a processor core, or more accurately, the role of a thread executing code on a core. Your team will explore how to use domain decomposition to accomplish the job of folding, stuffing, sealing, addressing, stamping & mailing multiple envelopes.

Time Required
fifteen minutes

Objective
Use scrap paper, some empty envelopes, and a pencil to explore the concept of parallelism
through domain decomposition.

Materials
1) 16 envelopes per table of 4 to 5 “processors”
2) 32 colored post-it notes (16 to represent stamps, 16 to represent address labels)
3) Pens or pencils

Setup
1) Divvy up the 16 envelopes & colored post-its so that each process gets a roughly equal share
2) Each “processor” (think student) must read over and become familiar with the “code” or instructions she is to execute so that the “code” is committed to memory.
Here is your “code” of instructions – For Domain decomposition – each processor does the same task but uses different data (represented here by different addresses)
a) Fold scrap paper
b) Stuff paper into envelop
c) Pretend to seal envelope (so we can re-use them later)
d) Address an “address label” and fix it to the middle of the envelope
You may use these fictitious addresses if you cannot come up with 16 of your own:

e) Fix another post-it (representing a stamp) to the stamp area of the envelope
f) Place envelope in table area designated “the mail box”

Monitor Time for completion of mailer exercise
1) Have someone on the team write down the time just prior to saying go
2) Each “processor” should complete his assigned set of envelopes as quickly as possible.
3) Record the time to complete the assigned mailer job. Time: _____________________
4) Record any observations about the nature of the tasks you do – which ones take longest, which one are fast? Were any processors idle for periods of time?

Activity 2 – Explore Task Decomposition

In this activity, your team will explore how to use a task decomposition to accomplish the job of folding, stuffing, sealing, addressing, stamping & mailing multiple envelopes.

Time Required
fifteen minutes

Objective
Use scrap paper, some empty envelopes, and a pencil to explore the concept of parallelism
through task decomposition.

Materials
1) 16 envelopes per table of 4 to 5 “processors”
2) 32 colored post-it notes (16 to represent stamps, 16 to represent address labels)
3) Pens or pencils

Setup
1) Divvy up the 16 envelopes & colored post-its so that each process gets a roughly equal share
a) Each “processor” will agree with team ahead of time which task or tasks he/she is committed
to accomplishing. Perhaps, one processor is assigned the tasks of Folding, Stuffing, Pretend
Sealing all the envelopes.
b) Another processor, or perhaps even two, are assigned the task of addressing the envelopes
Use same addresses as before
c) Another processor is assigned the role of stamping and mailing the envelopes

Monitor Time for completion of mailer exercise
1) Have someone on the team write down the time just prior to saying go
2) Each “processor” should complete his assigned tasks as quickly as possible.
3) Record the time to complete the assigned mailer job. Time: _____________________
4) Record any observations about the nature of the tasks you do – which ones take longest, which one are fast? Were any processors idle for periods of time?

Activity 3 –Vector Addition exposes race conditions

In this activity, your team will explore how to use a domain decomposition to accomplish the job of (mis)adding a set of numbers which we will call a vector. The activity exposes the problem that occurs when writes to a shared memory variable are not protected by a synchronization construct.

Time Required
fifteen minutes

Objective
Use some index cards, and pencils to explore the concept of a race condition.

Materials
1) 16 numbered index cards.
2) One index card labeled “Shared Sum”
3) 16 extra index cards are labeled “local memory”
4) Pencils

Setup
1) The 16 numbered index cards represent a vector of length 16 elements. These are divvied up roughly equally among all 4 to 5 “processors”
2) One extra index card is labeled “Shared Sum” and has the value 0 written on it and is placed in the middle of the table accessible to all processors
3) Several extra index cards are labeled “local memory” and are given to each processor as a scratch pad to add number on.

Execution
1) This is a domain decomposition exercise, where each processor “reads” the value of the “shared sum” and writes a new value to this shared sum – ignoring all the other processors previously written values – this is called a race condition.
Each processor should do these steps as quickly as possible:
a) “read” the value of the “shared sum” and writes that number on your own scratch pad.
b) add one of your “vector” card’s values to the sum on your scratch pad.
c) Immediately cross off the current value on the “shared sum” card and write your own value on the card (probably stomping over someone else’s value).
d) Repeat steps 5a – 5c until you are out of index cards
2) Compare the final value written on the “shared sum” with the known total (46)
3) Did your team compute the correct grand total for the vector sum?

Activity 4 –Vector Addition fixed with critical section

In this activity, your team will explore how a critical section can be used to guarantee that access to a shared memory region are protected – in other words, that writes to a shared variable are done in an orderly and synchronized fashion. It will also expose the performance penalty that can be taken as a result of critical sections.

Time Required
Fifteen minutes

Objective
Use some index cards, a magic marker & pencils to explore the concept of a critical section

Materials
1) 16 numbered index cards (we call it our vector)
2) 1 index card labeled “Shared Sum”
3) 16 extra index cards are labeled “local memory”
4) Magic marker
5) Pencils

Setup
1) The 16 numbered index cards represent a vector of length 16 elements. These are divvied up roughly equally among all 4 to 5 “processors”
2) One extra index cards labeled “Shared Sum” and has the value 0 written on it and is placed in the middle of the table accessible to all processors.
3) Several extra index cards are labeled “local memory” and are given to each processor as a scratch pad to add number on.
4) A Magic maker, known as “critical section”, is placed on the table next to the “shared sum”

Execution
1) We are now trying to synchronize access to shared memory by implementing a critical section. Our goal is to get rid of the race condition we encountered earlier.
2) New rule: “Each processor can only use the magic marker, named critical section, to write values to the “shared sum” index card. And – No processor can do any computations without first acquiring the magic marker, called critical section. As soon as a processor writes a new value to “shared sum” the processor should expeditiously return the capped critical section to the middle of the table”.
3) Each processor should do these steps as quickly as possible:
a) Acquire the critical section! If you failed to acquire the critical section you must wait for the marker to be placed back in the middle of the table.
b) Immediately cross off the current value on the “shared sum” card
c) Add the value of one of your index cards to the “shared sum” use a scratch pad if needed
d) Write the new value for sum on the globally shared “shared sum” card
e) Return the cap to the marker
f) Return the marker to the middle of the table
g) Repeat steps 5a(i) – 5a(v) until you are out of index cards
4) Compare the final value written on the “shared sum” with the known total (46)
5) Did your team compute the correct grand total for the vector sum?
6) What did you observe about how much time you spent idling versus time spent writing or calculating?

Activity 5 – Vector Addition fixed with reduction

In this activity, your team will explore how a reduction (or a partial sums approach) can be used to guarantee that access to a shared memory region are protected – in other words, that writes to a shared variable are done in an orderly and synchronized fashion. It will also demonstrate the benefit of replacing a critical section with a reduction wherever possible.

Time Required
Fifteen minutes

Objective
Use some index cards, & pencils to explore the concept of a critical section

Materials
1) 16 numbered index cards (we call it our vector)
2) 1 index card labeled “Shared Sum”
3) 4 index card labeled “Partial Sum”
4) 16 extra index cards are labeled “local memory”
5) Pencils

Setup
1) The 16 numbered index cards represent a vector of length 16 elements. These are divvied up roughly equally among all 4 to 5 “processors”
2) One extra index cards labeled “Shared Sum” and has the value 0 written on it and is placed in the middle of the table accessible to all processors.
3) The remaining “Partial sum” cards are divvied up among the processors
4) Several extra index cards are labeled “local memory” and are given to each processor as a scratch pad to add number on.

Execution
We are now trying to synchronize access to shared memory by implementing a reduction – which amounts to a collection of partial sums computed by each processor, followed by a grand total computed by a master thread. Our goal is to get rid of the race condition we encountered earlier, and do the parallel tasks in a more efficient manner.

Every processor will add up his/her own partial sum that represents the total of all the vector
elements assigned to him/her.

One processor will also be named to execute the “master thread” that adds up all the partial sum cards to create a grand total , that the master thread writes this grand total to the “shared sum” card.

1) Each processor should:
a) Add the values from all their assigned vector cards
b) Write the value to a “partial Sum” card
c) Give the “Partial Sum” card to the Processor who will execute the master thread
2) The Master Thread only should:
a) Compute his own partial sum
b) Wait for all other partial sums to arrive
c) Compute the grand total for all partial sums
d) Write the grand total on the “Shared Sum” card

3) Did your team compute the correct grand total for the vector sum?
What did you observe about how much time you spent idling versus time spent writing or calculating?

4) How effective was the reduction strategy at computing the sum in parallel versus the other methods tried?

Review Questions

Question 1: Describe a race condition
Question 2: What does a critical section do?

Warning - new metaphor coming…

We are about to embark on a journey. A journey to the future. A future defined by the many-core era.

To take us on the journey – we need fuel. The fuel mix for this journey consists of four ingredients: multi-core hardware, parallelism training, great instructors and the fertile minds of bright high school students. We are about to light the mix off in a controlled burn next week (July 21-23) at the campus of Brooklyn Tech HS. A couple dozen HS students and faculty will participate in this hands-on parallel programming training event. We will be laying out the challenge to begin thinking in parallel and arming the students with three patterns that can be used to think about parallel problems. Then we will arm them with a couple of methods to implement parallel software on many-core HW. We will discuss some of the challenges unique to parallel programming and ways to address these challenges using SW tools & new ways of thinking. Then we will show them just of few of the possibilities – a few compelling SW demos that show how “real” a virtual world powered by multi-core systems can be. Along the way we hope to arm them knowledge of how to leverage many-core systems that are headed our way. Hopefully we will refine our mixture as we learn from these students & faculty how to better equip young minds.

I guess I want to extend James Reinder’s point and say that today high schools & colleges are either teaching “the history of programming” or they are teaching parallel programming. I am excited to work with Brooklyn Technical High school and their principal, Randy Asher, who are doing something about teaching to the FUTURE.  I am also proud to work with folks like Jeff Birnbaum (Bank of America) who was the inspiration & prime motivation for making this project happen.

Stand back, put your safety goggles on – we’re about to light the mixture.

As I scan the horizon lately, I see an interesting pattern has emerged.  Tools such as Threading Building Blocks, the new OpenMP 3.0 spec and the Executor interface from the Java.util.concurrent package, to name a few, are providing ways for developers to specify tasks to a library or runtime and allowing the library to manage the assignment of execution agents (threads) to these tasks.  The central concept now: Tasks!

What are tasks?  Tasks are logical units of work.  A task may be a function call, it may be an iteration of a loop, or it may be a block of code encased in curly braces.  Tasks are the job assignments, in code, the developer wants to accomplish.

The trick to parallel programming is finding as many independent tasks within an application as possible and then in finding as many dependent tasks as possible that can either be ordered or provided with some synchronization constructs that effectively make even these tasks conditionally independent.

So training for parallel programming going forward, I would argue, should focus more and more on tasks and less on threads; more on teaching developers how to identify independent tasks, and less on how specific explicit threading implementations. I believe we are reaching the point where we can grapple with the higher level abstraction of tasks and have some confidence that I can rely on a library or package to handle the thread assignment and thread management activities automatically.

Does this mean I can forget about Threads?  No.  At this point, knowledge of threads is still required to know how to deal with tasks that are not completely independent.  A basic knowledge of threads, in so far as knowing that threads can run in any arbitrary order, is at least required to understand the possible side effects to threading such as race conditions or dead lock conditions.  Proper synchronization of threads to data is key to eliminating these traps and synchronization on a shared memory system requires a knowledge of some threading API to create mutex or critical sections, or what-have-you.

At least, that’s my take.  What is yours?

My Challenge
These are the questions I am grappling with as I lay out a plan for a pilot project for parallelism at the high school level with a small group of very savvy High school programmers.

First of all, while it’s fine to start off the camp in a purely conceptual way – talking about ideas & concepts for parallelism and even walking through examples of parallelism we see every day in real life – waiting in a line at a store and wishing for more checkers, enlisting the help of friends to paint a room – at some point we have to get around to programming.  So what language will I choose?  Some high school students have programmed in Java, some in C/C++, and some in Java like languages like Alice from Carnegie Mellon University – so what do I choose and why?

I have chosen to teach the camp using C/C++.  The reason for this choice is that there are some excellent diagnostic tools to help diagnose threading issues for C/C++. I feel strongly in having solid analysis tools available for students.  Students should know the rudiments of debugging and have access to a good debugger when they first learn to program because it gives them a feel for the dynamics of a program.  Similarly, when learning to program using parallel techniques, it is essential that a good set of parallel diagnostic tools are available.  Students, especially, need tools to help them spot and avoid race conditions and deadlock conditions and “printf” just are NOT the answer.

Also – for students familiar only in C# or Java, the syntax differences are few and the C/C++ code examples are readily understood by students whose only background are C# or Java.

What is my approach?  First let me say that it is not written in stone yet.  I have based the first two days of the bootcamp around some excellent material provided to us by Professor Michael Quinn which I regard as an introduction to parallel programming. The third day is based on materials provided by Intel engineers and cover OpenMP, Intel® Threading Building Blocks, Intel® Thread Checker & Intel® Thread Profiler.  These materials will provide students a couple of tangible ways to implement parallelism in a C/C++ application. The last day is tentatively earmarked to teach students how to approach parallelizing a demo game written in C/C++. Below is how my planning is shaping up so far.Bootcamp  - Day 1:
Parallel Puzzle de Jour
Use puzzles as an introduction to the students to give them some real-world background in some of the problems that CE majors typically are called on to solve.

Introducing Parallel Programming
Here I will define parallel computing, explain why parallel computing is becoming mainstream and explain why explicit parallel programming is necessary.

Recognizing Potential Parallelism
This is where students recall opportunities for parallelism in the real world

-        working at a restaurant,

-        adding more checkers to alleviate long lines while shopping

-        ways of tackling class assignments in parallel sub-teams

Do a “students as threads” activity to carry out a parallel computation (possibilities: compute a parallel sum, perform a sorting operation, find a maximum value of an array of data)

Identify opportunities for parallelism in code segments and applications

Shared Memory and Threads
Describe the shared-memory model of parallel programming. Explore the differences between the fork/join and the general threads models. Demonstrate how to implement domain and functional decompositions using threads. Investigate whether a variable in a multithreaded program should be shared or private

Short Introduction to OpenMP AKA Implementing Domain Decompositions
Identify “for loops” that can be executed in parallel. Identify blocks of code suitable for parallel execution. Add OpenMP pragmas to programs that have suitable blocks of code or “for loops”.  Explore the new OpenMP Task directive.       Demonstrate the proper use of the “single” and “nowait” directives

Bootcamp  - Day 2:
Parallel Puzzle de Jour
Review any solutions or ideas for tackling yesterdays puzzle and introduce a new puzzle to be solved by the end week.

Confronting Race Conditions

Give practical examples of ways that threads may contend for shared resources. Write an OpenMP program that contains a reduction. Describe what race conditions are and explain how to eliminate them. Define deadlock and explain ways to prevent it.

Implementing Task Decompositions
Describe how threads can be used to implement parallel programs using task decomposition. Implement a task decomposition based on work pools.   Implement a task decomposition in which different threads execute different functions. Examine two case studies: 1) The N Queens Problem, 2) Fancy Web Browser

Improving Parallel Performance
Give reasons why one sequential algorithm may more suitable than another for parallelization. Use loop fusion, loop fission, and loop inversion to create or improve opportunities for parallel execution. Explain the pros and cons of static versus dynamic loop scheduling. Explain Load Balancing. Explain Locality. Explain why it can be difficult both to optimize load balancing and maximize locality

Bootcamp  - Day 3:
Parallel Puzzle de Jour
Review any solutions or ideas for tackling yesterdays puzzle and introduce a new puzzle to be solved by the end week.

Introduction to Threading Building Blocks
Give an overview of Threading Building Blocks. Describe Generic Parallel Algorithms such as parallel_for, parallel_reduce, parallel_sort. Explain theTask Scheduler. Discuss Generic Highly Concurrent Containers. Explore Scalable Memory Allocation. Discuss Low-level Synchronization Primitives

Correcting Threading Errors with Intel® Thread Checker
Discuss the Intel® Thread Checker. Examine race conditions. Exlore the Intel Thread Checker.  Discuss some types of threading errors. Examine library thread-safety

Tuning Threading Code with Intel® Thread Profiler
Discuss Intel® Thread Profiler features. Define Critical Path Analysis. Examine Thread Profiler “data views”. Review common performance issues of multithreaded applications. Examine Load imbalance. Examine Synchronization contention. Describe general optimizations to gain better performance 

Bootcamp  - Day 4:
Parallel Puzzle de Jour
Review any solutions or ideas for tackling yesterdays puzzle and introduce a new puzzle to be solved by the end week.

Threading Games for Performance 
Case Studies - Destroy the Castle Demo game. Give an overview of Multi-Threading in Games. Introduce the Destroy the Castle Demo. Examine Functional Decomposition for this game. Examine Data Decomposition.

Parallel Puzzle Review of Solutions
Student lead discussion of approaches they took towards the parallel puzzle de jour.   

My Challenge to You
So, you’ve seen my proposal.  You know my target audience. You may not agree with the selection of topics, the selection of language, or perhaps the scope or the sequence. So, tell me, how would you design a 4 day bootcamp for technically savvy high school students?

While our current content deployment mechanism works, I fear that it may be more difficult than it needs to be in order to access our content. In most cases, our current model has a listing of modules with course description and a link to download a ZIP of our content, which includes powerpoint slides, student lab manuals, and ZIP’s of the various labs themselves. In the spirit of trying to find a more suitable delivery mode I have explored a number of online learning sites and I’d like to get your take on the pros and cons of these sites in comparison to what we currently offer.

The two sites I am looking into currently as roll models are …drumroll…

1)       Wikiversity (http://en.wikiversity.org/wiki/Wikiversity:Main_Page) and

2)       MIT Opencoursware (http://ocw.mit.edu/OcwWeb/web/home/home/index.htm)

I don’t have enough time in tonight’s blog to analyze both sites – so I will cover one tonight, Wikiversity, and I promise to do the other one next blog post.

The first site I’d like to consider as a potential model for future ISC delivery is…

http://en.wikiversity.org/wiki/Portal:Computer_Science. As a newbie member of this portal – look me up – I’m zmadscientist – I thought this approach to presenting lessons was pretty intuitive.  The lessons tend to be short, byte sized chunks.  They tend to be more verbose and text based and not so visually oriented as my home turf where we use a lot of powerpoint with punchy bulleted concepts. 

I looked up a several programming related topics to get a feel for the layout.  The two topics I looked up were Parallel Programming (doesn’t exist),  Threading (doesn’t exist), Parallel Computing, C++ programming with the  Alice Programming language.  My intent was to get a gut level feel for the efficacy of the lessons and delivery mode.

So to start - what I like about wikiversity is the simple layout and instant interaction with the lessons.  This is a wiki – so the layout is not consistent across all topics – but at least the C++ topic looked well organized.  And in one click I could get to a specific lesson – nice!

The layout for C++ is something like this:

1)       tabs across the top – resource tab laying out bulk of the content, discussion tab to get community feedback, then an edit and history tab that I am not as much into

2)       On the resource tab we see:

a.       Course title

b.       Course description, background discussion

c.       Pre-requisites

d.       Pros & Cons

e.       Lessons (hyperlinks to a wikiversity page specific to that one lesson)

f.         Enrolled – showing people registered who are interested in the topic

So kudos for ease of use and getting to the lessons!

But what about dynamic content? Content like showing how a data race can develop with two threads trying to access a shared variable.  Can that be done effectively in a wiki format?  I’m not convinced.

And what about the size of each lesson.  The C++ example, hello world, takes roughly two typed pages to explain.  This felt very toyish and rudimentary to me but maybe that’s appropriate for lesson 1  It still feels very spoon fed to me. Is this really suitable for topics like Threading Building Blocks, Win32 threads, OpenMP 3.0, or software tools with a load of graphic content to them like VTune Analyzer or Thread Checker?  We currently have over 4 hours of materials ~ 80 foils worth of compressed bulleted content on VTune analyzer alone. I can see that ballooning into a  hundred pages if we took the same approach – and that’s just VTune Analyzer.  I suppose this could be cut into a few tens of smaller lessons each maybe 10 pages long - but is that the right direction to take?

I suppose that screen shots can be embedded (we do that in powerpoint now) but I can’t find a simple way to animate graphics here – Well I suppose we could turn everything into flash tutorials but then its not really well suited to a wiki format then is it? And Flash seems too synthetic and constrained for the kinds of materials we currently offer.  

More advanced topics like parallel computing are described only at the highest level and no lessons are currently available – see http://en.wikiversity.org/wiki/Topic:Parallel_computing – so its hard to completely envision how ISC content could play into a wikiversity like model

Right now my take is that wikiversity offers an easier way to access content than the current ISC model – but it seems better suited to introductory materials like Programming with Alice and beginning C++.

So, what’s your take? Should ISC morph its online content area to be more in the image of wikiversity? 

Give me some feedback – how can we better server you? Is a different delivery modality even the answer? It would be a huge departure from what we are doing now - and would takes a bit of work to retool.  Is it worth it?

Next time – I want to take a harder look at how MIT offers content thru their OpenCourseware site.  Some of their material is phenomenal! – Look up Classical Mechanics (course 8-01) by Walter Lewin or Linear Algebra (course 18-06) by Glibert Strang! I’ve downloaded each of these to my ipod and have been watching them repeatedly.   

I asked Dr Dennis (Prf Emeritus CS at MIT) his thoughts on what should be taught to undergrads to prepare them for a many core future. This was a lunchtable conversation and not a true curriculum planning session - but none the less - Dr Denis did not hesitate to mention functional languages as one of the first things that should be taught. I don't think he was implying that a functional language is the magic bullet or one size fits all solution to bringing new developers to the discipline.

The reasons he articulted for teaching a functional language are that:
1) it is a model for parallel prgramming that avoids the sunchroonization hazards associated with threading - data races etc.
2) version of parallel languages are already being taught in many schools already so there s a low barrier to entry
3) Examples of functional languages can already be found in industry

I would argue that there will still be a need to teach students about threading (but not with as high a priority). If you teach them about threading, you have to teach them about the associated hazards. This does not contradict that we should also teach them a functional language.

On other fronts here at IPDPS I talked to Keshav Pingali from the University of Texas, and Vivek Sarkar from Rice University who were panelists here Wednesday night. These panelists discussed how the current parallel computation community could pass their learnings on to a new generation of develpoers just starting out in multicore. After the panel discussion, Michael Wrinn & I were able to get their take on essentially the same question I asked of Dr Dennis. They indicated that there still is some value in teaching functional programming to the new crop of developers. Keshav in particular indicated that his early exposure to functional languages has influenced his coding style in positive ways - years later. They acknowledged that some implentations of functional languages have been poor performers on sequential machines in the past and so they have not really caught on in industry (Erlang is the excetion to this statement) and also they cited some difficulties with cache locality & dealing with multidmensional arrays from a developers perspective. However, they also indicated that several groups have been adding extensions to these lanuages, I think Haskell was mentioned, to allow for improved handling of arrays and to address locaility issues.

So here are my musings after havng these discussions. Warning controvesial road ahead - use caution when entering - Here's a controversial perspective on appropriateness of functional languages as we move into many core land. Maybe the locaility issues that caused functional languages to be discounted wont be so significant in a time when we are utilizing hundreds of cores. Why? In sequential programming days and in early days of multicore - 2 cores could possibily give you a 2X speedup. But the tax we pay for poor cache locality might be hypothetically ~10X - the number thrown around here in our conversations with these disinguished professors from Texas. So any language that could gain you 2X by parallelism - but lose you 10X thru poor locality probably would die a natural death. BUT - improve cache locality fo these languages and apply to many more cores. Suppose in future we have 100 cores and that compilers for the functional languages get a second look and get needed optimizations so that we reduce cache locality issues to be a 50% penalty rather than 10X (50% penalty means we run at 1.5X speedup). Now assume that we approach 100X due to parallelism but pay 1.5X tax. Thats a net gain ~66X speedup. Compiler writers might be persuaded to optimize a functional language if there was a decent pay off. 66X might do it. If the industry had frozen in a past instant of time at only 2 cores and if compiler writers at that time thought that they might be able to reduce locality penalty to 50% would it have been a worthwhile endeavor? 2X gain/1.5X loss 1.3X net - that a 30% gain in performance - not so clear that compiler writers would be enthusiastic to do all the work required because the potential pay off would not be that large. But maybe for 66X gain thay may consider it.

Caveat - I know I am assuming no overhead here and we likley wont scale perfectly or anywhere near it at 100 cores etc. But if there are no synchronization hazards - and we reduce the locality penalties maybe these things will scale better than we imagine - does anyone have a quantitaive way to address this? Quick - can someone whip out an equation from Hannesy & Patterson?

My point is that perhaps we should keep an open mind ot the possiblity of functional languages and hope that the "economy scale" and clever compiler writers might be able to bring a solution. The payoff ultimately would be fundamentally easier approaches to parallelism.

Who knows?

bobc

I had the privilege of discussing the future of parallel programming with a number of distinguished luminaries in parallel computing! The topics discussed in side hall discussions and informal lunch table chats were varied and dynamic. Given that this is the first day of the conference for the broader set of technical sessions (the NSF track actually started on Sunday) I have no doubt that there will be more intersting discussions throughout the rest of the week. Let me start my recap of the conference with one lunchtime discussion I had on day one.

Today I had the privilege of talking to Jack Dennis, Professor Emeritus of Computer Science and Engineering at MIT. Over cold cut sandwiches and iced-tea, we had two very interesting discussions. The first regards Professor Dennis’ Fresh Breeze Project at MIT and the second regards his view of how to prepare undergraduate students for the many core world we are now entering.

Fresh Breeze is multi-core chip design which supports composable parallel programming. Composable means that parallel programs should be able to be used as components in still larger parallel programs without a lot of fuss and without a detailed knowledge of the implementation details of the smaller parallel program. Composable in this context implies that resources, such as processor allocation & memory, should be flexible and able to be reassigned according to the current needs of computations. This project adheres to six important principles for supporting modular software construction with a view towards composability of parallel programs:

1. Information Hiding Principle: The user of a module must not need to know anything about the internal mechanism of the module to make effective use of it.
2. Invariant Behavior Principle: The functional behavior of a module must be independent of the site or context from which it is invoked.
3. Data Generality Principle: The interface to a module must be capable of passing any data object an application may require.
4. Secure Arguments Principle: The interface to a module must not allow side-effects on arguments supplied to the interface.
5. Recursive Construction Principle: A program constructed from modules must be usable as a component in building larger programs or modules.
6. System Resource Management Principle: Resource management for program modules must be performed by the computer system and not by individual program modules.

Professor Dennis holds that his new multi-core design would be key to building modular parallel programs. For more details – see Prof Dennis’ website - http://csg.csail.mit.edu/Users/dennis/.

The second topic we bantered around the table was how academia could prepare undergraduate CS students for the burgeoning parallel computational world that has been thrust upon them (and us). On this topic – I asked Professor Dennis this question – "If there were a handful of changes that academia could make to prepare undergraduates for this many core transition – what would they be"? This was his response:

1. Teach undergraduates a functional language – yes functional as in LISP – which avoids synchronization hazards. MIT’s been teaching LISP for years. Another choice might be Erlang as it side steps synchronization hazards, is a simple language to learn and has been designed for high performance use in the communications industry
2. Teach undergraduates MPI as in Message passing Interface. This paradigm has been used successfully in large scale parallel programs already.
3. Give them a blended HW/SW computer architecture course, including multicore arhcitecture – expose them to cache architecture so they understand performance
4. Expose them to hazards like synchronization hazards and data races so they can avoid these hazards when they implement parallel designs
5. Revisit object oriented programming methodology, which is great for sequential programs, but is not well suited for structured parallel programming. A program can easily be written which follows OOP but can still exhibit a data race.
6. Teach students the concepts of atomicity, determinacy, and the difference between them. Atomicity is the concept that all or none of a transaction must be completed. Determinacy deals with achieving a correct result regardless of the order in which threads execute. Atomicity does not imply determinacy.

Professor Dennis – thanks for lending me your sage advice on how to steer our curriculum efforts!

So now I ask YOU!

If there were three (or five) changes that academia could make to prepare undergraduates for this many core transition – what would they be? What is YOUR response?

Bob C