Mystery: static variables & performance

[Mark McIntyre]

Re: [OT] Mystery: static variables & performance

On Sun, 08 Feb 2004 07:01:16 GMT, in comp.lang.c , "Mike Wahler"
<mkwahler@mkwah ler.net> wrote:
[color=blue]
>"Mark Shelor" <mshelor@comcas t.removeme.net> wrote in message
>news:KdOdnZ5Ul afqTLjd4p2dnA@c omcast.com...
>[color=green]
>>it might behoove you to try and
>> contribute something technically[/color]
>
>This group's archives can attest to my contributions here.[/color]

Consider them attested for.


--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.c om/ms3/bchambless0/welcome_to_clc. html>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[Mark McIntyre]

Re: [OT] Mystery: static variables &amp; performance

On Sun, 08 Feb 2004 01:15:25 -0700, in comp.lang.c , Mark Shelor
<mshelor@comcas t.removeme.net> wrote:
[color=blue]
>Mike Wahler wrote:
>[color=green]
>> Perhaps. Note that it has also had the negative result of branding
>> you as clueless as well as abusive.[/color]
>
>There now, Mike, I hope that made you feel better.[/color]

Why would it make Mike feel better, knowing that you've managed to
brand yourself clueless and abusive?

(Snip remaining dorkish and sarcastic attempts at insults.)


--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.c om/ms3/bchambless0/welcome_to_clc. html>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[Mike Wahler]

Re: [OT] Mystery: static variables &amp; performance

"Mark Shelor" <mshelor@comcas t.removeme.net> wrote in message
news:jaadncDLvZ 27bbjd4p2dnA@co mcast.com...[color=blue]
> Mike Wahler wrote:
>[color=green]
> > Perhaps. Note that it has also had the negative result of branding
> > you as clueless as well as abusive.[/color]
>
>
> There now, Mike, I hope that made you feel better.
>
>[color=green]
> > I don't care whether you do or not. I find it very valuable to me,
> > which is why I take the time to defend it by challenging off-topic
> > material.[/color]
>
>
> Where WOULD the newsgroup be without you, Mike? I'm glad you were on
> duty this weekend. Perhaps our planet would have shifted off its axis
> otherwise.[/color]

It seems some folks are beyond help.

*PLONK*

-Mike

[Nick Landsberg]

Re: Mystery: static variables &amp; performance



Mark Shelor wrote:
[color=blue]
> Sidney Cadot wrote:
> [color=green]
>> Consider, for a moment, the possibility that you are wrong and we (the
>> people reacting to your insistance to discuss implementation-dependent
>> performance issues in this newsgroup) are right: the C language is
>> standardized in a way that very explicitly leaves performance issues
>> out. They are a matter of (quality of) _implementation _.[/color]
>
>
>
> 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. But how utterly boring, and what a waste of talent. It
> reduces the newgroups participants to a mere gaggle of lawyers.
>
> 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 . 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. 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. It's the
> newsgroup's cleverness that I want to tap into, not its legal expertise.
>
> 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.
>
> Regards, Mark
> [/color]

I can argue both sides of this issue -

As someone who has been a performance consultant on many projects,
I find that the most egregious performance faux-pas are made not
at the language (code) level, but at the implementation level,
e.g. doing too many mallocs() rather than a buffer pool,
spawning excess threads, opening and closing sockets willy-nilly,
etc.

The C language allows you to shoot yourself in the foot in this
regard (and most languages do too, in this regard). What you write
is what you get in terms of performance.

If, on the other hand, all of the issues similar to the ones noted
above have been adressed, then it is legitimate to wonder which
C constructs are "best" for a given implementation. The answer
to this question is most likely to be dependent on the implementation
and the compiler. (is that redundant?) For example, I have worked
with compilers where "while(1)" was more efficient than "for(;;)"
and vice-versa. The delta was miniscule in comparison to the other
inefficiencies in my code.

On the other hand, if there ARE constructs which are inefficient,
I want to know about them in order to avoid them. So a question
to the language guru's may not be out of place





--
Ñ
"It is impossible to make anything foolproof because fools are so
ingenious" - A. Bloch

[Christian Bau]

Re: Mystery: static variables &amp; performance

In article <Rb6dnQnRTMeFRL vdRVn-gQ@comcast.com> ,
Mark Shelor <mshelor@comcas t.removeme.net> wrote:
[color=blue]
> 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.[/color]

If you know that the C Standard answers a question, then there is a good
chance that you know the answer as well. The other way round, if you
don't know the answer, then there is a good chance that you don't know
whether the C Standard gives an answer or not.

[Mark McIntyre]

Re: [OT] Mystery: static variables &amp; performance

On Sun, 08 Feb 2004 17:54:55 -0700, in comp.lang.c , Mark Shelor
<mshelor@comcas t.removeme.net> wrote:
[color=blue]
>Had Mr. Wahler been so kind as to include my entire remark, you would
>have seen that I was suggesting that he contribute something technically
>*to this thread*.[/color]

Given that its impossible to answer this thread in CLC, that would be hard
to do for anyone, even Dan Pop.

But mike already gave you very good and highly relevant contribution. You
chose to ignore it. Your loss.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.c om/ms3/bchambless0/welcome_to_clc. html>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[Mark McIntyre]

Re: Mystery: static variables &amp; performance

On Sun, 08 Feb 2004 17:49:23 -0700, in comp.lang.c , Mark Shelor
<mshelor@comcas t.removeme.net> wrote:
[color=blue]
>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.[/color]

cut out the hyperbole, it does nothing for your argument except make you
look an idiot.
[color=blue]
>But how utterly boring, and what a waste of talent. It
>reduces the newgroups participants to a mere gaggle of lawyers.[/color]

You're wrong, probably through ignorance rather than malice. This is a very
active and popular group, which gets along very well as it is. There's
plenty to discuss in Standard C, even though you can't understand that.

And whenever we want to talk about Unix or Windows or microprocessor
specialisations , well hey, we can pop over to the right group for that too.
There's even comp.programmin g for general programming issues.
Wow, isn't usenet wonderful.
[color=blue]
>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 .[/color]

So you plan to port to embedded processors, dragonball, cray, etc? I think
not.

You asked a specific question about performacne on MacOS vs some other
platform. So find out from the experts in those areas.
[color=blue]
>As author of a portable
>cryptographi c digest package, I cannot predict which C compiler a
>particular user might actually employ to build the package.[/color]

True. In which case you need to ask EXPERTS in the platforms you reasonably
expect it to be used on, so that you can get it as right as possible. To
find experts in a specific platform, I'd recommend a platform-specific
group.

But this is all irrelevant to CLC. In CLC we don't discuss platform
specific details, so you are simply asking in the wrong place.
[color=blue]
>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.[/color]

True. In a platform-independent manner.
[color=blue]
>For the newsgroup to eschew matters of
>performance and efficiency is therefore short-sighted, and violates the
>true spirit of the language.[/color]

We don't. We do however eschew platform specific solutions to those
problems here. You are still missing the point.


--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.c om/ms3/bchambless0/welcome_to_clc. html>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[Joona I Palaste]

Re: Mystery: static variables &amp; performance

Mark McIntyre <markmcintyre@s pamcop.net> scribbled the following:[color=blue]
> On Sun, 08 Feb 2004 17:49:23 -0700, in comp.lang.c , Mark Shelor
> <mshelor@comcas t.removeme.net> wrote:[color=green]
>>But how utterly boring, and what a waste of talent. It
>>reduces the newgroups participants to a mere gaggle of lawyers.[/color][/color]
[color=blue]
> You're wrong, probably through ignorance rather than malice. This is a very
> active and popular group, which gets along very well as it is. There's
> plenty to discuss in Standard C, even though you can't understand that.[/color]
[color=blue]
> And whenever we want to talk about Unix or Windows or microprocessor
> specialisations , well hey, we can pop over to the right group for that too.
> There's even comp.programmin g for general programming issues.
> Wow, isn't usenet wonderful.[/color]
[color=blue][color=green]
>>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 .[/color][/color]
[color=blue]
> So you plan to port to embedded processors, dragonball, cray, etc? I think
> not.[/color]
[color=blue]
> You asked a specific question about performacne on MacOS vs some other
> platform. So find out from the experts in those areas.[/color]
[color=blue][color=green]
>>As author of a portable
>>cryptograph ic digest package, I cannot predict which C compiler a
>>particular user might actually employ to build the package.[/color][/color]
[color=blue]
> True. In which case you need to ask EXPERTS in the platforms you reasonably
> expect it to be used on, so that you can get it as right as possible. To
> find experts in a specific platform, I'd recommend a platform-specific
> group.[/color]
[color=blue]
> But this is all irrelevant to CLC. In CLC we don't discuss platform
> specific details, so you are simply asking in the wrong place.[/color]

This is actually a wonderful thing to have. I'm quite good at
*programming*, and quite good at *C*, but I tend to suck at
implementation-specific details. I can't use the Unix API without
reaching for my Stevens. I haven't even *looked* at the Windows API.
However, most of the questions I answer here on comp.lang.c have
diddly-squat to do with either, or any other platform-specific API.
That's where I can use my *real* expertise.

