This function must be overlapped to allow showing its own Help in a user application:
class CSampleApp : public CWinApp {
...
virtual void WinHelp(DWORD dwData, UINT nCmd);
};

Everything went alright until 64-bit systems appeared. And MFC developers had to change the interface of WinHelp function (and some other functions) in this way:
class CWinApp {
...
virtual void WinHelp(DWORD_PTR dwData, UINT nCmd);
};

In 32-bit mode DWORD_PTR and DWORD types coincided but in 64-bit one... Of course developers of user applications, too, had to change the type to DWORD_PTR for correct overload but the compiler did not inform about this and the error appeared only at the stage of testing when Help system began to behave "mysteriously". To learn the details I refer you to the article mentioned above.

What made me recall this error? The fact that now, in the end of 2009, this error is still present in the code of real applications. You doubt?

There is an excellent component library BCGControlBar. You must have heard about it because the components by BCGSoft Ltd are included into Microsoft Visual Studio 2008 Feature Pack. So, if you download the demo-version of this library, install it and search the word "WinHelp" through .h-files... you will see that everywhere this function is supposedly overlapped, DWORD parameter is used instead of DWORD_PTR. And this means that Help system in these classes will behave incorrectly on a 64-bit system.

Can it really be true that this error is still in the code of such a popular library? I think the point is that the company's clients have access to source codes of this library and they can always introduce some corrections into it. Besides, WinHelp function is used very rarely nowadays. HtmlHelp is much more popular. And it does have the right parameter DWORD_PTR in BCGControlBar. But the fact remains: there is an error in a real code and the compiler will not detect it.

P.S. Analyzer PVS-Studio (Viva64) has been able to detect such errors from its very appearance, and Help system includes a detailed example (see description of error V301).

size_t nCount = 10;
int **poinerArray = (int **)malloc(nCount * 4);

The code is incorrect but in a 32-bit system it will work correctly. The error can occur when adapting the program to a different software/hardware environment. It has become very urgent and important to detect such a code because of mass migration of software on 64-bit systems. Changing of the sizes of some base types makes a code like this very dangerous. Viva64 analyzer included into PVS-Studio will show a warning about using magic constant “4″ on the code given above and an error will be detected when viewing the diagnostic warnings. But a code can be more complicated:

#define N_COUNT 100
#define POINTER_SIZE 4
#define NSIZE (N_COUNT * POINTER_SIZE)

int **pArray = (int **)malloc(NSIZE);

It is more difficult to diagnose an error in such a code written in C style with the use of #define. Although the code contains constant 4 defined by a macro, Viva64 analyzer is deliberately set so as to avoid showing warnings on such constructions. The analyzer ignores magic constants defined by macros (#define) due to two reasons. First, if a programmer defines constants through macros, he is likely to know what he is doing and a false response is very likely to occur. Second, if we react to constants which are dangerous from the viewpoint of a constant’s 64-bit mode (4, 8, 32 etc) we will have too many false responses relating to using Windows API. Let’s consider a harmless code as an example:

MessageBox("Are you sure ?",
           "Some question",
           MB_YESNO | MB_ICONQUESTION);

If we analyze the magic numbers hidden behind MB_YESNO and MB_ICONQUESTION macros there should be two warnings on using magic constants 4 and 32 on this line. Of course, it is too great a level of false responses. When analyzing malloc() function we can print all information about all dangerous magic constants without paying attention if it is a macro or not. But that is not enough anyway for the next case:

int **pArray = (int **)malloc(400);

If we go further and consider any number used in the expression for malloc() function unsafe it will cause false responses on a correct code:

int **pArray = (int **)malloc(400 * sizeof(int *));

On examining the situation, we have decided to introduce a new rule to verify applications whose result is transferred into malloc() function. At present, this rule reads as follows:

You should consider unsafe using numeric literals in the expression transferred into malloc() function. Exceptions:
1) The expression contains sizeof() operator
2) All the numeric literals divide by four with a remainder

Thanks to this rule we can warn about an error in the following code:
1) The first example:

void *p = malloc(nCount * 4);

2) The second example:

#define N_COUNT 100
#define POINTER_SIZE 4
#define NSIZE (N_COUNT * POINTER_SIZE)
int **pArray = (int **)malloc(NSIZE);

And also avoid showing a false warning on the code like:
1) The first example:

void *p = malloc(sizeof(double) * 4);

2) The second example:

#define N_COUNT 100
#define POINTER_SIZE sizeof(int *)
#define NSIZE (N_COUNT * POINTER_SIZE)
int **pArray = (int **)malloc(NSIZE);

This new diagnostic rule is most likely to appear in the next version of PVS-Studio 3.30. Let’s now consider another situation also relating to malloc() function and incorrect suggestion about data alignment. It is not quite relative to magic constants but the problem is similar. Let’s consider an example of code:

struct MyBigStruct {
  unsigned m_numberOfPointers;
  void *m_Pointers[1];
};
unsigned n = 10000;
void *ptr = malloc(sizeof(unsigned) +
                   n * sizeof(void *));

Although this code does not use magic numbers and the size of the types is defined by sizeof() the code is still incorrect. It does not take into account changing of the data alignment method different for 32-bit and 64-bit systems. The following code will be correct:

void *ptr = malloc(
  offsetof(MyBigStruct, m_Pointers) +
  n * sizeof(void *));

To warn the user about a possible error we are planning to introduce one more rule:

You should consider unsafe using more than one sizeof() operator in the expression transferred into malloc function. Perhaps, changing of alignment is not considered when calculating the structure’s size. With that, the parts of an expression split by the comparison or division operator are considered independently.

In some cases this rule will cause false responses but such places must be checked thoroughly anyway.
The dangerous expressions with magic constants described above are topical not only for malloc() function but for a class of such functions as fread, fwrite etc. But these functions must be studied separately and we will perform their analysis later when diagnosis relating to malloc() function is completely worked out.

I'm presently attending the Microsoft PDC 2009 conference and I am today in the Patterns of Parallel Programming workshop.

It appeared that the workshop was being recorded and so I sent an e-mail to some of the PDC 2009 organizers and can confirm that the Patterns of Parallel Programming workshop recording will be available to all attendees.

Richard Ciapala, Ade Miller, Herb Sutter, and Stephen Toub presented an excellent session on where we are with the parallelism today and where the Microsoft platform can take you in the parallel future.

Combining these capabilities with the Eclipse RCP based fully GUI driven Intel(R) JTAG Debugger and the whole Intel(R) Embedded Software Development Tool Suite available at http://www.intel.com/software/products/atomtools delivers a concise yet complete solution for Linux* hosted Intel(R) Atom(TM) processor targeted system development.

Please feel free to check it out :-)

First, let's begin with saying that any code written in C++ is incorrect by itself. Only that code will be correct which consists of the empty function main, yet I'm not sure about it. It is impossible to write an ideal correct program in C/C++. For you should consider that the program should work on a 12-, 16-, 32-, 64-, ...-bit system. The program, if possible, shouldn't allocate memory dynamically because somewhere it is missing. Also, it shouldn't use functions like scanf for you may need to place the program into a controller where there is no input device. The program mustn't use type conversions. Any type conversion is a potential error on some platform. And perhaps it is better to write the program with the help of trigraphs - you never know... :)

Well, I mean that there are no ideally correct programs in C/C++. You can seek to create such a program but you will never create it. In reality, when writing programs an admissible level of correctness and supposition about the execution environment is chosen and the program is written within the framework of this model.

So, any code is incorrect by itself from the viewpoint of an ideal programmer with golden hands living in vacuum. But we can suppose that a particular code be correct in some particular conditions. When the conditions (the environment) change the code may become incorrect. In what way it becomes incorrect depends on the external changes. Search of errors occurring when the execution environment changes can be arranged in a group and successfully diagnosed, while the approach "everything in the program is incorrect" is irrational.

Let's consider an example. We have a program to port into a controller which won't have a console. The program has some number of cout, cin, printf, scanf. We should find and "deactivate" these functions. Suppose that input be performed through the ports connected to some handle on the device's case. There is no sense in saying that the code is bad, the programmer who wrote it is bad only because he hadn't foreseen that there can be no console and one cannot disable all these sections by one pressure. It won't help us. And there is no sense in trying to perform an ideal refactoring to create an ideal program. We should only find and fix the necessary fragments. One can invent a static analyzer of "input-output issues in controllers"-diagnosis kind. And it will be helpful! But, honestly, all this is due to imperfect code of course :-)

The example above is exaggerated but I just want to show that when one is writing code one cannot foresee everything. One doesn't know that in five years this code will be placed into a controller, ported on a 64-bit system or adapted to a submarine. It is rather difficult to foresee some things.

Programmers have and maintain that code which they have. It can contain a lot of magic numbers, THOUSANDS of expressions where signed and unsigned types are used together, where many warnings may be disabled because one has to use LARGE old third-party libraries. And no one will bother to perform total refactoring of such projects to make them more beautiful, portable etc. And if one insists on this - this person should be fired. :) In reality, you should solve real tasks. You should add new functionality, organize maintenance on existing systems. If necessary, you should port the code on 64-bits. But when you port the code on a 64-bit system, it is this task that will be solved and not the task of how to make the code maximum portable. And here we face the practical task of detecting particular magic numbers (but not all of them), unsafe expressions with signed and unsigned types (but not all of them).

My position may seem wrong to many people as if I'm urging to write bad code and then use various crutches (which I sell myself) to fix it in some places. I am simply a practitioner. And also I call many things by their names. :)

Mostly, program code is BAD. And it works more or less well because it is lucky. Unfortunately, programmers are persistent in not admitting it. Any "code-shaking" (changing of the compiler, execution environment etc) reveals a layer of particular types of errors. I understand that there are no "64-bit" errors. There are just errors in code. They are always present in code. But some errors will occur on a 64-bit system. I tell developers about these errors and hope it will help them. And it is these errors that I call "64-bit errors".

The error described deserves attention because of its simplicity or even ingenuousness. It has been recommended in all the books for many years not to use magic constants in code. Everyone knows about it and mentions it in coding standards. But in practice magic numbers appear in various code sections again and again.

Let's consider an example of CreateFileMapping function's call in some application:

hFileMapping = CreateFileMapping (
    (HANDLE) 0xFFFFFFFF,
    NULL,
    PAGE_READWRITE,
    (DWORD) 0,
    (DWORD) (szBufIm),
    (LPCTSTR) &FileShareNameMap[0]);

Right - you have guessed it. The error is in using constant 0xFFFFFFFF. The first argument of CreateFileMapping function may have value INVALID_HANDLE_VALUE defined in the following way:

#define INVALID_HANDLE_VALUE ((HANDLE)(LONG_PTR)-1)

As a result, INVALID_HANDLE_VALUE does coincide with 0xFFFFFFFF value in a 32-bit system. But in a 64-bit system 0×00000000FFFFFFFF value will be put into CreateFileMapping function and as a result the system will consider the argument incorrect and return the errors' code. The cause is that 0xFFFFFFFF value has UNSIGNED type (unsigned int). 0xFFFFFFFF value does not fit into int type and that's why has unsigned type. It is a subtle point you should pay attention to when performing migration on 64-bit systems. Let's illustrate it by an example:

void foo(void *ptr)
{
   cout << ptr << endl;
}
int _tmain(int, _TCHAR *[])
{
   cout << "-1\t\t";
   foo((void *)-1);
   cout << "0xFFFFFFFF\t";
   foo((void *)0xFFFFFFFF);
}

The result in the 32-bit version of the program:

-1                     FFFFFFFF
0xFFFFFFFF      FFFFFFFF

The result in the 64-bit version of the program:

-1                     FFFFFFFFFFFFFFFF
0xFFFFFFFF      00000000FFFFFFFF

See also: V112. Dangerous magic number used.

But sometimes you can test the code of Linux-applications in 64-bit Linux environment in Windows system. It is this possibility our engineers are working at. In this note I will tell you how it works.

From the viewpoint of developing 64-bit applications Windows and Linux operation systems differ in the data model being used. This is a correlation between the sizes of basic data types in a particular system. In the 64-bit Windows-version LLP64 data model is used. In this data model the types have the following sizes: int - 32 bits, long - 32 bits, long long - 64 bits, size_t - 64 bits, pointer - 64 bits. In the 64-bit Linux-version LP64 data model is used. In it the data types' sizes are the following: int - 32 bits, long - 64 bits, long long - 64 bits, size_t - 64 bits, pointer - 64 bits. For 64-bit Linux and Windows systems such types as long double are also different but it is not relevant here. As you can see, the basic difference is in the size of long type - in 64-bit Windows it is 32 bits and in 64-bit Linux it is 64 bits.

By default, Viva64 code analyzer (and now PVS-Studio) is oriented on LLP64 data model being intended for operation in Windows environment. Roughly speaking, it means that it searches incorrect shared use of size_t-types and int-types. To test the code on correctness in 64-bit Linux-environment you need to search incorrect shared use of long-types and int-types as well.

We plan to add the possibility of searching incorrect shared use of long-types into the new version of PVS-Studio 3.10. It will be a special operation mode, the so called "Linux-like mode". The analyzer of 64-bit problems will operate in this mode in the same way as it would operate in Linux-environment. It will allow you to partly test the code of applications operating in Linux in Windows system with the help of PVS-Studio.

So, to test a 64-bit Linux-application you will need to have its version compiled into Visual Studio. That is, such testing is reasonable for cross-platform applications which are built both in Windows and Linux.

Of course, testing of an application on 64-bit code correctness in the mode of imitating Linux-environment cannot be considered full and guarantee its efficiency in real Linux-world. Besides, there can be more false responses. But in some cases this testing variant will help you find a lot of errors which would occur in 64-bit Linux-systems.

The disadvantage of this approach is code sections which are not built for Windows. For example, it can be interface parts of a program. You cannot test them in Windows because you cannot compile them. But, for example, you can test the core of a program which operates both in Windows and Linux.

You should also keep in mind that in Linux-like data model only user code is tested. The code included into system include-files in Windows will still be the same as for LLP64 memory model. For all the files are processed by the preprocessor before analysis and of course it does not know about LP64 model.

To demonstrate the peculiarities of using PVS-Studio in "Linux-like mode" I will give some examples.

void foo(ptrdiff_t delta);

int i = -2;
unsigned k = 1;
foo(i + k);

This code will be potentially unsafe both for Windows and Linux systems. An incorrect result occurs at implicit extension of the actual argument having the value 0xFFFFFFFF of unsigned type to ptrdiff_t type. In this case the warning will be shown independently from the mode being used.

void *ptr;
long np = (long)(ptr);

This code diagnosed as incorrect in 64-bit Windows programs will be correct for 64-bit Linux-systems.

Vice versa, the next example shows the code correct for Windows systems and incorrect for Linux ones:

long array[4] = { 1, 2, 3, 4 };
enum ENumbers { ZERO, ONE, TWO, THREE, FOUR };

int *intPtr = (int *)(array);
cout << intPtr[1] << endl;

As the sizes of int and long in 64-bit Linux systems do not coincide, the analyzer will show the corresponding diagnostic warning.

The last two examples demonstrate the limitations of the new operation mode:

#ifdef _WINDOWS
  typedef long MY_SIGNED_32;
#else //Linux
  typedef int MY_SIGNED_32;
#endif

As the preprocessor will choose the branch "typedef long MY_SIGNED_32;" all the code constructions containing MY_SIGNED_32 type will be incorrect from the viewpoint of Linux systems.

