Very well, then; but please don't cross-post this to c.l.c++. For me,
the Eiffel side of this discussion is much more relevant than that from
the knee-jerk defenders of <that other language>.
Quote:
> | Another barrier to overcome would be performance. Eiffel code is
> | noticeably slower than equivalent C/C++ code; adding the overhead of
> This is not my experience. Eiffel programs compiled with the
> TowerEiffel optimizer routinely benchmark roughly the same as
=======
Eiffel/S only, and only on somewhat trivial "test-this-or-that"
programs. If I were to time my (what does ISE call it? thawed?)
unoptimized Free ISE Eiffel code, the discrepancy would probably be
higher.
Quote:
> equivalent C++ programs (usually within 10-15% -- sometimes slower,
> sometimes faster). Customers have reported doing experiments where a
> design is coded in idiomatic Eiffel and C++. Much to the project
> leaders' surprise, the Eiffel versions often actually out-perform the
> C++. I can't supply details on any particular tests, but these
> results are not particularly suprising to me.
=========
Alas. Hard facts -- numbers, plus relevant details of implementation and
environment -- would be useful.
Quote:
> C++ is full of hidden
> inefficiencies (constructor overhead, implicit copy constructors,
> etc.)
=========
Eiffel has creation methods, so I expect this comparison to be less than
meaningful. That you call them explicitly, without name overloading, is
hardly relevant to runtime performance. As to the nuts and bolts of
programming, some C++ programmers are less aware than others of when
temporaries might be constructed. This, leads us to object ref's,
discussed below, and awareness, also discussed below.
In terms of hidden costs, some programmers I worked with (and I
similarly at one point) split hairs to avoid the cost of virtual
functions. While I don't applaud their attention to detail, this brings
to light certain costs involved in indirection. I believe the default
mode (only mode?) for Eiffel methods requires indirection. This might
actually be a plus for usability (but not performance) when the compiler
can recognize statically when indirection is not required; I expect C++
programmers will be more consciously aware of this possible cost than
Eiffel programmers.
Is this enough to make a difference? I would guess yes; the magnitude
varies from small to miniscule perhaps, on the side of C++.
Quote:
> And its lack of garbage collection encourages a "make a copy of
> everything" style of programming which is inherently slow.
=========
Hardly. Very usually, GC is fully emulated with a very thin wrapper
around {*filter*} pointers. This equates to the same functionality and
probably equivalent overhead of Eiffel object ref's. When you consider
that many objects need not be dynamically allocated, the savings add up
to some measurable sum. As for copying objects, even the more primitive
compilers optimize away the need for a copy; the returned object is
constructed in the caller's memory space.
Like you, I have no statistics or citations to back up the following. My
gut feel, though, is that roughly half the object use in C++ are local
objects. These equate to Eiffel expanded locals, and do not require
dynamic allocation. This is the default mode for locals in C++; memory
is not dynamically allocated, nothing is garbage collected. The default
mode for Eiffel is object ref's, requiring dyn. allocation and
subsequent garbage collection. I suspect at least a moderately lower use
of expanded locals than in C++, simply because GC and the default mode
"obviates" the need.
Quote:
> C++
> programmers seem to _think_ that C++ is fast (it looks like C, one has
> to manually deallocate memory, it feels like you're programming "close
> to the metal", therefore it must be fast, right?), but is it really?
=======
Was this rhetorical, or are you asking *me* for citations?
In a larger sense, Eiffel, Java, VB, and their ilk lower the entrance
requirements relative to C++. The syntactical elements of programming in
these languages reputedly have a gentler learning curve than C++. Thus,
a programmer with relatively low experience is able to produce average
work somewhat more quickly. To be similarly rhetorical, is this
necessarily a *good* thing?
The system knowledge -- that larger body of understanding what a program
is doing -- remains as large and foreboding as it ever was. Some
implementors manage to climb the curve eventually, regardless of the
language they use. When they reach that point, being able to program
"close to the metal", as it were, might become meaningful. The key
phrase there was "being able to", as in "empowered", unlike "required
to", and as distinctly opposed to "prevented from." In context of
understanding the system behind the program, is it necessarily a good
thing to hide the inner workings? Wouldn't this slow the larger learning
process?
Being aware of what a line of code does goes far beyond the impact of a
local inefficiency. There really is no shortcut to understanding what
the system is doing, and this remains largely language independent.
Programming for performance is a parallel skill to understanding
abstractions. They are not contradictory, and at least one language
allows me to express both very efficiently and eloquently. Can you say
the same about <your favorite programming language>?
I believe that Eiffel and C++ are more alike than they are different. A
poor understanding of abstractions leads to bad designs in both. A poor
undestanding of performance dynamics leads to slow systems in both.
There are rare opportunities where the flexibility of C++ will make a
difference in the outcome. More importantly, though, C++ obscures less
of the internal workings, allowing (not forcing) a deeper understanding
of certain interactions.
There comes a point in building any system when matters become less one
of design abstractions, and more one of implementation pragmatics.
Eiffel only gets you 90% of the way there in this sense. Unfortunately,
that last 10% only helps those systems that are properly designed in the
first place. It's not a matter of 10% more effort at the end; it's a
matter of applying pragmatics throughout the implementation, without
sacrificing abstraction. This is where experience and awareness are
necessary. In other words, this is language independent, but again, for
the reasons given above, the advantage falls ever so slightly on the
side of C++.
Quote:
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> C++: One million lemmings can't be wrong.
:) I eat less red meat than I used to. Do you? Why or why not?
Mike.