ambiguous ?

[T. William Wells]

I've decided not to redirect this article to alt.flame, since Mr.
Giles apparently doesn't understand the purpose of doing my so,
and so that we can continue to watch him make a fool of himself.
:-(

In article <14109 at lanl.gov> jlg at lanl.gov (Jim Giles) writes:
: > You see, if you knew beans about C optimizers, [...]
:
: And you do, I suppose?  Then you can explain why you think C is
: faster than other languages in spite of the fact that it is inherently
: harder to optimize.

Don't put words in my mouth. As Doug has already pointed out, your
assertion, NOTE, YOURS NOT MINE (you goddamn hypocrite, yes, I've
seen your flames), is not always true.

As it happens, I *do* know a bit about C optimizers. And yes, by
and large, many, if not most, C optimizers are piss poor. But not
all of them. Some of them produce code that is very good. And for
certain applications, beat hell out of any Fortran compiler.

But the primary reason for the general relative efficiency of
Fortran and C compilers can be summarized in one word: history.

Fortran compilers have been around a lot longer than C compilers.

Fortran has also traditionally been used in applications where
any improvement in the optimizer translated into important gains
to the users. C has traditionally not been used in such. People
have generally had more of an incentive to work on Fortran
compiler optimizers than C's.

With the advent of graphics systems and the other munchers that
are becoming common, and with the push to make C as convenient
for numerical applications as Fortran is, I suspect that you'll
see this difference, where it exists, narrow and disappear.

:                      Once a program has been parsed and is represented
: by an abstract syntax tree (or some other intermediate representation)
: it is nearly impossible to tell what language the original source was
: in - except C which has more aliasing and potential dependencies than
: most other languages.  Also, C's character processing is less efficient
: as well.  In those respects that are important to compiling, C is
: nearly identical to most other imperative languages.  In those respects
: where it differs, it is harder to optimize.

A mishmash of true and false statements.

There are several things representable in C, things that are
important in the kinds of things C is often used for, that are not
easily representable in other languages, and so don't show up in
their syntax trees. Not only that, you are confusing the standard
methods of character (or did you mean string?) processing with
what is actually possible in the language.

When those attributes are important, C beats hell out of any
other language. When not, it depends. To those of us who
understand the language, the things that you mentioned that
happen to be true come as no surprise; we stopped debating them
ages ago. You certainly don't have anything new to tell us about
them.

: > You may have knowledge, but you are lacking in C wisdom.
:                                                  ^^^^^^^^
: Is that the peculiar mental condition which prevents you from discussing
: an issue without resorting to abuse?

What issues? Your whines about C? So far I've seen nothing from
you worthy of discussion.

Maybe if you actually learned something about the language as it
is actually used, and the techniques that competent programmers
have evolved to deal with C's known deficiencies, you might have
something to contribute. But so long as your comments are
directed to issues that have been resolved long ago, or are based
on theoretical grounds that have no bearing on practical use of
the language, or are directed to changing the language in ways
that will break significant amounts of existing code, you have
nothing to say that is worth my time to hear.

And argument by repetition will only draw flames.

---
Bill                    { uunet | novavax | ankh | sunvice } !twwells!bill
bill at twwells.com