Mark said:
OK, Sidney, I am considering it. I can certainly understand the premise
that a group might choose to entertain ONLY those questions that can be
resolved purely by a reading or clarification of (drum roll please) The
Standard.
That's a good summary; the drum roll surely adds a touch of class to it.
But how utterly boring, and what a waste of talent.
The first is a subjective assessment, I'll just disregard that if you
don't mind. The second I think is not true: most people here of course
do have more talents than they can expose here, simply because they
abide by the subject that is topical here, which is standard C. No
talent is wasted, it's just exposed in the proper setting.
It reduces the newgroups participants to a mere gaggle of lawyers.
Language-lawyering is probably not the most hip thing out there, but
it's still useful in some settings. I think you would agree that people
who write standards, for example, need to use very precise wording, and
tend to do so. The separation between semantics and performance issues,
for example, is not incidental.
Now it so happens that most of the people here take some interest in the
interpretation of the standard. One of the fun things is that you can
really learn here to write programs that are truly portable, i.e., that
are *guaranteed* to work on any conforming implementation.
In practice, this is quite hard to achieve with real-life problems. But
(speaking for myself here) thanks to following this newsgroup, I now
have a much higher level of awareness in my day-to-day programming as to
when I use non-portable constructs. Furthermore, I have been made aware
of pro's and con's of my particular style of programming. As an example,
I prefer to cast malloc() results, which almost everybody here thinks is
a very bad idea. By discussing this issue I have seen some good
arguments against my style, and had to make very clear (to me and
others) why I still prefer casts. All in all, (thinking about) stuff
like that raises my ability as a C programmer.
So I think discussion of language-semantics are worthwhile. I think the
same of performance issues (I'm a sucker for squeezing out the last
clock cycle out of a program myself), but I understand the limitations
of this group in that respect.
Secondly, responding to your earlier advice to post to the newsgroup
associated with my implementation, this is a non-starter. My question
spans the totality of C implementations.
Your original question mentioned two specific platforms. If you ask the
very general question instead: "is there a general way to ensure optimal
performance in this respect", the answer you are going to get here is no
(since there isn't).
Now if you want to tap the experience of the guys here, you need to play
nice. What helps is acknowledging that you understand this stuff is
off-topic, that you realize the standard doesn't talk about performance,
but still you would be interested if people here would have some ideas
to help you on this. It's a matter of greasing up the social
interaction, so to say.
As with the technical side of your question: chances are that, truly,
nobody has a very good idea how to be of assistance in the general case.
The people hanging around here are for the most part highly skilled
technical people; as you know, people like that (myself included, I'm
afraid) like little better than showing off how clever they are :^)
Often times, even if a question is off-topic, if a quick answer can be
had you will get it anyway, together with a blunt "although it is
off-topic" notice.
Your question clearly falls in the category of "close to topical"; if
there would be an easy answer, or a truly useful remark, I think it
would have been gotten by now.
As author of a portable
cryptographic digest package, I cannot predict which C compiler a
particular user might actually employ to build the package. Yet it's
reasonable to want to ensure that--no matter which implementation is
chosen--the result will execute efficiently.
True. I think you should consider if 5--30% is really worth an effort
though.
And there are clever ways
to go about this that avoid the incremental approach of simply piling up
a mountain of #ifdef's in the code to handle specific cases.
I wonder if there really is anything other than a mountain of ifdefs.
You could run a test-run while doing your program's initial configure
script, or something like that, or even a runtime check. But again,
5--30% seems hardly worth the effort.
It's the newsgroup's cleverness that I want to tap into, not its legal
> expertise.
Ok, but I think you have to respect that people gather here for the
reason that they do (which is discussing C language semantics), and not
to have their cleverness tapped.
The only common thread that connects this challenge is the C language
itself. The language was principally designed to offer a portable means
to produce efficient programs. For the newsgroup to eschew matters of
performance and efficiency is therefore short-sighted, and violates the
true spirit of the language.
It is true that C has an important performance component in it, of
course. Often times, here, you will find people pointing out possible
order-improvements in sample code, or even more modest improvements
(e.g., traversing an array once instead of twice). These are performance
improvements that will generally work on /any/ 'normal' implementation.
However, your issue truly is out of reach from the C perspective, the
performance differences are caused at a level that cannot simply be
fixed by tuning the C code. At least that's how I see it.
Best regards,
Sidney
