I wanted to remind all of you that the live event is scheduled for Wednesday, Oct 15th, 8AM-3PM PST. The event will also be archived for the next 30 days, but there will be no live Q&A and networking opportunity in the archived event.The event is a virtual experience with technical sessions, ISV/Intel exhibition hall, networking lounge, etc. I am looking forward to seeing you at the Boot Camp. Also, please don't forget to give us your feedback - Your feedback is very important to us and can help us host better events in the future.

I've noticed that developers who start using TBB often ask questions "Whether I should replace STL containers (protected with locks where necessary) by their TBB counterparts in my application? Are TBB containers faster that those from STL?". Unfortunately questions formulated like this are too general to get a specific answer. Therefore I decided to make a concise overview of how TBB concurrent containers differ from the STL ones, why the particular design decisions were made, and what the efficiency of both approaches depends on (though I'm not a person who designed TBB containers I believe my understanding of the matter is basically sound, and in the worst case my colleagues will correct me if I misstate anything:) ).

I'll try to keep this discussion general enough, without delving into the implementation details or analysis of specific use cases, so that after reading it you have an understanding, which criteria should be taken into account when choosing the solution for your particular application.

Let's have a look at how do the scopes of functionality of both container libraries correlate with each other.

First of all one have to understand that despite of similar names and a lot of commonality in interfaces of TBB and STL containers, the former are not simply thread-safe versions of the latter. Though we tried to make TBB interfaces as close as possible to those of STL, most of them still have substantial differences in their usage models (and consequently in interfaces). To name the most prominent ones:

- concurrent vector does not support insert and erase operations (new items can only be pushed back), and cannot be shrunk;
- concurrent hash map does not support iterators, and uses accessors instead.

There are two main reasons why concurrent containers cannot be made thread-safe replicas of their STL counterparts. First, concurrent access invalidates some of the assumptions that the serial code relies on. Let's consider vector's method pop_back(). In the serial code it is often used as part of the following idiom:

T item = v.back();

v.pop_back();

But in concurrent case another thread may pop the same item while the first thread is in between of the two above operations.

Leaving such methods in the TBB interface would encourage TBB users to inadvertently write inherently flawed code. Such adverse scenarios would be quite probable since most of the programmers move to writing parallel code after getting substantial experience with the serial programming and its patterns. Another risk is that such unsafe methods would mask dangerous pieces of serial code when it is parallelized. Taking all this into account TBB designers decided to explicitly prohibit use cases that lose their original serial meaning or lead to indeterministic behavior in the multithreaded apps.

The fact that TBB culled STL interfaces still does not mean that what remains is a thread-safe subset of STL functionality. Some operations in TBB containers are not thread safe, like reserve() and clear() in concurrent vector. Other methods are extensions to what STL has and reflect the specifics of the parallel usage models, e.g. the family of grow_xxx() methods in the concurrent vector or pop_if_present() and push_if_not_full() of concurrent queue.

Besides, some of the concepts though supported by concurrent containers may change their meaning slightly in comparison to their serial usage. For example the intuitively simple "first in first out" notion becomes somewhat fuzzy when a value may be pushed by one thread and popped by another. So before starting incorporating concurrent containers into your application for the first time, please read the reference (or at least tutorial) carefully, to avoid unpleasant surprises.

The second reason why the usage models of TBB and STL containers differ is more mundane. Actually it is what the whole multicore shift is about, … right, it's performance. Supporting some of the serial usage models though technically possible would be so inefficient that their applicability area would become marginally small (e.g. iterating over the concurrent hash map).

Besides, from the methodology standpoint, providing such tremendously inefficient APIs would entice unaware developers into writing code that covertly ruins performance of their applications, and increase the probability of the situations when a serial code that apparently has been successfully parallelized, works slower than its serial ancestor even on a quad-core machine.

At last, some of the dropped functionality, if implemented, would have taken unbearably heavy toll on the performance of other operations, and thus render the whole concurrent container next to useless. For example, insert() in concurrent vector, if allowed, would have drastically burdened both iterating and growing operations, which constitute the backbone of the container's usage model.