And finally we can give a simpler example when the code we need to analyze will not be analyzed:

#ifdef LINUX_64
   // there is too much code here
#endif

Despite the limitations we have listed, the ability of working both with the Windows-traditional LLP64 data model and Linux-traditional LP64 data model will help you broaden the scope of use of our code analyzer. You should just understand how this option operates and what it can and cannot provide.

By default, the new mode will be switched off and those users for whom operation in Linux-environment is not relevant, can forget about it.

Not so long ago, when our product for testing 64-bit code was called Viva64, we were addressed by the manager of the open library Loki* with an offer to check compatibility of the library with 64-bit Windows systems. For that moment the Windows-version of this library was represented only in 32-bit mode. We agreed and set about the new task bating our breath. The point is that compiler developers often use Loki library as a perfect testing model allowing you to estimate compatibility with C++ standard. We were not sure that we would be lucky. So, we consider it a great achievement that our analyzer did not hang on it, did not crash with a critical error and was able to provide normal diagnosing.

But the results of the diagnosing showed a great disadvantage of Viva64 analyzer: it cannot instantiate templates and cannot detect many errors in them. Here is an example to make it clear:

 01 template <class T, class M>
02 class TemplateClass
03 {
04 public:
05   char m_char;
06   T *m_t;
07   M m_m;
08   T Get(int index) { return m_t[index]; }
09   void Set(int value) { m_t[m_m] = value; }
10 };
11
12 TemplateClass <char, int> A;

Only one potential error in line 8 was detected. In this line a variable of int type is used as an array index and it is potentially dangerous when working with large data arrays. When diagnosing this error it does not matter what relates to T type. But two other errors we will describe further have never been detected by Viva64 analyzer. One can say that Viva64 checks the code of templates rather superficially and detects only those errors which are present in it independently from the arguments with which an array will be instantiated.

This disadvantage arises from OpenCxx library on whose basis VivaCore library has been created being the base of Viva64 analyzer. The reason is very simple - OpenCxx simply cannot instantiate templates. It looks rather strange for it restricts abilities of the library. But we have a suspicion that there had been support of template instantiating in OpenCxx library but then was deliberately removed before the project became open and accessible. Some strange stubs and near-empty classes relating to template processing are an indirect evidence of this.

We have known about this drawback and its effects on diagnostics for a long time but it was Loki library that urged us to engage into implementing a mechanism for testing instantiated templates. We have created a mechanism which instantiates a template and analyzes it again on the basis of new knowledge about types. Implementation is not very good yet and needs to be improved but it already allows us to detect many new errors. Let's discuss it on the basis of the example given above.

After implementing the instantiating mechanism the analyzer immediately gave three diagnostic messages:

Line 3: error V401: Instantiate TemplateClass <char, int>: The structure's size can be decreased via changing the fields' order. The size can be reduced from 24 to 16 bytes.

Line 8: error V108: Incorrect index type for "m_t". Use memsize type instead.

Line 9: error V108: Instantiate TemplateClass <char, int>: Incorrect index type for "m_t". Use memsize type instead.

Having met the line "TemplateClass <char, int> A;" the analyzer instantiated this template and analyzed it possessing the information about T and M types. As a result, it warned that the data structure in the class is non-optimal (V401) and the size of this class in a 64-bit system can be reduced from 24 bytes to 16. For this we need to rearrange the members of the class. Pay attention that this diagnostics is possible only when you know what types the members have. For there can be no warning if, for example, m_m members have size_t type. In this case field rearranging will not help reduce the class' size.

The error in line 8 is detected as before because knowledge about T and M types does not matter here.

The last error in line 9 also relates to indexing of the array with the use of a variable of int type. Here information about M type does play an important role and is used by the analyzer.

The improvements made enabled us to perform fuller testing of Loki library. You may learn more about this work in the article "64-bit Loki" at which we are working together with the library's manager Rich Sposato.

Analysis of Loki has been performed by a special research version of Viva64. But now we decided to integrate the new abilities into the new version PVS-Studio 3.10 ** which will be released in the near future. Users will be able to use a new option DoTemplateInstantiate which enables the mode of deep template analysis.

*Note. Loki library for C++ programming language was written by Andrei Alexandrescu as part of the book "Modern C++ Design: Generic Programming and Design Patterns Applied". The library is built on template meta-programming and actively uses C++ abilities for generalized programming. (Wikipedia. Loki.)

**Note. PVS-Studio is a program product uniting and extending abilities of Viva64 and VivaMP static analyzers. Numbering of PVS-Studio begins with the version 3.00 to emphasize that this is evolution of the existing tools. In 3.00 version we did not hurry to implement template instantiating support but decided to introduce this ability in PVS-Studio 3.10.

If you are going to the event next week in Berlin then let me know about it. Maybe we can meet face to face and if there are enough of us perhaps even a gourp community meeting. This can be a good opportunity to meet the experts.

In any case, you are all welcome to join my session titled "Parallel Programming for Embedded". I will be presenting on Friday 10:45 - 12:00.

At the basis of this presentation is the fact that the hardware has always been parallel. This also caused the kernel drivers to live in a parallel environment, so even though embedded devices were late to adopt Multi-Core CPUs, the people who are working with the lower levels have always been working in parallel environments.

The session speaks of parallel systems in general side by side with embedded systems and infrastructure environemnts.

The goal of this session is to open the eyes and show the systems that have always been working in parallel and name the principles used with these systems.

You can read my previous blogs to learn more about this approach. For example these:

is dos the ideal parallel environment part iv

stateful programming a case study

Here are a few slides from this presentation.

Parallel Programming for Embedded TechEd 2009

USB Ping Pong

Hope to see you all there,
Asaf

This time my attention was attracted by a message in RSDN "Alignment on 64-bit architectures" running as follows:

Today I have faced a problem in Linux. There is a data structure consisting of several fields: 64-bit double, 8 unsigned char and one 32-bit int. Altogether it is 20 bytes (8 + 8*1 + 4). On 32-bit systems sizeof is 20 bytes and everything is OK. But on the 64-bit Linux sizeof returns 24 bytes. That is, an alignment at the 64-bit border takes place.

After that the author dwells upon data compatibility and asks for advice how to pack data in the structure. But at the moment we are not interested in this. What we are interested in is that there is a new type of errors which can occur when porting applications on a 64-bit system.

It is clear and common that when sizes of fields in a structure change, the size of the structure itself changes too because of this. But this is a different case. The size of the fields remains the same but the size of the structure will change too due to different alignment rules. This behavior can lead to various errors, for example, incompatibility of the formats of the data being saved.

Linux systems are not supported by Viva64 yet, but I decided to find out if such an error can occur in Windows systems. For this purpose I took an example of the code printing types' sizes and alignment from the article "C++ data alignment and portability". I've modified it a bit for Visual Studio and got this program:

#include <iostream>
using namespace std;

template <typename T>
void print (char const* name)
{
  cerr << name
       << " sizeof = " << sizeof (T)
       << " alignof = " << __alignof (T)
       << endl;
}

int _tmain(int, _TCHAR *[])
{
  print<bool>        ("bool          ");
  print<wchar_t>     ("wchar_t       ");
  print<short>       ("short int     ");
  print<int>         ("int           ");
  print<long>        ("long int      ");
  print<long long>   ("long long int ");
  print<float>       ("float         ");
  print<double>      ("double        ");
  print<long double> ("long double   ");
  print<void*>       ("void*         ");
}

I compared the data I'd got with the data described in the article "C++ data alignment and portability" for GNU/Linux systems and now give them in Table 1.

Table 1. Types' sizes and alignment.

