[Beowulf] Stroustrup regarding multicore

[Peter St. John]

VIncent,
I wouldn't look to Stroustrup for guidance about multicore (I'd look to RGB
:-) but he defines C++ and the C I use is a subset of the C++ copmpiler
(genrally)  But yeah, to me C++ is bloaty: compare Stroustrup's gravid
classic to K&R's gemlike classic..

I mostly write in C, with the sense that basically it saves me writing in
assembly; and most of us, maybe all, use only a subset of C++; which can
pare down to K&R (within a whisker) if you like. Something like C with
Classes seems like a good middle ground between hierachism for the
programmer's comprehension and spare C for the machine's.
Peter

On 8/25/08, Vincent Diepeveen <diep at xs4all.nl> wrote:
>
> Well Stoustrup should be the last speaking about multicores, he better
> stick to single core.
>
> Let me explain.
>
> The experience learns that most C++ code from BIG companies not to mention
> organisations is factor 5 to 50 slower
> than an imperative implementation. Templates get used to declare variables
> and classes are very deep, not seldom
> 10 subclasses deep before you actually see a few lines of code doing
> something, and you
> never know which object gets allocated now and deallocated there.
>
> Therefore for highend computations C++ is not very interesting.
>
> Add to that, the C++ standard (iso) where Bjarne has contributed to a lot
> (deep respect for that),
> costs hundreds of dollars to buy,
> so there is no clear hard definition easily available to programmers at
> home to figure out the optimization
> limitations that C++ allows. To get speed you need to know the exact
> borders which compilers must follow.
>
> int a = 5;
> unsigned int x = 2;
>
> if( a == x )
>
> how C treats the above is easy. how does C++ treat it?
> Do you know?
>
> To program code for speed you need to know the EXACT limitations of a
> language.
> Clear definitions, not 5000 pages with what the language all "might be able
> to do for you".
>
> No one who learns at home is gonna pay to get that ISO of course and the
> language is getting that complex and even more
> complex, that programmers who try to learn it are busy half their life
> learning it. After many years, just knowing how to code C++,
> they already are too old to program a lot and feel ready to become
> teamleader or manager. This is because C++ is the most
> complex programming language on the planet. It has changed. I've got some
> C++ books from start of 90s here and none of them
> mentions things like templates.
>
> The C++ from the 90s was very useful for companies, had it been
> standardized sooner.
>
> Bjarne made c++ too complex however.
>
> College students who start C++ now, directly start using templates and
> never learn how to actually DECLARE a variable anymore.
>
> Object orientation is the opposite of what modern processors are good at.
> First of all object allocation and deallocation is real
> slow and even the best C++ programmers have problems limiting the number of
> allocations that makes their software real slow.
>
> Additionally putting together code and data, as well as things like
> templates, makes code sizes real massive huge.
> This where for crunching power we'll see more and more tiny processors
> where having a lot of code is just slowing down.
>
> That said, C++ has basically a number of advantages over JAVA and C#.
> Graphical you can do the same in visual studio
> with C++ like you can do with c++, so there is no reason to program in C#.
> In C++ you CAN incorporate C code easily
> as well as compiler intrinsics, even entire assembler programs (gcc). So
> you DO have the choice to hire a programmer who
> can speedup your code.
>
> The good C++ programmers who are really good in getting code done, usually
> have a low grade highschool,
> no university or at most 1 year college or so, if at all and know relative
> little about algorithms let alone optimization techniques.
>
> That's your typical C++ coder. Bugfree code that's ugly slow.
>
> Over the past years i've helped out dozens of PHD's who didn't know how to
> speedup their C++ code at all. Not even where to start.
> They know books from Stoustrup from head though and are in the knowledge of
> all kind of details. Usually not seldom within days
> that results in factor 2 to 3 speedup.
>
> Writing yet another book with things that even most C++ scares in C++0x is
> not very interesting IMHO, and just shows how much of
> a nerd a person can become.
>
> I'd argue there is a big need for a new language that is basically
> imperative, where there is mechanisms, but not necessity,
> to split code and data, where you can declare anywhere new temporarily
> variables, and which has the potential to get the same
> speed like C code and where the language constructs are not far away from
> C/C++, to get programmers not extra confused.
>
> So instead of C++ something like Cr with the 'r' of 'realistic'. Something
> that is really usable for companies to get fast code
> at tiny processors meanwhile compatible with C libraries, which dominate
> the open source world, with good reasons.
>
> So just the basic minimum that you need to make out of C a language that
> big companies can use, without losing speed.
>
> Speed matters for mass software and highend.
>
> C++, JAVA and C# are just too slow to take a lecture with the below name
> serious.
>
> Instead of trying to standardize the manner how to write a program in C++
> writing in clear statements that all kind of complex C++
> language such as templates should get avoided at all costs, except when it
> has a clear benefit that other simpler straightforward code
> doesn't offer the opposite is gonna get spoken out in the speech.
>
> What happens now with C++0x  is yet another nerd addition to make worlds
> most complex language even more complex.
>
> Vincent
>
> On Aug 22, 2008, at 6:31 PM, Peter St. John wrote:
>
>  In this interview http://www.devx.com/SpecialReports/Article/38813/0/page/1
>> Bjarne Stroustrup  talks about  an upcoming C++ ISO standard,  C++0x  (the
>> same nomenclature as "C89", "0x" means the specific year is undecided, it
>> doesn't mean hex :-).
>>
>> He categorizes the additions in three ways, Concurrency, Language, and
>> Libraries; the concurrency part is about multicore support.
>>
>> He writes, 'Basically, the "concurrency" features will standardize the
>> basic layers needed to do systems programming in a multi-core world.
>> Obviously, facilities for doing that already exist in C++ implementations,
>> but they are not standardized. I'd have liked to see library support for
>> some high-level concurrency models, but the committee didn't have the time
>> or consensus for that.'
>>
>> Peter
>> _______________________________________________
>> Beowulf mailing list, Beowulf at beowulf.org
>> To change your subscription (digest mode or unsubscribe) visit
>> http://www.beowulf.org/mailman/listinfo/beowulf
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.beowulf.org/pipermail/beowulf/attachments/20080825/057fbec8/attachment.html>