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.
Thread beginning with comment 52595
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Pay attention to Herb Sutter
by rayiner on Fri 28th Oct 2005 20:01 UTC in reply to "Pay attention to Herb Sutter"
rayiner
Member since:
2005-07-06

I don't know if a C++ guy is the best one to spearhead this whole movement though. The ISO C++ folks go to comical lenghts to avoid overhead, and like it or not, doing parallel code properly is going to impose significant overhead in the single-threaded case. When the C++ folks attempted to handle automatic memory management, their "no overhead" philosophy resulted in a technique (smart pointers), that manages to be much slower than GC on some benchmarks: http://www.hpl.hp.com/personal/Hans_Boehm/gc/04tutorial.pdf (pgs. 53-55).

C++ won't cut it for writing good parallel code (Lisp likely won't either, so there). Languages will need to be redesigned, at the level of their basic computational calculus, to do parallel code support properly. Microsoft is doing some research into their area (Polyphonic C# applies Pi calculus to C#). These efforts may produce the necessary results.

Reply Parent Score: 1

emarkp Member since:
2005-09-10

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.

Additionally, his arguments finally convinced me that GC in C++ is a good thing. He has also been one of the people working on a GC model for Managed C++ which separates object lifetime (which can be deterministic) and memory reclamation.

And I'm confident he's familiar with the C# efforts. 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.

Reply Parent Score: 1

rayiner Member since:
2005-07-06

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