--
/-- Joona Palaste (palaste@cc.hel sinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/

[Michel Bardiaux]

Re: Mystery: static variables &amp; performance

Mark Shelor wrote:
[color=blue]
>
> 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. But how utterly boring, and what a waste of talent. It
> reduces the newgroups participants to a mere gaggle of lawyers.[/color]

I agree 100% with you. This group has been taken over by a bunch of
fanatics. Unfortunately, they have a very effective strategy: to
effectively censor a question, they post a large number of messages
about the topicality of the question. Anyone wishing to find *real*
discussion of the original question has to waddle through dozens of
completely uninteresting messages. Killfiling the so-called regulars is
not practical, the thread becomes even more unreadable.
[color=blue]
>
> 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 .[/color]

Yes, that's part of the standard (ha ha) strategy: QOI on platform X is
supposed to be topical for a group devoted to platform X. Note that
according to the mindset of the clc thought police, that group *should*
decide that *any* reference to other platforms than X is OT! Questions
of comparative QOI would thus be OT everywhere...
[color=blue]
> 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. 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. It's the
> newsgroup's cleverness[/color]

Tha's one of the most frustrating aspects. The OT bashers are *not*
idiots; I'm quite sure they *do* know the answers to the questions!
[color=blue]
> that I want to tap into, not its legal expertise.
>
> 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.
>
> Regards, Mark
>[/color]
I have given up a long time ago... I just browse the group quickly
hoping to find something in all the noise. I have sometimes wondered why
all the lawyers did not move over to clc.moderated, but there is a catch
there: is *one* moderator accepts a question even *once* then there is a
precedent. And if a question is rejected by the moderator the whole
thread will be cut short and the lawyers wont have an opportunity to
plead, flame, rave and other activities they enjoy so much.

--
Michel Bardiaux
Peaktime Belgium S.A. Bd. du Souverain, 191 B-1160 Bruxelles
Tel : +32 2 790.29.41

[Mark McIntyre]

Re: Mystery: static variables &amp; performance

On Mon, 09 Feb 2004 18:33:06 +0100, in comp.lang.c , Michel Bardiaux
<michel.bardiau x@peaktime.be> wrote:
[color=blue]
>Mark Shelor wrote:
>[color=green]
>>
>> 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. But how utterly boring, and what a waste of talent. It
>> reduces the newgroups participants to a mere gaggle of lawyers.[/color]
>
>I agree 100% with you. This group has been taken over by a bunch of
>fanatics.[/color]

Euh, this group has /always/ since the days before comp. began, been run by
a bunch of what you term fanatics. Thats why its managed to survive so long
without being drowned in offtopic garbage.
[color=blue]
>Unfortunatel y, they have a very effective strategy: to
>effectively censor a question, they post a large number of messages
>about the topicality of the question.[/color]

This isn't a strategy. If the newbies asking in the wrong place would take
a hint after response 1, there'd be no further posts.


--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.c om/ms3/bchambless0/welcome_to_clc. html>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[Rob Thorpe]

Re: Mystery: static variables &amp; performance

Mark Shelor <mshelor@comcas t.removeme.net> wrote in message news:<z4ydnQxFZ Npp07ndRVn-tw@comcast.com> ...[color=blue]
> I've encountered a troublesome inconsistency in the C-language Perl
> extension I've written for CPAN (Digest::SHA). The problem involves the
> use of a static array within a performance-critical transform function.
> When compiling under gcc on my big-endian PowerPC (Mac OS X),
> declaring this array as "static" DECREASES the transform throughput by
> around 5%. However, declaring it as "static" on gcc/Linux/Intel
> INCREASES the throughput by almost 30%.
>
> I would prefer that the array not be "static" so that the underlying C
> function will be thread-safe. However, giving up close to 30%
> performance on gcc/Linux/Intel is unacceptable for a digest routine,
> whose value is often closely tied to speed.
>
> Can anyone enlighten me on this mystery, and recommend a simple, clean,
> portable way to assure good performance on all host types?[/color]

There are no portable ways to assure performance.
There are ways that work on a wide range of systems.
Asking about the performance of a set of different platforms is a
highly *platform specific* question.

Possible Clues:

* Address generation has completely different penalties on different
microprocessors .
* Executable formats may change between machines requiring different
access methods.
* Does it involves an array of perl internal variable, ie SV or AV.
If so remember: the fields may change in length and the efficiency of
the accessor functions may be very different between systems. (You
should go home if this is the case)

Do this:

* Look at the assembly produced if you can
* If you can't figure it out
** Post the C code and the assembly to somewhere like
comp.lang.asm.x 86
** Post the C code and possibly the assembly to
comp.os.linux.d evelopment.apps
** Ask someone knowledgable in Perl internals about x86 and PowerPC
differences
* Stop bitching about people telling you you're off topic it helps
nobody.

[Alan Balmer]

Re: Mystery: static variables &amp; performance

On Sun, 08 Feb 2004 17:49:23 -0700, Mark Shelor
<mshelor@comcas t.removeme.net> wrote:
[color=blue]
>Sidney Cadot wrote:
>[/color]
<snip>
[color=blue]
>Standard. But how utterly boring, and what a waste of talent. It
>reduces the newgroups participants to a mere gaggle of lawyers.
>[/color]
The usual recommendation for usenet is that one read a group for some
length of time before posting to it. If you had done that, you would
know that the above statement is not true.

[color=blue]
>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 . As author of a portable
>cryptographi c 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. 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. It's the
>newsgroup's cleverness that I want to tap into, not its legal expertise.[/color]

Then perhaps you should try comp.programmin g. There, you not only get
clever C programmers (including some who frequent this group) but
cross-fertilization from expertise in other languages.[color=blue]
>[/color]
<snip>

--
Al Balmer
Balmer Consulting
removebalmercon sultingthis@att .net

[Martin Ambuhl]

Re: Mystery: static variables &amp; performance

Michel Bardiaux wrote:
[color=blue]
> Mark Shelor wrote:
>[color=green]
>>
>> 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. But how utterly boring, and what a waste
>> of talent. It reduces the newgroups participants to a mere gaggle of
>> lawyers.[/color]
>
>
> I agree 100% with you. This group has been taken over by a bunch of
> fanatics.[/color]

The same kind of "fanatics" that have populated it from the beginning,
before the Great Renaming. It is only because it has kept on topic that it
has been one of the oldest, most successful, and most popular newsgroups,
probably since before you were born. Be an idiot, if you want. Just do it
elsewhere.



--
Martin Ambuhl

[Sidney Cadot]

Re: Mystery: static variables &amp; performance

Mark Shelor wrote:
[color=blue]
> Sidney Cadot wrote:
>[color=green]
>> Consider, for a moment, the possibility that you are wrong and we (the
>> people reacting to your insistance to discuss implementation-dependent
>> performance issues in this newsgroup) are right: the C language is
>> standardized in a way that very explicitly leaves performance issues
>> out. They are a matter of (quality of) _implementation _.[/color]
>
> 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.[/color]

That's a good summary; the drum roll surely adds a touch of class to it.
[color=blue]
> But how utterly boring, and what a waste of talent.[/color]

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.
[color=blue]
> It reduces the newgroups participants to a mere gaggle of lawyers.[/color]

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.
[color=blue]
> 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 .[/color]

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.
[color=blue]
> 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.[/color]

True. I think you should consider if 5--30% is really worth an effort
though.
[color=blue]
> 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.[/color]

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.
[color=blue]
> It's the newsgroup's cleverness that I want to tap into, not its legal
> expertise.[/color]

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.
[color=blue]
> 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.[/color]

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

[Mark Shelor]

Re: Mystery: static variables &amp; performance

Rob Thorpe wrote:
[color=blue]
> There are no portable ways to assure performance.
> There are ways that work on a wide range of systems.
> Asking about the performance of a set of different platforms is a
> highly *platform specific* question.[/color]


With respect, Rob, you're simply not correct.

There are clever ways to use the C language that--in general--are more
efficient across a wide range of platforms. I illustrated this point
earlier with a simple string-copy example.

I have no desire to interfere with your right to believe that issues of
C language definition are completely separable from issues of
performance. On the other hand, you have an opportunity to learn
something here: by making the realization that these two realms are
indeed linked.

[color=blue]
> Do this:
>
> * Look at the assembly produced if you can
> * If you can't figure it out
> ** Post the C code and the assembly to somewhere like
> comp.lang.asm.x 86
> ** Post the C code and possibly the assembly to
> comp.os.linux.d evelopment.apps
> ** Ask someone knowledgable in Perl internals about x86 and PowerPC
> differences[/color]


First off, let me say that I appreciate your taking the time to
enumerate this list of suggestions. They would indeed be helpful if I
were only interested in the package's performance on a limited set of
platforms.

The citing of the Intel/Linux and PowerPC/BSD examples merely served to
illustrate that there can be a *dramatic* difference in performance due
to the use of the static storage class. Perhaps there are alternative
ways to set up the SHA message schedule processing in C that are not
only portable, but also more likely to be uniformly-efficient across a
wide range of platforms? I appreciate that it might require a great
deal of experience in language and compiler design to answer a question
such as this, but I assume such folks inhabit this newsgroup.

[color=blue]
> * Stop bitching about people telling you you're off topic it helps
> nobody.[/color]


Not being a fan of censorship or churlish remarks, I'll overlook this
demand. Perhaps you can save yourself a great deal of frustration by
simply not participating in this thread, if that's acceptable to you.

Regards, Mark