P
pete
Eric said:
http://www.google.com/search?hl=en&ie=ISO-8859-1&q="redundant+backup+systems"
Results 1 - 10 of about 959 for "redundant backup systems". (0.19
seconds)
http://www.google.com/search?hl=en&ie=ISO-8859-1&q="redundant+backup+systems"
Results 1 - 10 of about 959 for "redundant backup systems". (0.19
seconds)
C
Clever Monkey
"... without resorting to special compilers, optimized libraries or
clever optimzation techniques."
They are special in the sense that they are specific implementations
intended for a specific audience. The point of Fortran was that
ordinary code written in a portable fashion should perform reasonably
well under most implementations.
I'm not getting involved in this holy-war. Use the best tool for the
job. If you need the kind of grunt required to run non-trivial math
over the course of days or weeks, do your own benchmarks.
My only point was that it is not crazy to make the statement that
Fortran may emit code that performs better than the equivalent algorithm
implemented in C. In general, this has been true. Whether or not you
can find the right implementation, library or technique to find a case
where this general trend is reversed is not all that important.
Specific comparisons between specific implementations are important
considerations, and there are some modern benchmarks posted (I can't
find the link, sorry, but Google should have it) comparing Intel's C
compiler, a recent gcc implementation and Fortran-90. Given a variety
of hard problems, Fortran consistently came up much faster with default
code and no explicit optimizations.
Your other comments were addressed else-thread, I think.
C
Chris Torek
Before I add to this, let me say that my earlier posting in the
thread was indeed sarcastic/flip. I probably should not have
posted it.
(There was a real point to it, mostly being: "If you use a C++
compiler, you are compiling C++ code. It may also happen to be C
code, and it may even have the same semantics in both languages,
but it is still C++ code." Note that "having the same semantics"
is not as common as "compiles in both languages".
Personally, I think if one intends to compile with C++ compilers,
one might as well make use of various C++ constructs. For instance,
templates are actually quite valuable, in spite of their horrific
syntax.
)
Indeed. It may -- and some may hope that it does -- become less
true, especially now that C99 has "restrict". But traditionally
it seems to have beem the case. (One possible reason I offer here
is that, on many machines, particularly the mini- and micro-computers
commonly used in the 1980s and early 1990s, it is easy to compile
C code to "relatively OK" machine code without bothering with much
if any optimization, and at the same time, C's aliasing rules often
make it hard to do a great deal of optimization. The same does
not hold for the Fortran of the time -- F77 -- so compiler-writers
*had* to put in *some* optimization, and then had no barriers to
putting in more optimization.)
thread was indeed sarcastic/flip. I probably should not have
posted it.
(There was a real point to it, mostly being: "If you use a C++
compiler, you are compiling C++ code. It may also happen to be C
code, and it may even have the same semantics in both languages,
but it is still C++ code." Note that "having the same semantics"
is not as common as "compiles in both languages".
Personally, I think if one intends to compile with C++ compilers,
one might as well make use of various C++ constructs. For instance,
templates are actually quite valuable, in spite of their horrific
syntax.
)Indeed. It may -- and some may hope that it does -- become less
true, especially now that C99 has "restrict". But traditionally
it seems to have beem the case. (One possible reason I offer here
is that, on many machines, particularly the mini- and micro-computers
commonly used in the 1980s and early 1990s, it is easy to compile
C code to "relatively OK" machine code without bothering with much
if any optimization, and at the same time, C's aliasing rules often
make it hard to do a great deal of optimization. The same does
not hold for the Fortran of the time -- F77 -- so compiler-writers
*had* to put in *some* optimization, and then had no barriers to
putting in more optimization.)
E
Eric Sosman
pete said:
Not 100% sure what point you're making, but in case it's "lots
of programmers use `redundant' without meaning `unnecessary'," let
me point out that lots of programmers use "kilo" as if it meant 1024.
P
pete
Eric said:
It's not just programmers.
"Redundant backup systems" is an engineering term.
http://www.google.com/search?hl=en&lr=&ie=ISO-8859-1&q="redundant+backup+systems"+aviation
Results 1 - 10 of about 94 for "redundant backup systems" aviation.
http://www.google.com/search?hl=en&lr=&ie=ISO-8859-1&q="redundant+backup+systems"+steam
Results 1 - 10 of about 54 for "redundant backup systems" steam.
http://www.google.com/search?hl=en&lr=&ie=ISO-8859-1&q="redundant+backup+systems"+nuclear
Results 1 - 10 of about 122 for "redundant backup systems" nuclear.
R
Richard Bos
Eric Sosman said:
YM ahead.
And even then it never did, and it still does not, mean "useless".
Something that is repeated, even something that is repeated
unnecessarily, may well be repeated usefully. People who use "redundant"
to mean "useless" are wrong now, just as they would have been back then.
Richard
W
websnarf
Clever said:
Exactly what *specific* audience do you think Microsoft's C compiler is
for? Its the default compiler for anyone developing applications on or
for a Windows machine. In terms of developer audience, there couldn't
possibly be even a close second with the exception of gcc (which may in
fact have a wider audience; I really don't know how they compare in
that sense). And Intel C/C++ started as a specialist (for video games,
and specific applications where Intel wanted to look good on a
benchmark) compiler, but certainly by today, its a totally mainstream
compiler whose target audience is basically just anyone who is looking
for a high quality and high performance C compiler. There's nothing
special at all with their audiences, except that MS is tied to Windows
(most of the Unix cc's are in the same boat). (Intel's compiler runs
on Linux, Windows and the recent Mac OS Xs.)
That may be your point (and is only true if by ordinary code you mean
algorithms that use only arrays of floating point numbers, and
targetting compilers from half a decade ago). But that's not the
statement Chris made.
Been there, done that. By modern standards Fortran no longer offers
anything that C doesn't (except being a simpler language.)
That's fine if that was the point originally made. In fact its hard to
contend with this except for the special example of the Intel compiler,
because of its common back-end for the two languages coupled with its
benchmark leadership in both languages.
But that's *NOT* the point that was made. Chris just say that "Fortran
was even faster". And that's just utter nonsense (as a blanket
statement, that's basically never been true, and by today's standard
you cannot put together a fair case.)
With an emphasis on *HAS BEEN*. Its basically no longer true.
Like picking a modern compiler and turning on a switch? (The "no
aliasing" switches have been sitting in C compilers since the early
90s.)
This is what google returned to me:
http://shootout.alioth.debian.org/gp4/fortran.php (Fortran is way
slower)
Obviously using "g95" is highly suboptimal, but more googling didn't
reveal anything else of relevance to me. My understanding comes from
directly analysis of the compiler output and mating the language's
capabilities to them.
W
websnarf
Chris said:
That isn't the point of contention. Its that you used this sarcastic
guise to cover up two blatant deceptions.
That couldn't be your point, because you didn't say anything remotely
similar to that.
Perhaps you would like to discuss this with Richard Heathfield. He
apparently has a very strong opinion about discussion of C++ in this
newsgroup. You and he are the only people in this thread who have
brought up the discussion of the C++ language here. (Personally, I
just notice that there are other C++ newsgroups, and that C++ experts
don't tend to hang around in this newsgroup, so why would I try to
discuss C++ here?)
There is a very big difference between using a C++ compiler, and using
the C++ language. This is a very special case because of the very
large intersection of C and C++. I made the very clear point that the
better C compilers are, in fact, C++ compilers (both from an object
code output and a diagnostics point of view). This is the most obvious
thing in the world, and clearly was I was talking about. Any imagined
discussions about the C++ language here are from people *OTHER* than
myself.
[...] For instance,
templates are actually quite valuable, in spite of their horrific
syntax.
You are being off topic for this newsgroup.
R
Richard Heathfield
(e-mail address removed) said:
The first message in this thread that I can find that talks about C++ is
Message-ID: <[email protected]>
"And, of course, the real difference is that the first compiles straight
in C++, and the second is just an error. I have found that in general
the C++ optimizers and warnings are better for the C++ mode of my
compilers than the C mode."
And you posted it.
If you invoke a C++ compiler, it will interpret your source according to the
rules of C++, not C. If that's what you want to do, that's fine, but
discussions of C++ compilations belong elseNet, not in comp.lang.c.
It is also obviously wrong. Trivial examples (e.g. int new easily disprove
your point, so there is no particular need to find complicated examples.
See above quote.
Indeed he is. And so were you.
The first message in this thread that I can find that talks about C++ is
Message-ID: <[email protected]>
"And, of course, the real difference is that the first compiles straight
in C++, and the second is just an error. I have found that in general
the C++ optimizers and warnings are better for the C++ mode of my
compilers than the C mode."
And you posted it.
If you invoke a C++ compiler, it will interpret your source according to the
rules of C++, not C. If that's what you want to do, that's fine, but
discussions of C++ compilations belong elseNet, not in comp.lang.c.
It is also obviously wrong. Trivial examples (e.g. int new
easily disprove your point, so there is no particular need to find complicated examples.
See above quote.
[...] For instance,
templates are actually quite valuable, in spite of their horrific
syntax.
You are being off topic for this newsgroup.
Indeed he is. And so were you.
I
Ian Collins
Another situation is where one uses C++ constructs to instrument or addChris said:
testing functionality that can not be accomplished in C without
intrusive test code to an application under test. Provided one is happy
to live with the constraints of the common subset of the two languages,
this can be a powerful development tool.
For instance,
templates are actually quite valuable, in spite of their horrific
syntax.
Thank goodness for typedefs!
W
websnarf
Richard said:
Just as a person cannot be described by the color of their toenail, I
don't see this as a discussion of the C++ language. My bringing this
up is obviously narrowly focussed on the usage of a C++ compiler as a
tool to compile C code. I mean C++ is a language with really a lot of
features; using the compilers for generating better output for C code
is not something anyone thinks of as a language feature.
Yes, but this is just a natural characteristic of the tool. It
doesn't, by itself, make your code into C++ code.
But, its compiling C, just using a different tool. Are you suggesting
then, that discussion of the usage of LINT is off topic for this
newsgroup as well?
It is also obviously wrong. Trivial examples (e.g. int new
your point, so there is no particular need to find complicated examples.
What the hell are you talking about? That example (or more complicated
ones which invoke those sorts of anomolies) would not be in the
intersection of C and C++. And clearly I am not advocating the
creation of polyglots with different semantics from different
languages.
The quote makes no mention or implication about any C++ language
content.
[...] For instance,
templates are actually quite valuable, in spite of their horrific
syntax.
You are being off topic for this newsgroup.
Indeed he is. And so were you.
You have provided no evidence of this claim.
O
Old Wolf
Sorry, you're right -- it was in fact Richard Heathfield who
made that comment. I transfer my pox to him.
O
Old Wolf
You're on a different world to the rest of us. Since there exist
C programs with identical source to C++ programs, but
different semantics, it follows that a C++ compiler cannot
simultaneously be a C compiler, as you are claiming.
Are you trying to make the point that the developers of the
better C compilers, also develop C++ compilers? If so, then
that isn't even relevant to the discussion.
K
Keith Thompson
Old Wolf said:
It's possible that a compiler could act as either a C compiler or a
C++ compiler depending on how it's invoked. gcc does this, but I
don't know how much code is shared between the C and C++ modes.
R
Richard Heathfield
Old Wolf said:
Keep it, Old Wolf. You might need it some day. If you look more closely at
the original discussion, you'll see that it initially centred around the
word "superfluous", which websnarf introduced to describe his own code.
Keep it, Old Wolf. You might need it some day. If you look more closely at
the original discussion, you'll see that it initially centred around the
word "superfluous", which websnarf introduced to describe his own code.
C
Chris Torek
The preprocessing and code-generation/optimization phases are
shared. The code for building the parse trees, i.e., assigning
semantics based on syntax, is (unsurprisingly) not shared.
(Saying that the code generation is shared may be a little bit of
an overstatement. Without getting into details, it is difficult
to describe the process and the shared vs separate parts. There
is only one "machine description" per target, however, and it
includes all the code-matching/generation patterns, even if some
are never actually used from the C compiler -- e.g., there is no
need to emit "exception handler frames" for C code.)
O
Old Wolf
Richard said:
You wrote earlier:
which is certainly true, if you take one of the many meanings of
"redundant". Note that you introduced this usage of "redundant".
You then wrote, in response to Paul Hsieh:
Clearly he is referring to one of the other meanings of "redundant",
in particular, one in which redundant things can be useful.
O
Old Wolf
Richard said:
[Note - that was in fact a misattribution; that statement wasn't
made by Paul]
If many people think a word means something, then they are
correct by definition. The meaning of words isn't set by some
authority. Instead, dictionaries try to reflect actual usage.
There are thousands of words (probably more) in current usage
today that had different meanings decades ago. It's called
language evolution.
FWIW, from dictionary.com:
re·dun·dant /rɪˈdʌndənt/
–adjective
1. characterized by verbosity or unnecessary repetition [....]
K
Keith Thompson
Old Wolf said:
I'm not going to take sides on that issue, but I'll mention that it's
controversial; detailed discussions about the meanings of English
words are welcome in some other newsgroup.
But I will point out that, even as a new meaning for a word becomes
common, it is a fact that some people will continue to use it with its
old meaning. There are plenty of uses of the word "redundant" that do
not imply that something is unnnecessary; see "redundant backup
systems". See also "byte".
M
Mark McIntyre
This is a false conclusion. Just becase thousands of ignoramuses think
"enormity" is a symonym for "huge", don't make it so.
to an extent, but only to an extent, and always in broad terms not
colloquial ones.
Note the word "or". Not "and". So far as I'm aware these are not (yet)
synonyms.
--
Mark McIntyre
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan