Vincent,
I have always said that C++ is computational science's cold fusion:
lots of power in, but no net gain.
C is not much better. I once worked a young computational programmer
for almost a week to get him to prove to himself that a C source
program couldn't walk through a 2-d array the hard way as fast as a
Fortran source program unless the stepping was coded by hand. He
didn't believe that a 2-d array in C is syntactically a 1-d array of
pointers to 1-d arrays, and the row pointers must be fetched from
memory! And separate compilation of functions with variable array
dimensions? I hear echoes of Kernighan and Ritchie laughing with
each other "We don't need no steenking libraries with execution-time
array dimensioning! We're system programmers here! Besides, if
somebody needs that they'll use Fortran."
Sure, you may be able to use C++ to add reasonable array behavior to
C. But that's like writing a yacc script to build a compiler for a
language in which you can write your entire program with a single
executable statement.
Mike
At 11:36 AM 8/25/2008, you 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>>_______________________________________________
>Beowulf mailing list, Beowulf at beowulf.org>To change your subscription (digest mode or unsubscribe) visit
>http://www.beowulf.org/mailman/listinfo/beowulf
{Dad, Mike}
________
The notation {option1, option2} means choose option1 or option2, and
comes from the era of command-line computer programs and their documentation.
NYLLP = New York Local Liberal Paper aka The N__ Y___ T___s.
Tinfoil Hats = Tin-foilers = Wackos of the Democrat base who think
hatred of Bush is a political principle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.beowulf.org/pipermail/beowulf/attachments/20080826/efbc2504/attachment.html>