Slashdot Mirror

Yes, Intel/AMD could have started doing multi-core sooner, but the entire point of the article is that designing software for multi-core hardware is hard, and requires a shift in the mindset of software designers to 1) realize noticable performance increases from it, and 2) properly find all race issues (some of which never show up on a single-core machine).

I don't know if it has been referenced here before, a very interesting and enlightening article : http://www.gotw.ca/publications/concurrency-ddj.ht m

The Free Lunch is Over, same thing you're saying, but now you too can beat people over the head w/ it.

concurrency ? http://www.gotw.ca/publications/concurrency-ddj.ht m/ anyone ?

"Starting today, the performance lunch isn't free any more. Sure, there will continue to be generally applicable performance gains that everyone can pick up, thanks mainly to cache size improvements. But if you want your application to benefit from the continued exponential throughput advances in new processors, it will need to be a well-written concurrent (usually multithreaded) application. And that's easier said than done, because not all problems are inherently parallelizable and because concurrent programming is hard."

http://www.gotw.ca/publications/concurrency-ddj.ht m
Talks about the need for more concurrency as we hit the clock cycle wall.

While memory speeds will continue for awhile, already processor speeds are falling off. Check out this graph from the article where he clearly shows what's happening.

This brings an interesting dilemma to modern programmers. Programs won't magically get faster anymore. We need to start coding to take advantage of concurrency.

The same is true of using SIMD units. They can speed up your code dramatically, but they must be taken into account in your code. That's why this macstl project is such a good idea. It is a standard set of common primitives that let you harness the SIMD functions of your processor. By putting a library over the specifics, your vector-aware code will grow with modern SIMD systems.

Few people will ask you to write in assembly these days, but if you could easily give your math-intensive program a 10x-30x speedup by using one library (that seems very easy to use, by my standards), why wouldn't you?

While memory speeds will continue for awhile, already processor speeds are falling off. Check out this graph from the article where he clearly shows what's happening.

This brings an interesting dilemma to modern programmers. Programs won't magically get faster anymore. We need to start coding to take advantage of concurrency.

The same is true of using SIMD units. They can speed up your code dramatically, but they must be taken into account in your code. That's why this macstl project is such a good idea. It is a standard set of common primitives that let you harness the SIMD functions of your processor. By putting a library over the specifics, your vector-aware code will grow with modern SIMD systems.

Few people will ask you to write in assembly these days, but if you could easily give your math-intensive program a 10x-30x speedup by using one library (that seems very easy to use, by my standards), why wouldn't you?

Surely people can now start to see where the future lies - from a performance viewpoint. We've reached the end of the clocking "free lunch" (see http://www.gotw.ca/publications/concurrency-ddj.ht m/).

The way forward is turning the CPU (of a traditional) architecture into a Nanny for a range of various dedicated processing units. IBM saw this years ago, and thus began the whole Cell architecture - but I suspect that their job was much easier. The software that would run on the platform they are designing is fairly specific - games & multimedia which usually lend themselves well to vectorization.

The real challenge for architects (in my humble opinion) is translating will be applying the same technique to other system bottlenecks.

AMD's (and now Intel's) approach of crambing more and more processing cores onto an IC might pay off in the short term, but like the "free lunch" of clock speed, will hit a roadblock when issues like memory bandwidth and caching schemes just have too much work to do with 4 or 8 processing cores hacking at it all the time.

In addition, code performance matters less and less as machines get faster, memory goes up etc.

But what about all these posts that say Java is as fast as C/C++ in all problem domains? If true, then fine (although I find it difficult to believe). If not then Java will soon be a dead language.

Also, maybe you haven't been keeping up with the news (working can do that to you), but the free ride is over. Software is now going to be more responsible for performance increases than hardware. That is the future. Efficient programing and real concurrency are the future. "cycles are cheap" and "just wait a year and it will be fast" will be laughed at in a decade. It is incredibly naive. Sure not all programs need to be fast, but some do. It is about time that programmers began to take some responsibility for the speed of their code again. I for one am hedging my bets by getting more into assembly again. Some kind of concurrent (built in from the ground up) low level (like highly macroed assembly) version of C or ADA is what I see as the future. If it is to be a managed language, fine, but that had better not impact on performance or you will simply lose out to your competitors even if it takes them longer to get their product out the door. I say again, the free ride is over. There is only so much you can get done in x seconds.

Since the dual core freescale supposedly outperforms a G5 at same clock speed, I really would have liked to see the freescale in the new specs.

