Linked by Thom Holwerda on Fri 28th Oct 2005 11:17 UTC
Hardware, Embedded Systems Herb Sutter, a software architect from Microsoft, gave a speech yesterday at In-Stat/MDR's Fall Processor Forum. Addressing a crowd mostly consisting of hardware engineers, he talked about how the software world was ill-prepared to make use of the new multicore CPUs coming from Intel and AMD.
Permalink for comment 52631
To read all comments associated with this story, please click here.
Member since:

Funny, those are the issues Sutter (and others) are bringing to the C++ committee--that the language will have to address threads explicitly, even if it harms the single-threaded case.

I'm not talking about threads. Native thread support in C++ won't make parallel code any easier to write than it is in Java. I'm talking about basing the language on an explicitly concurrent model of computing. The precise computing model to use is still an area of intense research, but Pi calculus (as used in Polyphonic C#), seems to be a popular one.

And excuse me if I don't trust the same people who came up with auto_ptr (and encouraged shared_ptr) to come up with a proper parallel C++.

Additionally, his arguments finally convinced me that GC in C++ is a good thing.

But you'll never be able to have a good GC in C++! As long as you can convert an integer into a pointer, you'll need a conservative GC, and that makes a lot of the really high-performance GC algorithms unusable.

And I'm confident he's familiar with the C# efforts.

Polyphonic C# is a seperate research project being funded by Microsoft --- not a part of their main C# effort.

Since C# has some problems in the MT arena (all languages do) I don't see why it has a better chance at addressing MT issues than C++ does.

The standard committe is likely to be the primary reason why any concurrency concepts in C# will suck (just as the metaprogramming concepts suck). They refuse to break compatibility with "classical" C++ and C, and are thus stuck to using inferior solutions. Moreover, pointers and guarantees of byte-level object layout will likely become another issue. For the overhead of a truely parallel language to be tolerable, you'll likely need powerful optimizers, which are exceedingly difficult to do in a langauge that makes as many guarantees about memory layout as C++ does. Hell, C++ can't even support a compacting GC!

Reply Parent Score: 1