Let's study this table. Pay attention to the marked cells relating to long int and double. These types' sizes don't depend on the architecture's size and therefore don't change. Both on 32-bit and 64-bit systems their size is 8 byte. But alignment is different for 32-bit and 64-bit systems. It can cause change of the structure's size. When we implement Viva64 for Linux we'll take into consideration the possible errors relating to this.

In Windows systems, there are no such problems with alignment change. Pay attention that alignment of all the types doesn't change or changes together with the type's size. That is good - Windows developers have one potential problem off.

You are hereby invited to a gathering on November 17 at 5:30 pm in room C124 of the Oregon Convention Center in Portland. We are having a panel discussion focused on incorporating parallelism into the Computer Science curriculum. Of course, you might need to purchase a day pass to SC09 to attend, if you are not otherwise attending.

We generally all believe it is a good idea to weave parallelism throughout the CS curriculum. There are a variety of paths to get there, roughly corresponding to number of panelists, of which I will be the moderator and facilitator. The panel held last year at SC08, had a standing-room-only animated crowd. It happens to be available in 15 minute chunks: part 1, 2, 3, 4, 5, 6, and 7. I expect similar festivities this year.

Our distinguished panel is composed of

• Wen-mei Hwu, University of Illinois at Urbana-Champaign, who believes key computer architecture concepts, some performance optimization concepts, some program analysis concepts, some program transformation concepts, effective parallel programming patterns and algorithms, and fundamental parallelism concepts are required to train a successful undergraduate CS major.
• James Larus, Microsoft Research, who believes parallelism must be woven into the general series of courses, but sees the dilemma of the current awkward and crude tools imposing awareness of the underlying architecture on the student. He longs for a more elegant toolchain for use with students.
• Simon McIntosh-Smith, University of Bristol, who has succumbed to the "Snow White" syndrome of advocating the dwarves parallel patterns from UCB. He also sees the utility of teaching the current prevalent tools: MPI and OpenMP, while remaining sensitive to the emerging potential standards: CUDA, OpenCL, Ct, map-reduce, etc.
• Bob Chesebrough, Intel, who sees the trouble in River City of a late introduction of parallelism to students, and of course recommends the "Think Method", in this case the "Think Parallel" method. Parallelism is all around and the key concepts can be conveyed without a computer.
• Steve Parker, nVidia, who believes and has done many things. There needs to be a teaser to get you to come to the event. This is it.
• Charlie Peck, Earlham College, who sees faculty education as key activity to get right, since many CS faculty have limited first hand experience with the myriad faces of parallelism. Involving students is a key part of this, for a unique form of learning takes place via an apprenticeship model of student involvement.

For several years now, we have been a parallel education working group composed of broad representation from industry, colleges/universities, hardware manufactures, and labs We are about to call ourselves something like "The Educational Alliance for a Parallel Future." I now know first hand what is involved in morphing from a working group to an alliance. When you are getting ready to make a tee-shirt, alliance ends up sounding sounding way cooler, and actually better reflects who we are. We will also be releasing a parallel crossword puzzle. This is not one solved in parallel, though it might be if someone is looking over your shoulder. The subject matter is of many things parallel. Stay tuned, we'll point you to it, once it debuts at SC09.

After you look at the technology, think about the kinds of device capabilities, hardware and software, that would make your web application better. Then share them with us - we're listening.
If you need some food for thought take a look at this blog post - where I list several API drafts we recently submitted to the W3C Device API working group.

"The story" gives you the context. "The Technology" dives a little deeper into the details.

Working on CAD Exchanger I am designing one of its plugin to convert 3D CAD data between ACIS and Open CASCADE (two modeling kernels) to be parallel. Depending on a model size, the converter has to deal with multiple small objects allocated on a heap (e.g. 20,000+ objects each taking 48bytes + additional object data such as lists, strings, etc).

The translation works just fine and concurrency analysis with Intel Parallel Amplifier indicates high concurrency levels. So far, so good. However I had noticed that when translating the same ACIS file over and over again in the same test harness session translation took longer and longer. Why could it be ?

So I launched the Amplifier to collect hotspots and here is what I saw:

These two top hotspots relate to the memory manager layer (Standard_MMgrRaw class) which simply forwards calls to malloc/free and new/delete. Trying to root-cause the problem I had to switch to the mode to see direct OS functions (toggling off the button on the Amplifier toolbar) and here is a new screenshot:

It shows that hotspots are two system functions – RtlpFindAndCommitPages() and ZwWaitForSingleObject() – which are called from memory allocation / deallocation routines. It also shows that the nearest hotspot related to my code (BSplCLib::Bohm()) is just 1/4 of the time consumed by ZwWaitForSingleObject() (0.47s vs 1.81s).

After experimenting with several runs, analyzing how the hotspot profile changes with growing number of runs, I concluded that the first hotspot is explained by the fact that the ACIS converter creates multiple tiny objects with different size with short life span (they are destroyed after every conversion). This seems to cause strong memory fragmentation which forces the system to constantly look for new memory chunks.

The second hotspot (ZwWaitForSingleObject()) which goes through critical section is caused by the default mechanism of memory management on Windows which uses a lock.

The execution of locks&waits analysis also proves that memory management lock is the greatest one adversely affecting concurrency.

All this is caused by the direct use of calloc/malloc/free, and new/delete called dozens of thousands times. It’s worth mentioning that such hotspots did not exist when I used serial implementation and popped up only when I started using parallel one. The former used a memory manager (in a 3rd party lib) that allocated memory blocks and did not return them to the system reusing them when the application requested new blocks. I couldn’t reuse this memory manager because it was not thread-safe and therefore had to switch to another manager that simply forwarded to malloc/free.

So I almost was forced to write my own memory manager that would implement a previous behavior and would be thread-safe and … fast ! Challenges are good but not when you need to re-write low-level components what can take a lot of time and require diligent thorough testing delaying progress in your project which already receives very limited attention.

So, I approached my colleagues from the Threading Build Blocks team to check if there is anything TBB could help with. What was my surprise when they suggested me trying a new release 2.2. Version 2.2 offers a mechanism to seamlessly replace the system memory manager with the tbb allocator. ‘Seamlessly’ really means it – everything I had to is to add a single line of code into a C++ file:

#include "tbb/tbbmalloc_proxy.h"

The outcome was immediate. Not only did the hotspot profile change completely removing the OS hotspots (see the comparison mode screenshot below) but the overall speed up (on entire test case) was about 25%! One line of code, no need of re-writing anything on my own saved hours of coding, with such a return! Just incredible, the least I could say. Recently released 2.2 Update 1 includes further improvements which my app now benefits from (more reliable processing of realloc(), bug fixes for debug mode, etc).

The colleagues later explained me that the TBB allocator runs concurrently (seemingly without any locks inside) and with a similar fashion of reusing previously allocated blocks. Thus, it was the entire application (not only its parallel part) which benefited from this substitution.

So, if you are migrating from serial to parallel implementation you may encounter something unexpected – memory bottlenecks. If you got accustomed to use some nice single-threaded memory manager you can be forced to consider migration to something alternative. If this is the case you may want to give a try to tbb allocator and see if it helps in your case.

12/3 | 4PM | 2405 Siebel Center for Computer Science

UPCRC Illinois Research Seminar: A Structured, Unified Approach to Multi-Core and Many-Core Computing - with Applications by Michael McCool, Intel & U of Waterloo

In a previous post I kicked off a conversation with web developers about exposing device capabilities as javascript APIs and widgets in the browser.

Here's your chance to comment and help inform our web developer enabling activities. Tell us about how having better access to the device's hardware capabilities would make your web app implementation easier. Maybe you have a use case you would like to share?

Here is a list of APIs for device capabilities we proposed.

You can see the detailed API specs and example use cases at the WC3's site.
This is only the beginning. Stay tuned to the blog, or my tweets, for more API, widget and mashup proposals coming in the near future.