Not to flame, but I'm interested in where you're getting your information from (benchmarks, reviews, etc). I wouldn't be surprised at all to see a Dual Core G4 outperform a single core/CPU G5 when it comes to apps that are fully MP-aware (threaded properly). But I would be surprised to see a Dual Core G4 outperform a single core G5 on apps that are not threaded. I'd love to see some real world comparisons.

Remember just because it has 2 cores doesn't mean that it's twice as fast. It only means that there's the potential to do more at once if the software can take advantage of it through threading. Here's a great article that explains the problems/challenges software developers are going to face with multi-core CPUs.

Now I'd love to have a dual core CPU in my laptop and I'd love to program for it, but I image Apple would face some of the same challenges trying to get the dual core Freescale CPU into a laptop as they would in getting a G5 into a laptop, namely heat. A dual core G4 is going to be hotter and more power hungry than what they've got now. I'd love to see either the dual core G4 or a G5 in a laptop.

It works.
Free Flat Screens | Free Mini Mac

Jesus do you people ever get tired of re-hashing the power consumption issue? As someone who needs the power at what ever cost I welcome these bad boys. Pentium M is a great desktop core, but I need pure speed.

Well, get used to it. Intel has realised that the GHz war has ended. They have hit the limit of speed, at least as far as clock speed goes.

This doesn't mean the end of processor speed increases, but most further increases will have to come via other ways - increasing the cache size and increasing parallelism with multicore cpu's

The original article was on
Slashdot and links to Dr Dobbs Journal

Essentially, expect an exponential increase in the number of CPU cores.

So, get used to it, you are going to have parallelism in a big way, and the issue of heat per CPU isn't going to go away in a hurry - it will be the limiting factor on speed for a while yet.

My 2c

Michael

RAWR, no discussion of dual-core CPUs is complete w/out a mention of Herb Sutter's The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software!

I've been thinking about whether or not it'd be better to see a dual core G4 or a G5 in PowerBooks. Assuming both could be done with similar heat situations comparable to today's G4 notebooks, which would you rather see?

IMHO, I think I'd rather have the dual core chip. As much as I'd like to see a 64bit chip in a PowerBook, I think a dual core is more likely to be advantageous in the near future as per the MHz wall that the processor industry has hit and how this will affect how we all write software (see this article on the use of concurrency in software design).

Does anyone else have thoughts on this? If it was up to you, what would you put in the next PowerBook: A G5, or dual core G4?

I read an article which included an anecdote about optimisation problems in the 64 bit version of the MSVC compiler. The problem is that compilers use a vast number of pointers, and while the number of registers has increased, the amount of cache has not and so they can only fit half the number of pointers into cache on chip and are getting more soft page faults as a consequence. This almost exactly offsets the gain caused by the extra registers so the 32bit and 64 versions of the compiler run at just the same speed.

Oh, yea!
They despise so much that they hired Herb Sutter to work on it.

I'm not exaggerating. I ask every Senior C++ developer I inteview this Interview Question; and to date, only 1 out of well over 100 programmers could answer it correctly. And that one? He explained "yeah, I just read Herb's book last night studying for this".

Give a non-C++ programmer that question and 0% will get it right. Give these same people Java or C# or C or Eiffel or ML or Haskell or Python or anything except C++ or Perl and they'll probably guess correctly what will happen even if they don't "know" the language well.

If you have a language where 95+% of people who describe themselves as Sr Developers with Strong Knowledge of the Language can not even figure out which functions in a 20 line program get called; it's the language that sucks, not the developers.

