Re: Order of argument evaluation in C++, etc.

ka@socrates.hr.att.com (Kenneth Almquist) writes:
> I'm surprises that David Chase isn't familiar with compilers which
> take advantage of the permission to evaluate arguments in arbitrary
> order in order to generate better code. The basic idea is [Sethi-Ullman
> numbering].
> ... This idea is not new; the first two compilers for C (the Ritchie
> compiler and PCC) both used it [or something similar].


> So in the absence of register windows (which seem to have fallen out
> of favor) requiring left-to-right evaluation will force a compiler
> to generate non-optimal code for the above example. This does not
> answer David Chase's request for quantitative measurements ....


Sadly enough, no compiler that I know of actually generates "optimal"
code, for a variety of reasons (*). This one little frob is unlikely
to make a difference that anyone would usually notice (though I, too,
lack measurements to back this up), and if it did, those users who
care would detect it when they profile their code (if they don't
profile, they don't really care) and fix the order of evaluation
manually. Therefore, all that is really lost is the automatic
application of this apparently-minor optimization, and what is gained
is portable, reproducible behavior.


(*) everything from users' demonstrated inability to read and follow
instructions, to interlanguage compatibility constraints, to plain
old expense of most-accurate analysis, to impossibility of perfect
analysis, to time-to-market constraints on engineering. Note, too,
that performance is also "lost" to other rules forced on the compiler
by a language standard. If the C standards committee really cared
about (and understood) performance as much as some people seem to
think, then we'd have "noalias" or something like it.


Optimality of code also no longer depends simply on number of
registers used. The cost of a register is at most the cost of a
spill and reload, which can be scheduled with great freedom. Even if
it costs, it doesn't cost much.


I'm also a little amazed to be encountering such resistance to a
well-defined order of evaluation in this decade. The last three
places that I've worked, people talk about "quality this" and
"reliability that" and about the importance of development
procedures, and things like ISO 9000. I've talked to people who work
for other companies, and they discuss various interesting things that
they do with defect-tracking to ensure that products ship with few
bugs. One important part of bug tracking and bug fixing is
reproducible behavior (if nothing else, the less things can vary, the
less you have to test for a given amount of reliability). I've even
heard people discuss hardware and instruction-set architecture
changes to increase the determinism of program execution. I've heard
of people producing applications for which the most important things
are reliability and time-to-market -- they ship debuggable binaries,
giving up a factor of 2 in performance (at least). You'd think that
this sort of thing was REALLY IMPORTANT, much more than some
apparently insignificant, sometimes-used, never-measured option to
optimize code.


speaking for myself,


David Chase
--

Return to the comp.compilers page.
Search the comp.compilers archives again.