Why C++ is vastly superior to C

[gwowen]

What I did find of course, is that huge programs tend to
trash around a lot jumping from one small method to the
next one...

THAT is surely a common observation.

Yup. That sounds about right.

 

[Stefan Ram]

Remember: premature optimization is the root of all evil.

The whole point of C++ is premature optimization, otherwise
one would use a programming language that is more safe,
simple, portable, and powerful.

I leave it up to you to decide whether this means that
C++ is the root of all evil.

 

[Rui Maciel]

The whole point of C++ is premature optimization

Why do you believe that "the whole point of C++ is premature
optimization"?


Rui Maciel

 

[gwowen]

  The whole point of C++ is premature optimization, otherwise
  one would use a programming language that is more safe,
  simple, portable, and powerful.

I don't think you comprehend what "premature" means.

 

[Rui Maciel]

Yes, you are right in principle. It is conceivable that a huge
program uses only a small fraction of its executable foot print
and all of it fits in the cache.

It is also conceivable that a program has a huge footprint but
it has almost no jumps so that its cache misses are exceptionally
low because when code is loaded all of it is used in highly
efficient loops.

And there could be more of those situations.

ALl I can tell you is that in my experience both the above
cases aren't found "in nature"...

What I did find of course, is that huge programs tend to
trash around a lot jumping from one small method to the
next one...

THAT is surely a common observation.

The reference to Belady's anomaly is based on the unavoidable fact that we
must deal with cache misses, which means that it applies to the cases we
do find, as you've put it, "in nature".

Based on that, what the Belady's anomaly shows us is that there isn't
necessarily a direct correlation between the number of page frames which
are used and the number of cache misses. This observation is independent
of what programs are running, and therefore how they jump around from one
method to another. No matter how common that observation is, from that
observation alone is still not possible to claim that the size of a
program is directly correlated to the number of cache misses, and
therefore how fast it is executed.


Rui Maciel

 

[Stefan Ram]

Why do you believe that "the whole point of C++ is premature
optimization"?

Design decision in C++ are usually decided in favor of
run-time efficiency.

For example, Java has decided to check array indices
at runtime, C++ not to.

»Learning C++ is equivalent to studying to be a NASA
test pilot. Its incredibly fast and effective, but takes
years to master the arcania and things tend to blowup in
your face if you're not very careful.«

Shinji Ikari

»I would rather compare it to learning how to drive a
racecar: yes, it can be fast. Most people tend to drive
it off track right away. Some people die in it.«

Matthias Blume

OOP: bind as /late/ as possible
C++: bind as /early/ as possible (generic programming)

Since this optimization is /always/ done, by pure /choice of
the language/, it can be called premature.

 

[hanukas]

I believe you didn't quite understood it.  The main point, which Belady's
anomaly demonstrates, is that there isn't necessarily a direct correlation
between how much cache a program takes up and the number of cache misses.
If it isn't possible to assume a direct correlation between how much cache
a program takes up and the number of cache misses then it isn't possible
to claim that a specific variation in a program's size has a specific
impact on how fast a program is ran.  If the subject being discussed is
the relation between a program's size and the influence that size may have
on how fast that program runs, particularly due to the number of cache
misses it generates, then it is obviously relevant.

Rui Maciel

In that case you choice of example algorithm to demonstrate the case
was not the best possible one; it only demonstrates paradox with FIFO.

 

[Joshua Maurice]

  The whole point of C++ is premature optimization, otherwise
  one would use a programming language that is more safe,
  simple, portable, and powerful.

  I leave it up to you to decide whether this means that
  C++ is the root of all evil.

The whole point of C++ is not premature optimization. One of its major
design goals, inherited from C, is to be a portable general purpose
assembly language. Part of that design goal is indeed optimization. If
that is premature depends on the particular program. While I'm always
a fan of measuring first, optimizing second, that maxim has its
limits. One is not going to write an OS in Ruby just to profile it and
rewrite the important parts in C. Writing software just doesn't work
that way. Sometimes choosing things up front for performance
considerations is /not/ premature. A classic example is you have to
decide pretty early if you want a single threaded, multi-threaded, or
distributed, application as that will have big impacts on your design
and code.

 

