I have been reading Herb Sutters effective concurrency articles over the past last couple of weeks. I just finished reading the last one. I think he will compile them into a book when he has enough of them (there are about 17 of them at the moment). I’m sure I’ll buy the book once its out, as I got all his other book already.

What is clear is that concurrent programming has hit the mainstream, and its here to stay whether we like it to or not. Tomorrows PC’s might not have faster cores than today’s, but tomorrows PC’s might have a hundred times more cores than todays. Programming such a beast correctly, while keeping your sanity, will not be an easy task. Although an interesting subject, it comes abit of a surprise to me how low level concurrent programming today still is. For parallel C++ programs its not just the order of the code as you write it that matters, not even the compiled rearranged code order can be counted on, its the order of the code actually being executed on the cores that makes all the difference to the correctness of the program. All this rearranging behind the scenes by the compiler and the CPU is done to optimize sequential execution but it makes life very difficult for concurrent programmers. To sequential programs the order looks the same on all three levels, but to parallel programs the different ordering will be seen and this causes more potential bugs and more complex logic to get right. Its like a step down back into assembler programming to get the ordering and synchronization right, or even like a step one level below assembler code, down to the the actual machine code on the CPU.

The C++0x standard will address some of this, in that C++ will finally get a defined memory model. This will basically limit how the compiler and the CPU may rearrange the code you write. Then there will be a new keywords, atomic, that forces the compiler to play nice and synchronize reads and writes to a given variable between all the cores. Then there will be threads, thread local storage, locks, futures etc. But its all still very low level. Hopefully higher level libraries and patterns will emerge that make writing deadlock free, data race free, scalable programs easier.

In my humble opinion it’s a bit unfortunate that once a new thread is spawned, the language and compiler assumes that all data and functions are safe to be used without synchronization. You have to explicitly specify and single out the variables and functions that have to be synchronized, instead of the ones that don’t. Well that’s just my two cents. The switch in programming styles, patterns and tools to accommodate the concurrency revolution will sure make for an interesting decade. If anything is going to kill C++ it might be that parallell programs are just to complex to get right in a language that allowsshared state and imperative pprogramming styles. Then again, if that the case, then most of todays mainstream languages will get killed even worse.

Anyways, here are Sutter’s Effectice Concurrency articles.

Advertisements

Better functors with boost

November 30, 2008

Today I read about boost::bind

It replaces the old STL function/functor binders (although lamda functions are a better replacement when composing/nesting several layers of binders). The improvement over the old binders is that (by way of better deduction) the new binder is less picky about the function/functor type, it can bind to any function/functor with up to 9 arguments, and the order of the arguments can be rearranged when binding. Bind is now part of the TR1 of the C++0x standard.

Here is a article and tutorial about boost::bind by Björn Karlsson: “How the Boost Bind Library Can Improve Your C++ Programs”.  The article is from the book “Beyond the C++ Standard Library: An Introduction to Boost” I’m tempted to buy the book, although I first have to finish a couple of other C++ books im reading.

I have been waiting to see if some authority in the c++ community would bite and give a response to Linus Torvalds flame about how bad C++ is compared to C. Steven Dewhurst’s wrote a good response. But first, If you haven’t heard the gossip.. A while back Linus gave sound bites like:

“C++ is a horrible language. It’s made more horrible by the fact that a lot of substandard programmers use it. […] C++ leads to really really bad design choices. You invariably start using […] STL and Boost and other total and utter crap […] and anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it’s not even funny. [C++ leads to] inefficient abstracted programming models. […]  The only way to do good, efficient, and system-level and portable C++ […] is limiting your project to C [which] means that you get a lot of programmers that do actually understand low-level issues and don’t screw things up with any idiotic ‘object model’ crap.”

You can read the whole thread here if you like.

I find it a bit chocking that a highly respected programmer like Torvalds would write such statements about the most advanced language in common use. He did not give any references to back up his claims about C++’s inefficiency or importability. He gave very little context for his views, so its hard to see where he is coming from. I got the impression reading the thread that C++ is unpopular in the open source developer community.

It’s been a long time since C had any performance advantage over C++. A decade ago The inventor of STL, Alexander Stepanov, wrote a famous article and benchmark where he debunkes the myth of the abstraction penalty of C++ compared to C. You can read the whole paper here.

The current C++ standard has been out for a decade, and today’s main compilers and standard library implementations are very conformant. So I cant imagine portability being much of an issue today. Even assuming Boost has portability problems, the library is just another 3rd part library, so you cant really blame the C++ language for it.

As for bad code and programmers. The fact that C++ has data hiding and abstraction features, and has stronger type safety than C, makes it easier to write good code. Without using data hiding and abstractions, dependencies are stronger and their number greater than necessary. It seems rather anti-intellectual to prefer more detail over more abstraction. After all, math, the purest science of all is all about abstraction. Good code is correct code, first and foremost. And performance, although important, is a secondary concern. With C++ we get the best of both worlds. Powerful abstractions and high performance.

I see no benifit to C, other than it being a simple language to learn. C++ might be complex, but not needlessly so. Every feature (well almost) is there for good reason.

Anyways, finally, here is Steven Dewhurst’s (a well known C++ author) response to Linus comments about C++. I’d love to see Linus response. Maybe he could explain his reasoning better given another chance.

Functional sugar in C++0x

November 10, 2008

I found this easy to follow lamda tutorial when checking out the wikipage for C++0x. Its written by a member of the VC10 Visual Studio C++ team.

Check the tutorial out at: http://blogs.msdn.com/vcblog/archive/2008/10/28/lambdas-auto-and-static-assert-c-0x-features-in-vc10-part-1.aspx

I think lamdas are great, as it will automate much of the cumbersome task of defining functors. Functors are central to STL, but I find the amount of boilerplate code that has to be written (even for the most basic functor) to be cumbersome to write and distracting to read.

More Importantly though is that the declaration and definition of the functor is often visually removed (and logically hidden) from the local context where its used. This has made defining functors unpractical for simple one-liner tasks. In the most simple cases one can always compose the standard functor adapters and binders to do the task at hand. But for slightly less simplistic logic the code quickly becomes unreadable.  

So for logic that are is not simple enough for adapters and binders, but not complicated enough to warrant being encapsulated into its own named class.. well for such logic lamda functors is now a much better fit. I think lamda function will probably make the functor adapters obsolete, and full blown encapsulated functor class declarations even rarer. You can even store the unnamed lambda functors in a named wrapper. Lamdas might just sound like syntactic sugar, but the fact that it makes functor so much more useable will make it easier to code in a more functional manner.

Another nicefeature exemplified in the post, is the new auto keyword. In C++0x the compiler will let you use the the keyword auto in-place of a type name when the compiler already can deduce the type. Again this is just syntactic sugar, but i think it will make a big difference in the way people code. I think it will help a programmer weaken the dependency and delay the commitment to a specific type until compile time (as opposed to design time). One might not even care or know what the actual name of the type one are using is. That again will make it easier to program in a more functional style.

Maybe this is more than syntactic sugar, maybe it will fundamentally change how people think about C++ design.

Anyways that’s my two cent. Check out the post to find out the details.

Cheers