Libraries work in Orcas

Hi! My name is Ale Contenti. I'm a developer on the Visual C++ Libraries Team. I work on the CRT (C Run Time, i.e. strcpy() and printf(), like I always explain to my friends), SCL (Standard C++ Library, i.e. STL and streams), ATL and MFC. I also happen to work for Martyn, which blogged here a few weeks ago.

So, if you read Martyn's post, you already know what the Libraries Team is going to work on during Orcas. One of the area's that I'm working on is STL/CLR.  We're making good progress on this, too!  You can finally put your hands on a pre-release of STL/CLR in the next available CTP (it should be online in August). You can also find some cool postings on STL/CLR on Nikola's blog.

Ok, but what do I really do? During last product cycle I worked a lot on the Secure Libraries (i.e. strcpy_s() and checked iterators). During Orcas, I've been working on STL/CLR performance investigations for the last month or so.

STL/CLR is pretty cool. It is developed by Dinkumware. Here in VC++ we analyze and test the drops they give us, and we open bugs and give feedback on the design of some parts of the library. Recently, we've been focusing on improving the performance of some key scenarios.

We decided to compare STL/CLR perf against two other libraries:

• STL, which works only on native types and use the native heap);
• BCL, i.e. the collection library in the .Net Framework, basically the collections in System::Collections

Notice that it’s pretty easy to compare STL and STL/CLR, because they are based on the same (simplified) principles:

• containers, which have member functions do add, remove and access elements;
• algorithms, i.e. external functions which operates on ranges of values;
• iterators, i.e. the glue between containers and algorithms.

An important difference, though, is that STL is native code

• can be compiled /clr and /clr:pure;
• cannot be compiled /clr:safe (i.e. the code is not verifiable, because it uses pointers and native storage);
• works only with native types;
• use native storage (i.e. new/delete).

On the other side, STL/CLR is a managed library, written entirely in C++/CLI, and all STL/CLR is verifiable code

• can be compiler /clr, /clr:pure, /clr:safe
• works only with managed types (and C++/CLI built-in type);
• use garbage collected storage (i.e. gcnew/delete).

The result of our investigation is that STL/CLR is slower than STL most of the time. The advantage of native code, especially in code like this, is still pretty high. But STL/CLR is not order of magnitude slower… we’re still doing pretty well overall.

Comparing against BCL is more important for STL/CLR, since they both can store the same managed types. Some of the characteristics of BCL are:

•  only have containers and enumerators;
• based on generics (while STL/CLR is based on both templates and generics).

All the operations that STL/CLR usually implements separately as algorithms (like sort) are implemented as member functions of the BCL collections themselves. This gives the BCL collections a perf advantage, since their sort method knows about the internal implementation of the collection. On the other side, STL/CLR containers and algorithms are more versatile, and this gives STL/CLR an advantage when, for example, you need to sort with a custom operator<.

In our tests, we’ve seen this pattern: STL/CLR is more or less on par with BCL, and can be a little faster than BCL in some scenarios.

Notice that this performance work is not yet done! The STL/CLR you will see in the August CTP has some good overall performance, but it’s still an early preview! And it's important you try it out and tell us what scenario you care about most, how do you want to use it, etc. so that we can beef up our perf tests even more!

Let us know! And thanks again for all the feedback (not only on STL/CLR).

Next time I want to post some real code and some interesting things we found while playing around with this big C++/CLI templated library. Stay tuned! J

Ale Contenti

VC++ Libraries Team