[Rune Allnor]

  Design decision in C++ are usually decided in favor of
  run-time efficiency.

  For example, Java has decided to check array indices
  at runtime, C++ not to.

      »Learning C++ is equivalent to studying to be a NASA
      test pilot. Its incredibly fast and effective, but takes
      years to master the arcania and things tend to blowup in
      your face if you're not very careful.«

    Shinji Ikari

      »I would rather compare it to learning how to drive a
      racecar: yes, it can be fast. Most people tend to drive
      it off track right away. Some people die in it.«

    Matthias Blume

  OOP: bind as /late/ as possible
  C++: bind as /early/ as possible (generic programming)

  Since this optimization is /always/ done, by pure /choice of
  the language/, it can be called premature.

You have to separate run-time from coding time:

Yes, you are right if you *only* consider run-time.
The binding that happens at run-time, through virtual
functions, in Java can also happen (but needs not) at
compile time, through templates, in C++.

But what's the problem with that? If the designer
*knows* at design time (prior to compile time) what
the application is supposed to do, what's the problem
with him using template code? Why force him to make
do with slow, lesser type-safe virtual functions if
a robust, fast alternative exists?

Of course, if some decision is made during program
execution what method or class to use, then the
late-binding virtual function is the correct tool to use.

But that's a different situation than the designer knowing
at design time what the program needs to do.

Rune

 

[Balog Pal]

»Learning C++ is equivalent to studying to be a NASA
test pilot. Its incredibly fast and effective, but takes
years to master the arcania and things tend to blowup in
your face if you're not very careful.«

Shinji Ikari

»I would rather compare it to learning how to drive a
racecar: yes, it can be fast. Most people tend to drive
it off track right away. Some people die in it.«

Matthias Blume

Quite true. But leads to the wrong implications. AAMOF the other languages
are not different, if you want to do actual industry stuff and not just
play.

Unfortunatley the most common approach to programming is still hacking away
before/instead of learning, and "trial an error". With C or C++ it will
blow your leg spectacularly. With other languages you more likely get some
error report.

But you still drive it off track, and keep it that way. And the difference
will be in whjat people "die" -- you push the problem on the client.

It would be time to face that software architecture is HARD. And that the
idea of uncle Fred writing his own fish shop software as presented in the
famous dBase III book will never happen. Regardless what languages and
environments are there. And working stuff needs huge amount of using brains
and discipline.

 

[gwowen]

  Design decision in C++ are usually decided in favor of
  run-time efficiency.

  For example, Java has decided to check array indices
  at runtime, C++ not to.

Really? What does .at() do?

  OOP: bind as /late/ as possible
  C++: bind as /early/ as possible (generic programming)

That's an statement utterly unsupported by reality. Are you suggesting
C++ doesn't allow OOP?

  Since this optimization is /always/ done,

Which optimisation? Early binding is done where possible, late binding
is done where necessary. Where's the optimisation.

 

[Michael Doubez]

  Design decision in C++ are usually decided in favor of
  run-time efficiency.

Design decision in C++ are nearly always driven by "you don't pay for
what you don't need".

IMO, this is not premature optimisation, it is common sense. Even
though, there is a trade-off with scalability of compiler extension
(such as array indices check).

  For example, Java has decided to check array indices
  at runtime, C++ not to.

Is it explicitly forbidden by the standard ?
I thought it was up to the compiler to provide it or not. IIRC Visual
has the option.

Java doesn't let you the choice.

      »Learning C++ is equivalent to studying to be a NASA
      test pilot. Its incredibly fast and effective, but takes
      years to master the arcania and things tend to blowup in
      your face if you're not very careful.«

    Shinji Ikari

I call that 'harnessing power'.

      »I would rather compare it to learning how to drive a
      racecar: yes, it can be fast. Most people tend to drive
      it off track right away. Some people die in it.«

    Matthias Blume

Well, the learning curve is hard. Much more so if you have a C
background.

  OOP: bind as /late/ as possible
  C++: bind as /early/ as possible (generic programming)