I did XP in extreme C++ for about a year (by extreme C++, I mean boostified, Alexandrescu'd C++). We used CppUnit for our test framework.

I'm not especially satisfied with the currently available C++ unit testing frameworks. CppUnit and Boost's both have trade-offs. I suspect they'll both get better, though.

The Ant-Contrib project's cc task works pretty well, in my limited experience. I was playing around with it just this weekend. I've yet to set up a tinderbox build process, but I don't see why this wouldn't be easy with either Cruise Control or good ol' cron.

In my mind, the two biggest hurdles with doing XP in C++ are build speed and developer prejudice. You can tackle build speed with a combination of ccache, distcc, good programming principles, and cash. Tackling developer prejudice is harder. A lot of C++ programmers like to write low-level, unsafe, old school C++ code. Modern C++ mostly lets you discard unsafe coding practices without sacrificing efficiency. Whether you can convince an old C++ programmer of this is another matter; it depends on the person. I've had decent success taking Java programmers and teaching them modern C++ via pair programming.

Using Boost helps, indirectly. You write safer code, which gives you a faster development cycle. All in all, I think the basic tools are there. It might be a little harder to get fancy lava lamp integration going with C++, but there's no reason why you can't have a good build process. It's just that a lot of C++ projects haven't evolved (I think this is due, in part, to the fact that the C++ community is late to the internet; a lot of C++ programmers just don't know what's, out there.

cheers,

Jon

I think the best way is to do what C++ does: it also gives you both declared and undeclared exceptions, but it makes the "can throw everything" case the default for every function.

Java and C++ are very different when it comes to exception specifications. C++ doesn't have the notion of a "checked" exception. Also, C++'s behavior when an exception specification is violated is also very different from Java's. Most experts agree that C++'s implementation of exception specifications is garbage and should rarely be used. See here and here.

I don't think any C++ implementation has ever been completely 'standard', it's a very difficult goal to acheive.. especially when you consider how difficult and complex the STL is to implement.

I'd agree that a few years back Visual C++ was woefully non-standard, but of late they seem to have made standards compliance a major goal to the point where they're probably at least as standard as GCC now and improving rapidly.

Admittedly the fact that the VC++ has been steered this way of late may have something to do with the fact they have the chair of the ISO C++ Standards Commitee as one of the big muckity-mucks working on VC++...

I do realize you were kidding, but did you realize that they did hire Herb Sutter (The chair of the ISO C++ standards committee) to be the Visual C++ architect for Microsoft.

When over 95% of "C++ programmers" that I interview can't even answer this: straightforward question about virtual methods, I see no hope for the language.

Seriously dude, that is most definitely not a straightforward question. It's carefully designed to test your understanding of some of the subtle tricks and traps of C++. And one of the "tricks" it uses to mislead you has nothing to do with inheritance, rather with implicit casting.

I must admit I got tripped up on it though, mainly because I'd forgotten the distinction between hiding and overriding. The question is nasty, ugly, and was intended to be as confusing and tricky as possible... and any programmer that writes code like that (especially something involving changing the default value of a parameter for an overriden method) ought to be shot.

BTW, if you're asking questions out of GOTW as interview questions, I can only say that that's pretty nasty - except perhaps as a final round question for some of the really cocky smart-arse types :-). Or if you're looking for a seriously hard-core C++ expert, in which case you'd probably expect him/her to have read all of GOTW and Sutter's books and know all the answers off by heart anyway.

It seems most people who claim to be C++ programmers just say that because they use a C++ compiler and stick their functions in objects.

There's certainly a depressing number of such people about - though nowadays they're mainly moving into Java, a language better suited to their limitati^Wcapabilities. And I say "Hooray!" to that :).

The more I try to hire good C++ programmers, the more I become a c++hating bigot.

When over 95% of "C++ programmers" that I interview can't even answer this: straightforward question about virtual methods, I see no hope for the language. It seems most people who claim to be C++ programmers just say that because they use a C++ compiler and stick their functions in objects.

The future I expect is a mix of a higher-level language (Java, C#, perhaps even Python) and C. I can think of cases where C is the right tool for the job (small memory embedded systems), and I can think of cases where Java/C# is (large scale enterprise software); but I don't see C++ as the right tool for either job.

foo++;

OMG! That's just disgusting; imagine using a post-increment operator when there's no need for a temporary.

I'm off to cleanse my mind with another read of Sutter's GOTW.

And what is the deal with the sort(,) as a free-standing function? Following OO principles, shouldn't the vector object v know how to sort itself with a call to v.sort()?

Here is an article that deals with the question which functions should be members and which shouldn't. It uses the std::string as an example which has a lot of methods that turns out shouldn't have to be.

// ville

You should read Herb Sutter's article on Compilation Firewalls (aka the Pimpl Idiom). It basically solves exactly your problem.

Maybe you should learn the use the STL first. One of the first things they teach you when learning the STL is that auto_ptr cannot be put in containers (try boost::shared_ptr for that). Its one of the most well documented libraries I've ever used. Try the SGI STL site, as well as Dinkumware's STL reference. Anyway, Google is your friend. A search for auto_ptr nets this article, on using auto_ptr effectively, as the first hit. It has an entire section titled "Things Not To Do, and Why Not To Do Them".

I prefer programming in C++ because I find it easier to just take responsibility for my memory.

auto_ptr is your friend :-)

I'd really like to be able to say that it wasn't that great, but then a bunch of you would come running at me with machettes.