Now that you have a general idea why TBB concurrent containers are quite unlike even their closest STL relatives, I'd like to attract your attention to the fact that TBB (at least so far) provides noticeably fewer containers than STL does. I believe most of you have already guessed why it is so (disregarding the considerations of TBB team's limited resources). Anyway I'd recommend you to have a look at the blog discussing one particular case of not supported containers: "Linked Lists - Incompatible with Parallel Programming?".

Though I’ve already lavishly used words “performance” and “efficiency”, all that was said before does not give any clue as to which choice should you do in your particular application (and I promised that you’ll learn it (well, at least will have an idea)). I’m not going back on my words, and we’ll talk about it in my next post that will get to you sooner rather than later (hopefully before the end of this week). Cheers.

As we wrote in the past, this application unnoficially goes also by the names of or Intel AMT pop-up or Privacy Icon. But unfortunately it is also called by some people with the name of 'annoying' :(. This may be because a manufacturer set it to 'always popup', or because it displays an error message (see how to fix the error in the previous post)…  But the fact is that it is considered bothersome by a number of users.
For those, this time we'll see how the icon can be minimized, disabled or removed from the system. Just keep in mind the notes at the end of the article, our recommendation is to have it minimized at startup.

Here too, the notes apply:
Note 1: Your systems may use a different folder for the software, change it accordingly where needed.
Note 2: Some modifications include changing values in the registry. While this should be inoffensive when done on the key/values described below, the registry is a dangerous place to tamper. Do it with care and at your own risk. :)
Note 3: The instructions below pertain to versions of the software up to Intel AMT 3.0. Versions 4.0 and on will be discussed in a different post.

• Minimize the icon on startup
  Your application should appear minimized when Windows loads. The icon will be seen in the notification area, but no other distracting dialog will appear -- until the notification area icon is double clicked.
  This is the best option to go. It keeps the application there in case it is needed, but it is out of the way.The following registry key determines the loading behavior:
  Key: [HKEY_LOCAL_MACHINE\SOFTWARE\Intel\Network_Services\atchk]
  Value: "MinimizePrivacyIconAtStart"=dword:00000001
  
  Have it set to 00000001 to minimize on start, or 00000000 to have it popup.

• Disable loading of the application
  If you want the application not to load at all, you can delete it from the startup list, by deleting its value at the following registry setting:
  Key: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run]
  Value: "atchk"="\"C:\\Program Files\\Intel\\AMT Status\\atchk.exe\""
   
  Delete the value, as below, to prevent the app from loading.
  Key: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run]
  Value: "atchk"=""

• Disabling the Intel® AMT System Status icon completely
  It was suggested in the past that one of the ways to disable the Intel AMT dialog is by simply telling Windows not to load it, in 'msconfig'. If that's what you want, here's the proper way to do it:
  Run 'msconfig' from the 'Run…' dialog, just go to the 'Services' and 'Startup' tabs and unselect the Intel® AMT System Status Service and the Intel® AMT System Status.
   
  Just the 2 lines shown in the pictures below (unrelated apps purposely blurred).
  
  
  Do not uncheck other Intel services and applications, as they may be of importance to your system's function and performance.

 
Very Important Note! Pay attention that by disabling the icon on startup or disabling the application and service completely, you take from the transparency and straightforwardness of the system.
Depending on the context, this may also have serious disclosure, privacy and/or legal implications.
Most times the users will be interested to know if the manageability system is performing in their systems. So the recommended option is to set "minimize icon at startup" - in this way, the Intel AMT popup is not intrusive/obtrusive, and the users still have access to up-to-date and transparent system information.

Well, that's it for the System Status icon. A lot of configurations, for such a little application :)
Next times we'll see what are the UNS, LMS and Intel MEI are about -- stay tuned, ask your questions.

Over on MSDN's Channel 9 is an interesting conversation between Jeffrey Snover, Martin Fowler, and Neil Ford on Domain Specific Languages.  

For most of you reading this blog Martin Fowler (Thoughtworks) needs no introductions and if you don't know who he is he is the one responsible for the Refactor menu within an IDE such as Visual Studio or Eclipse. If you don't already have a copy of his book Refactoring then definitely check it out. 

Neil Ford is a Software Architect and Mean Wrangler with Thoughtworks, listen to the conversation and you'll find out it actually says that on his business cards.

Jeffrey Snover is a Software Architect at Microsoft and the creator of the Windows PowerShell.

If you experience this problem, you can first try another browser (e.g. Firefox) to see if you can connect to the WebUI. If successful, then you can try the setting the following configurations in your IE settings.

When I  first encountered this issue I thought it was a bit obscure, but now am surprised it is not being reported more often.

Given the multi-core revolution, which Intel is without a doubt the driving force behind, I am very interested to learn more about how Microsoft and others intend to enable architects and developers to more efficiently write multithreaded code. MSDN's Channel 9 has an interesting conversation with Anders Hejlsberg and Guy Steele where they discuss concurrency and language design. Anders Hejlsberg, for those who don't know him, is the architect at Microsoft of the C# programming Language. Guy Steele is a language architect from Sun Microsystems and is working on a new language called Fortress which features implicit parallelism.

The first thing one has to say in that context is:
1. Eliminate sharing. Period. Not false sharing, just sharing. It's sharing that has huge performance penalties. It's sharing that changes linear scalability of your application to super-linear degradation. And believe me, hardware has no means to distinguish false sharing from true sharing. It can't penalize only false sharing, and handle true sharing without any performance penalties.

Second thing one has to say in that context is:
2. Put things that must be close to each other... close to each other. Assume following situation. In order to complete some operation thread has to update variable X and variable Y. If variables are situated far from each other (on different cache lines), then thread has to load (from main memory, or from other processor's cache) 2 cache lines instead of 1 (if variables are situated close to each other). Effectively this situation can be considered the same as false-sharing, because thread places unnecessary work on interconnects, thus degrading performance and scalability.

Points 1 and 2 can be aggregated as:

1+2. Do pay attention to data layout. This was important in the 60's. This is even more important in the multicore era.

Only after that one can also add:

3. Sometimes sharing can show up when you are not expecting it, i.e false sharing. This is important to eliminate false sharing too... etceteras... [insert here contents of False Sharing article]

If one says only point 3, well, it's basically senseless. And sometimes it can even hurt.

Let's consider simple example:

long volatile g_operation_count = 0;

void collect_statistics() {

  InterlockedIncrement(&g_operation_count);
}

What does naive programmer think about it? Hmmm... Let's see... I use "fast" non-blocking interlocked operations. Good!... Hmmm... False sharing. Let's see... Hmmm... Here is no false sharing. Good! So my program fully conforms to recommendations of experts.

Rubbish! It's a dead-slow, completely non-scalable program.

Now let's apply consistent rules to the example. First of all we have to do something like this:

long volatile g_operation_count [MAX_THREAD_COUNT] = {};

void collect_statistics() {

  InterlockedIncrement(&g_operation_count[get_current_thread_id()]);
}

It's good distributed design. When we need aggregate number of operations we just sum up all thread local counters.

Only at this point we can remember about false-sharing and put the final touches to the code:

struct counter_t {
  long volatile count;
  char pad [CACHE_LINE_SIZE - sizeof(long)];
}
counter_t g_operation_count [MAX_THREAD_COUNT] = {};

void collect_statistics() {

  InterlockedIncrement(&g_operation_count[get_current_thread_id()].count);
}

Ok, this distributed version is also fast and scalable. It has linear scalability and can be faster up to 100x on modern multi-core hardware as compared with original version.

So, point 1+2 is a kind of general rule, while point 3 is just a refinement to them.

Why people don't say the whole truth? I don't know. I don't beleive that authors don't aware of the problem. Maybe they think that it's obvious. The practice shows that it's not...

I'm going to devote this blog to multi-threading, multi-core, synchronization algorithms and all other concerned things. Development of lock-free, wait-free, obstruction-free, atomic-free synchronization algorithms is my hobby. Some of my designs you can see here.

Also, I've developed a tool called Relacy Race Detector, which can be of help to developers of synchronization algorithms.

Stay tuned!

So how does this relate to Intel?  The answer is: computing power. The energy problems that need to be solved are highly complex, with many variables, and involve math and engineering that are well beyond many people's comprehension. Without solid, speedy, powerful and reliable computing, I doubt we can get good answers quickly enough to pull us out of the hole. So you better believe that we'll continue to do our part by innovating solid and cutting edge technology to feed all you brilliant people out there. Together we can rally, and I thank you in advance for doing your part.