Are you talking about "name binding" vs "early bound method call" or
"compile time" vs "run time" ?

  Since this optimization is /always/ done, by pure /choice of
  the language/, it can be called premature.

Except if I work on a Java processor (or a LISP machine for that
matter).

And more generally, it depends on what you want to achieve, the
context, the domain, the scale of the software, the tools and all the
ilities driving the design.

I wonder how many times C++ is chosen for its performances; do you
have numbers ?

 

[Joshua Maurice]

      »Learning C++ is equivalent to studying to be a NASA
      test pilot. Its incredibly fast and effective, but takes
      years to master the arcania and things tend to blowup in
      your face if you're not very careful.«

    Shinji Ikari

Do you have a source or citation of some kind for this quote, where it
was first said? I'm just kind of curious curious for no particular
reason at all.

 

[Michael Doubez]

The whole point of C++ is not premature optimization. One of its major
design goals, inherited from C, is to be a portable general purpose
assembly language.

While the simplification seems to work, I don't buy that. C was first
designed as a *tool* for abstracting the underlying assembly language
but it has since evolved into a *language* that generates an
executable code.

We use our vocal cords (and our hands ) to communicate but it is
the language that carries the meaning.

The difference might be philosophical but I think it is important.

Part of that design goal is indeed optimization. If
that is premature depends on the particular program. While I'm always
a fan of measuring first, optimizing second, that maxim has its
limits. One is not going to write an OS in Ruby just to profile it and
rewrite the important parts in C.

I can write it in ruby and the use a ruby-to-bytecode tool (or a ruby-
to-C if it does not exists for my platform). Well, I theory.

IIRC there was some talk about an OS (from MS) which support
inspection and reflexion.

Writing software just doesn't work
that way. Sometimes choosing things up front for performance
considerations is /not/ premature. A classic example is you have to
decide pretty early if you want a single threaded, multi-threaded, or
distributed, application as that will have big impacts on your design
and code.

While there are some tension between some design values and optimality
of execution (see "Spending Moore's Dividend"), the two are not
necessarily exclusives.
IMHO the bet of C++ is to provide a language that scales from high
level requirements (modularity, policies, ...) down to low level next
to the metal. Some things don't have to be decided up-front but can be
delegated to higher-level policy without performance loss.

 

[Balog Pal]

Is it explicitly forbidden by the standard ?
I thought it was up to the compiler to provide it or not. IIRC Visual
has the option.

If we're talking about std::vector, it has .at() that checks and throws. It
has [] that makes oob access undefined behavior. Allowing implementation to
dfine it as no-op, as throw, as anything. What most implementations use for
diagnostics in debug build and no code in release.

Java doesn't let you the choice.

Yep. There is only one java way decided upward, puny programmers shall not
mess with decisions :-o

Indeed, Java seem to be created for "idiots" assumong that if they are
placed in a sandbox they will be productive. I didn't see much good coming
out of that experiment, just the expected gargabe in - garbage out.

And the few unfortunate sould who are out to do good job have to fight their
way against the wind.

 

[Jorgen Grahn]

....
Since this optimization is /always/ done, by pure /choice of
the language/, it can be called premature.

One day I'm going to have to write a paper called
"The phrase 'premature optimization' considered harmful" ...

/Jorgen,
only half joking

 

[Joshua Maurice]

One day I'm going to have to write a paper called
"The phrase 'premature optimization' considered harmful" ...

I'd fund it.

 

[hanukas]

Really? What does .at() do?

Doesn't look like array index to me.

 

[gwowen]

Doesn't look like array index to me.

No, it doesn't LOOK like an array index. Nevertheless, it *is* an
array index. And offering a checked and unchecked indexing doesn't
strike me as an optimisation at all, premature or otherwise.

http://www.cplusplus.com/reference/stl/vector/operator[]/
http://www.cplusplus.com/reference/stl/vector/at/

 

[Keith H Duggar]

One day I'm going to have to write a paper called
"The phrase 'premature optimization' considered harmful" ...

Thank you. That phrase is being used by the ignorant masses in
a manner only marginally less moronic than "conservatives want
to starve autistic children to death".

KHD