Oh and btw, make sure you have the credentials if you want to be in the same room as these guys. They're lev21 geeks and won't teach to anyone below lev18, sorry.

The best exposition I've seen was a set of three articles on "Reference Counting" in Herb Sutter's Guru of the Week series. You can find articles 43-45 on his web site, and as he notes there, an updated version is available in one of his books. You could also search the history for the Usenet group comp.lang.c++.moderated, where GotW is posted, to see more discussion on the subject. You might also want to check out the most recent GotW (questions but no solutions on the web site, but check the newsgroup history) for a few thoughts on why string classes tend to have overbloated interfaces.

The problem with on-line C++ is that many people who claim to write about it don't know their subject, and consequently write superficially correct code that actually sucks. I'm sorry to name names, but the much-recommended-here CPlusPlus.com is one such site; their "Hello, world!" program at the start of their isn't even correct. I'd give sites like that a miss if you're seriously interested in learning C++.

One good source of information about C++ (and many other programming-related subjects) on-line is the related Usenet newsgroups, particularly the group specifically for learners if you're just starting out, or the moderated C++ group for more advanced subjects.

Many of these groups also have helpful FAQs, available (as usual) via the Internet FAQ Consortium. Again, for those just starting out, I'd particularly recommend the alt.comp.lang.learn.c-c++ FAQ, which has links to helpful on-line resources, free compilers, etc.

There are a few web sites of which anyone in the C++ field should be aware.

• You can get generally pretty sound book reviews for thousands of books on these and related subjects at the Association of C and C++ Users web site.
• Herb Sutter's web site has lots of informative and thought-provoking C++ articles by one of the guys who's advanced C++ programming technique a lot in recent years.
• Similarly, Scott Meyers' publications page has many worth-reading articles on C++.
• It would be remiss not to mention Boost, a collection of very good general-purpose C++ libraries. If you can't see how to do something with the standard stuff, the answer -- or a useful idea to find it -- may well be here.

There are a few decent on-line references to the standard library:

• Dinkumware make a standard library implementation, which is shipped with Visual C++ amongst other things, and provide some helpful documentation on-line. (NB: The version that shipped with VC++ 6 was flawed in many horrible ways, but that wasn't really Dinkumware's fault given the compiler limitations at the time when they wrote that library; please don't judge them by that alone.)
• SGI's implementation of the "STL" parts of the C++ standard library is excellent, and well-documented on-line.

About the only decent on-line C++ tutorial I know of the electronic version of Bruce Eckel's "Thinking in C++" books. You can find a complete copy of these, and several of his other books, at his books web site. (He also has books on Java, C#, Python amongst other things, and all of his work I've read has been reasonably good.)

His webpage is Frontpage generated.

Please check the GotW site (here).
Here you can really check if you are a C++ expert. For instance, from the first Excexptional C++ book (here) you can find one of the deepest thinking about "exception safety".
Beleive me, I know tons of experienced C++ coders who don't know that a method who simply makes if-then-else and cout something on then and else branches can end in more than 20 different execution paths! (the topic is quite big, check the book... trust me, it's worth!)

Please check the GotW site (here).
Here you can really check if you are a C++ expert. For instance, from the first Excexptional C++ book (here) you can find one of the deepest thinking about "exception safety".
Beleive me, I know tons of experienced C++ coders who don't know that a method who simply makes if-then-else and cout something on then and else branches can end in more than 20 different execution paths! (the topic is quite big, check the book... trust me, it's worth!)

MS made a smart move hiring one of the most famous C++ guru, and moderator of "Guru of the week" (GotW, here).
(The Exceptional C++ books are selections from the GoW series).
I really think that this will enhance the MS' C++ offer quality, and including the GotW thinkabout in its future design is a kind of "bazaar" approach!... Funny!

MS should document every API and protocol.

MSDN has tons of documentation freely available. It's not 100% complete, but a good majority of developers can find what they need there.

They should work to ensure that Visual C can use GCC as its compiler, and that anything that the Visual C compiler can build can also be built by gcc.

Well, they're not switching to GCC, but I know they've hired Herb Sutter to serve as a liason to the C++ community. It looks like they're wanting better C++ standard support, which can only be a good thing.

They should include a rootless X Window server in future versions of Windows so that Unix (open and closed source) software can be ported to Windows more easily.

Why? What's the business reason that would help MS advance in the corporate world? "Because it's cool" is not the right answer here. Besides, we're talking about how MS can help the OSS community not those trying to port X Window apps to MS Windows.