Mystery: static variables & performance

[Mark Shelor]

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?

TIA, Mark

[Jack Klein]

On Fri, 06 Feb 2004 19:35:28 -0700, Mark Shelor
<ms*****@comcast.removeme.net> wrote in comp.lang.c:

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.
Note that Perl is completely off-topic here, but your question is more
or less a basic C one, regardless of what code you are trying to write
when you make this comparison.
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%.
The C standard does not define the relative performance of any type of
operation, variable, or memory usage over another. The differences
depend on two, and only two, things. They are the architecture of the
underlying hardware (processor, memory interface, etc.), and the
quality of the code generation of the compiler for that underlying
hardware.
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.
"thread-safe" is off-topic here, but if you need the array to have
automatic or dynamic allocation for some off-topic reason, then by all
means you had better write it that way and eschew arrays with static
storage duration.
Can anyone enlighten me on this mystery, and recommend a simple, clean,
portable way to assure good performance on all host types?

There is no mystery as far as we are concerned here, as the C standard
has neither requirements nor guarantees as to the relative performance
of memory with different duration, or even whether there is or is not
a difference. So you question is not in any way, shape, or form a
language one at all.

What you are asking for is how to optimize code for various
implementations, and that is not one but N implementation-specific
questions, where N is the number of platforms that you want it to run
on.

It is not even a C question, because processor hardware differs quite
widely. In maximally optimized assembly language, some processors
will access static memory faster than dynamic, others the opposite.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Mark Shelor]

Jack Klein wrote:

The C standard does not define ...

Your rather long-winded response could have been better expressed by
simply saying "I don't know."

My original post was not meant to elicit tautological remarks--such as
yours--about the C standard. It was intended to draw on a collective
depth of experience which this newsgroup hopefully possesses.

However, if comp.lang.c considers the practice of C programming to be
off-topic, and instead chooses to restrict itself to the language
definition, then please accept my apologies for intruding. I'll leave
you to your peaceful slumber.

Mark

[Joona I Palaste]

Mark Shelor <ms*****@comcast.removeme.net> scribbled the following:

Jack Klein wrote:

The C standard does not define ...

Your rather long-winded response could have been better expressed by
simply saying "I don't know."
But that would have been the wrong reply. This newsgroup is about the
C language, not about implementations of it. Languages do not have
speed. Implementations do. Therefore questions about efficiency are
off-topic here.
My original post was not meant to elicit tautological remarks--such as
yours--about the C standard. It was intended to draw on a collective
depth of experience which this newsgroup hopefully possesses. However, if comp.lang.c considers the practice of C programming to be
off-topic, and instead chooses to restrict itself to the language
definition, then please accept my apologies for intruding. I'll leave
you to your peaceful slumber.

Practice of C programming comes in two levels: the C language itself,
and particular implementations of it. Measuring efficiency of
particular constructs falls under the latter category.
Jack said, quite correctly, that the C standard does not define
efficiency concerns. Honestly, would you think it did? Would it make
sense to define "operation X must be 2.5 times slower than operation Y,
or else the implementation does not conform to the C standard"?

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Insanity is to be shared."
- Tailgunner

[Mark Shelor]

Joona I Palaste wrote:

But that would have been the wrong reply. This newsgroup is about the
C language, not about implementations of it. Languages do not have
speed. Implementations do. Therefore questions about efficiency are
off-topic here.

If you believe it's off-topic, then don't reply. This is an unmoderated
group.

Also, your presumption of clean separability between language definition
and efficiency is naive at best, and fatally flawed at worst. The
creation and refinement of the C language is rooted in the desire to
achieve efficient portable programs.

But, if you consider it more worthwhile to debate whether 73! can be
calculated in C without loss of significant digits--or other such toy or
academic problems--then far be it from me to interfere with your coffee
club.

Practice of C programming comes in two levels: the C language itself,
and particular implementations of it. Measuring efficiency of
particular constructs falls under the latter category.
Jack said, quite correctly, that the C standard does not define
efficiency concerns. Honestly, would you think it did? Would it make
sense to define "operation X must be 2.5 times slower than operation Y,
or else the implementation does not conform to the C standard"?

No, because the people who created the language--and refined its
definition into a standard--are reasonably intelligent, unlike your
example. Is

while ((*s++ = *t++) != '\0')
;

an efficient way to perform a string copy? Yes, probably more so than
other simple or brute-force approaches: a fact primarily due to C's
inclusion of facilities to specifically allow the production of
highly-efficient, portable programs. Divorcing considerations of
efficiency from the language definition, and labelling them as merely
implementation-dependent, does not reflect a great deal of wisdom or
practical experience.

Nonetheless, if you have something constructive to contribute, then
please feel free to enlighten me. Otherwise, I recommend you take
Wittgenstein's advice and simply remain silent.

Regards, Mark

[Sidney Cadot]

Mark Shelor wrote:

Joona I Palaste wrote:

But that would have been the wrong reply. This newsgroup is about the
C language, not about implementations of it. Languages do not have
speed. Implementations do. Therefore questions about efficiency are
off-topic here.

If you believe it's off-topic, then don't reply. This is an unmoderated
group.
The method of choice in this newsgroup with respect to off-topic
messages is to point it out to the sender, and kindly but firmly
redirect them to a more appropriate place.
Also, your presumption of clean separability between language definition
and efficiency is naive at best, and fatally flawed at worst. The
creation and refinement of the C language is rooted in the desire to
achieve efficient portable programs.
Well, let's see what the standard has to say about this, shall we:

C99, 5.1.2.3#1: "The semantic descriptions in this International
Standard describe the behavior of an abstract machine in which issues of
optimization are irrelevant. "

So the C language definition is explicitly separated from performance
issues. Of course, there are many practical situations (e.g., yours)
where performance /is/ important, but then, well, you need to address
this in a newsgroup dedicated to your particular implementation.
But, if you consider it more worthwhile to debate whether 73! can be
calculated in C without loss of significant digits--or other such toy or
academic problems--then far be it from me to interfere with your coffee
club.
Why, thank you. Although I'm not sure the derogatory tone is warranted.
Most of the regulars here are very experienced, with backgrounds varying
from academia to compiler-builders to working software engineers; most
of them would agree that following this newsgroup has provided them with
a great deal of insight into the C language.
Practice of C programming comes in two levels: the C language itself,
and particular implementations of it. Measuring efficiency of
particular constructs falls under the latter category.
Jack said, quite correctly, that the C standard does not define
efficiency concerns. Honestly, would you think it did? Would it make
sense to define "operation X must be 2.5 times slower than operation Y,
or else the implementation does not conform to the C standard"?

No, because the people who created the language--and refined its
definition into a standard--are reasonably intelligent, unlike your
example. Is

while ((*s++ = *t++) != '\0')
;

an efficient way to perform a string copy? Yes, probably more so than
other simple or brute-force approaches: a fact primarily due to C's
inclusion of facilities to specifically allow the production of
highly-efficient, portable programs.
I'd suggest using "strcpy()", and trust the library implementors.
Divorcing considerations of
efficiency from the language definition, and labelling them as merely
implementation-dependent, does not reflect a great deal of wisdom or
practical experience.
On the contrary, it provides a very important factorization between two
important aspects (semantics versus performance), making it possible to
treat these as (more-or-less) separate problems. It's all just a matter
of proper design.

compl.lang.c is concerned with semantics of the C language as described
in the standards (C89, C99). For performance (a worthy subject in
itself), you are kindly redirected to our friendly neighbours.
Nonetheless, if you have something constructive to contribute, then
please feel free to enlighten me. Otherwise, I recommend you take
Wittgenstein's advice and simply remain silent.

A little bit of self-reflection on your side wouldn't hurt, I guess.

Best regards,

Sidney

[pete]

Mark Shelor wrote:

Joona I Palaste wrote:

But that would have been the wrong reply.
This newsgroup is about the
C language, not about implementations of it. Languages do not have
speed. Implementations do. Therefore questions about efficiency are
off-topic here.
If you believe it's off-topic, then don't reply.
This is an unmoderated group.

That's why we all have the right to censor.
This newsgroup has the highest S/N ratio of any that I'm aware of.
Topicality is highly valued.
Otherwise, I recommend you take
Wittgenstein's advice and simply remain silent.

If you can't appreciate topicallity,
then we have to gang up on you. We have no other choice.

--
pete

[CBFalconer]

Mark Shelor wrote:

Jack Klein wrote:

The C standard does not define ...

Your rather long-winded response could have been better expressed
by simply saying "I don't know."

My original post was not meant to elicit tautological remarks--such as
yours--about the C standard. It was intended to draw on a collective
depth of experience which this newsgroup hopefully possesses.

You fail to realize that your original query has no answer, except
in the context of a specific C implementation. Most people
inhabiting a newsgroup dedicated to that implementation are likely
to know something about it. This group discusses portable coding
in the C language, as defined by the C standard. That makes
(accurate) advice applicable to all.

Even should someone here offer a reply there may well be nobody
available to check its accuracy. If you lurk a short time (as you
should have before posting) you will notice that inaccuracies tend
to be pointed out loudly and at length, sometimes accompanied by
gratuitious aspersions.

You should thank Jack for explaining reasons, rather than replying
with a simple "OT, go away".

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Martin Ambuhl]

Mark Shelor wrote:

If you believe it's off-topic, then don't reply. This is an unmoderated
group.

This approach has been tried and found wanting. It leads to newnet
cesspools. comp.lang.c and its pre-renaming predecessor is one of the
oldest and most successful newsgroup because of the attempt to keep it
topical. You are simply wrong to post off-topic questions here and wrong
in your suggestion of what to do about off-topic posts.

--
Martin Ambuhl

[MSG]

Mark Shelor <ms*****@comcast.removeme.net> wrote in message news:<z4********************@comcast.com>...

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?

TIA, Mark

You forgot to mention relevant details:

Threads library and version
Kernel version and configuration
CPU version
Compiler version and options used with them

As you noted above yourself, the performance difference between static
and regular arrays depends on these parameters. My guess is that it
comes from the different threading algorithms BSD and Linux use.

MSG

[Mark Shelor]

MSG wrote:

You forgot to mention relevant details:

Threads library and version
Kernel version and configuration
CPU version
Compiler version and options used with them

As you noted above yourself, the performance difference between static
and regular arrays depends on these parameters. My guess is that it
comes from the different threading algorithms BSD and Linux use.

At long last ... an intelligent response. Thank you!

Nonetheless, the problem is not quite as simple as your queries imply.
The Digest::SHA module and underlying C code are designed to be as
portable as reasonably possible, since it's not known beforehand which
compiler(s) will be used to build it; the CPAN user community is quite
broad and diverse. Merely finding which code is most efficient for each
platform/compiler combination, and setting up the appropriate #ifdef's,
is like chipping away at an iceberg. Yet, there should be a way to
construct portable and highly efficient code in a general sense (i.e.
that works well across most machines).

Your suggestion of threading is interesting, and might imply more
efficient alternatives to the current scheme of using function-local
automatic or static variables to hold the SHA message schedule. Perhaps
also is has to do with the register assignment algorithm working
differently when such variables change their storage class. It's hard
to be believe that accessing memory in one location versus another would
result in a 30% decrease in performance, unless of course the memory
values were no longer being cached in registers.

Or, perhaps there are other explanations for why the performance is
impacted, which might suggest other ways of approaching the computation.
That's what I'm really after here.

Regards, Mark

[Mark Shelor]

Sidney Cadot wrote:

The method of choice in this newsgroup with respect to off-topic
messages is to point it out to the sender, and kindly but firmly
redirect them to a more appropriate place.

Such as?

I'd suggest using "strcpy()", and trust the library implementors.

I'd suggest you re-read the entire paragraph surrounding my string-copy
example to gain the proper context. You entirely missed the point, and
your response is pedantic, insulting, and, lo, off-topic.

A little bit of self-reflection on your side wouldn't hurt, I guess.

Please, Sidney, set an example for us, and I'll be happy to follow.
Regards, Mark

[Mark Shelor]

pete wrote:

That's why we all have the right to censor.
This newsgroup has the highest S/N ratio of any that I'm aware of.

Given the lengthy discussion devoted to such absorbing topics as
"calculate value of 73!", I'd have to say that your criteria for
assessing a "signal" are quite liberal.

If you can't appreciate topicallity,
then we have to gang up on you. We have no other choice.

In the interest of maintaining newsgroup "purity" of course. You fail
to appreciate the fact that questions of portable efficiency ARE topical
to a discussion of the language. You are attempting to unilaterally
outlaw these questions because you lack the appropriate insight and
experience to answer them. Furthermore, accepting the role of mere
"standards-jockey" is flattering neither to yourself nor to the newsgroup.

Regards, Mark

[Dan Henry]

On Fri, 06 Feb 2004 19:35:28 -0700, Mark Shelor
<ms*****@comcast.removeme.net> wrote:

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%.
"static" as opposed to what, (implicit) "auto" or dynamically
allocated (i.e., malloc'ed)?

Specifying that the array's storage class be "static" /could/ cause it
to be located in a different region of memory compared to another
storage class or compared to the heap. By "different", I mean from a
hardware perspective -- different memory types with different access
times, different caching policies, different memory management
policies, etc.

Also, "static" allocation /could/ allow use of a different memory
addressing mode which might vary the speed.
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,...
Not without a whole bunch of platform specific details, I don't think.
and recommend a simple, clean,
portable way to assure good performance on all host types?

[Mark McIntyre]

On 7 Feb 2004 13:22:14 -0800, in comp.lang.c , ms*****@yahoo.com (MSG)
wrote:

Can anyone enlighten me on this mystery, and recommend a simple, clean,
portable way to assure good performance on all host types?

You forgot to mention relevant details:

snip irrelevant details.

Troll alert: there's no such thing as threading in C. If you think
that threads are relevant you;re either a troll or posting in the
wrong grop.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/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]

On Sat, 07 Feb 2004 05:35:32 -0700, in comp.lang.c , Mark Shelor
<ms*****@comcast.removeme.net> wrote:

Joona I Palaste wrote:

But that would have been the wrong reply. This newsgroup is about the
C language, not about implementations of it. Languages do not have
speed. Implementations do. Therefore questions about efficiency are
off-topic here.

If you believe it's off-topic, then don't reply. This is an unmoderated
group.

actually, its more of a self-regulated group. Offtopic posts get one
polite warning,
Also, your presumption of clean separability between language definition
and efficiency is naive at best, and fatally flawed at worst. The
creation and refinement of the C language is rooted in the desire to
achieve efficient portable programs.
Define efficient. fast? compact? least code? fewest pagefaults? etc
Jack said, quite correctly, that the C standard does not define

efficiency concerns. Honestly, would you think it did? Would it make
sense to define "operation X must be 2.5 times slower than operation Y,
or else the implementation does not conform to the C standard"?
No, because the people who created the language--and refined its
definition into a standard--are reasonably intelligent, unlike your
example.

You miss the point entirely. The standard doesn't define these things,
nor the efficiency of your example, because its ntirely system
specific.
Nonetheless, if you have something constructive to contribute, then
please feel free to enlighten me. Otherwise, I recommend you take
Wittgenstein's advice and simply remain silent.

Round here, we ask offtopic posters politely to ask elsewhere. If you
do't like that, then please feel free to remain silent.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/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]

On Sat, 07 Feb 2004 17:04:58 -0700, in comp.lang.c , Mark Shelor
<ms*****@comcast.removeme.net> wrote:

MSG wrote: (stuff)>
At long last ... an intelligent response. Thank you!
you might want to consider that MSG is bordering on becoming a troll
here.

(snip offtopic stuff)
Or, perhaps there are other explanations for why the performance is
impacted,
The frobozz has lost its wheezle. Or possibly your core memory beads
have slipped on the wires. Or you forgot to rub the cat with the
amber before putting the static memory in your 380-Z.
which might suggest other ways of approaching the computation.
That's what I'm really after here.

Then you're becoming an idiot. This is the wrong group.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/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]

On Sat, 07 Feb 2004 17:34:47 -0700, in comp.lang.c , Mark Shelor
<ms*****@comcast.removeme.net> wrote:

You fail
to appreciate the fact that questions of portable efficiency ARE topical
to a discussion of the language.
And you have had an answer. . Just because you don't like the answer
doesn't mean its not true. But let me repeat, for the hard of hearing:
"Standard C doesn't require any particular efficiency from any
function or construct and so it ts impossible to answer your question.
You need to ask in a group specialising in your platforms."
You are attempting to unilaterally
FWIW, to be unilateral, there has to be only one person trying to do
it. There's a /consensus/ here about this.
outlaw these questions because you lack the appropriate insight and
experience to answer them.

ROFL !!!!! Do you know who you're referring to?
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/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 =---

[Christian Bau]

In article <Gt********************@comcast.com>,
Mark Shelor <ms*****@comcast.removeme.net> wrote:

Nonetheless, the problem is not quite as simple as your queries imply.
The Digest::SHA module and underlying C code are designed to be as
portable as reasonably possible, since it's not known beforehand which
compiler(s) will be used to build it; the CPAN user community is quite
broad and diverse. Merely finding which code is most efficient for each
platform/compiler combination, and setting up the appropriate #ifdef's,
is like chipping away at an iceberg. Yet, there should be a way to
construct portable and highly efficient code in a general sense (i.e.
that works well across most machines).

One possibility that I have used for highly time critical and relatively
small code: Implement two or three versions of a function, each doing
things in different ways that could influence speed in some way. Call
these functions through a global variable containing a function pointer.
The function pointer is initialised to point to a measuring function;
that function will during the first x calls call one of your
implementations and measure the time; after x calls it decides which one
was fasted and replaces the function pointer with a pointer to the
fastest function which is used for the rest of program execution.

[Mark Shelor]

Mark McIntyre wrote:

The frobozz has lost its wheezle. Or possibly your core memory beads
have slipped on the wires. Or you forgot to rub the cat with the
amber before putting the static memory in your 380-Z.

Hmm ... are those techniques mentioned in the C standards? Isn't your
response off-topic? <g>

which might suggest other ways of approaching the computation.
That's what I'm really after here.

Then you're becoming an idiot. This is the wrong group.

Your reasoning is spurious. This is the group that likes to have
extended discussions on whether it's possible to calculate 73! using C.
If I were an idiot, I'd feel perfectly at home here.

Regards, Mark

[jacob navia]

"Mark Shelor" <ms*****@comcast.removeme.net> wrote in message
news:Gt********************@comcast.com...

Perhaps
also is has to do with the register assignment algorithm working
differently when such variables change their storage class. It's hard to be believe that accessing memory in one location versus another would result in a 30% decrease in performance, unless of course the memory
values were no longer being cached in registers.

That is the central point.
Maybe (for whatever reasons) the compiler can't cache static variables
in registers.
If another thread runs the same code modifying the same static
variable,
the register cached value would not be synchronized with the
memory value and a mess would result.

Some compilers could ignore this (rather remote) possibility and would
cache the variable in a register, and others would not.

This would be easy to see by analyzing the generated code

[jacob navia]

A good test for this would be to declare the variable
volatile and see if all compilers agree. If they do so, it means
that the performance lost is a consequence of register
caching being not done when the variable is static.

[Mike Wahler]

"Mark Shelor" <ms*****@comcast.removeme.net> wrote in message
news:5I********************@comcast.com...

Your reasoning is spurious.
As you indicate below with your own words, it's yours that's
spurious.
This is the group that likes to have
extended discussions on whether it's possible to calculate 73! using C.
If I were an idiot, I'd feel perfectly at home here.

A person who describes the preferences of a group of virtually
thousands of people who participate in a several-years old newsgroup
(whose archives are freely available) based upon a single recent
thread, authored by a very small number of those people, is, well,
imo an 'idiot'. :-)

*Before* posting here again, *please* read (and observe) this
document:
http://www.angelfire.com/ms3/bchambl...me_to_clc.html

Read my lips:

This newsgroup discusses the ISO standard C language.
Your query was *not* about the C language.

-Mike

[Mark Shelor]

Mike Wahler wrote:

A person who describes the preferences of a group of virtually
thousands of people who participate in a several-years old newsgroup
(whose archives are freely available) based upon a single recent
thread, authored by a very small number of those people, is, well,
imo an 'idiot'. :-)

If you'll invest the effort to track the entire thread, you'll see that
the "idiot" epithet was not hurled originally by me. However, my use of
it was relatively fair and measured by comparison.

*Before* posting here again, *please* read (and observe) this
document:
http://www.angelfire.com/ms3/bchambl...me_to_clc.html

Before posting again to this thread, it might behoove you to try and
contribute something technically rather than just issuing orders. The
world is postmodern now. Why don't you make an effort to join the rest
of us? You'll enjoy it.

Read my lips:

This newsgroup discusses the ISO standard C language.
Your query was *not* about the C language.

If you put down your copies of the standards for the moment and slowly
back away from the table, you'll see that it has everything to do with
the C language: but perhaps in a way that's more subtle than what you're
accustomed to. This is giving you the opportunity to grow, if you
decide to take advantage of it.

Despite the shrill squeaks from the peanut gallery, posting my query to
this newsgroup had very positive results. I've received several
enlightened suggestions through responses and private emails.

So, no, I don't by any means condemn this newsgroup. There are
obviously some highly intelligent and experienced people among your ranks.

Regards, Mark

[Mike Wahler]

"Mark Shelor" <ms*****@comcast.removeme.net> wrote in message
news:Kd********************@comcast.com...

Mike Wahler wrote:

A person who describes the preferences of a group of virtually
thousands of people who participate in a several-years old newsgroup
(whose archives are freely available) based upon a single recent
thread, authored by a very small number of those people, is, well,
imo an 'idiot'. :-)

If you'll invest the effort to track the entire thread,

If *you* would make the effort to track the entire *newsgroup*
(as well as reading its 'welcome message'), you'd get a much
better idea of its nature and purpose.
you'll see that
the "idiot" epithet was not hurled originally by me. However, my use of
it was relatively fair and measured by comparison.
You're entitled to your opinion of course.

*Before* posting here again, *please* read (and observe) this
document:
http://www.angelfire.com/ms3/bchambl...me_to_clc.html

Before posting again to this thread,

You didn't read the document at that link, did you?
it might behoove you to try and
contribute something technically
This group's archives can attest to my contributions here.
rather than just issuing orders.
I have issued no orders at all, I simply offered some good advice.
Of course you're free to observe or ignore it.
The
world is postmodern now.
That's a meaningless statement.
Why don't you make an effort to join the rest
of us?
Us? Who else are you referring to?
You'll enjoy it.
I long ago 'joined' with my fellow programmers here in discussing
the topic of this group: ISO standard C. Judging from your behavior
here, I have no interest in 'joining' *you*. And were I to do so,
I'm sure I would not enjoy it at all.

Read my lips:

This newsgroup discusses the ISO standard C language.
Your query was *not* about the C language.

If you put down your copies of the standards

I own *one* copy of the *single* standard defining the C language.

This standard *defines* the C language which is the topic of this
newsgroup, so of course I refer to it quite often, and do use it
to determine if a particular issue is topical, if I don't know
already.
for the moment and slowly
back away from the table, you'll see that it has everything to do with
the C language:
If it's not defined by the standard, it's not part of the language.
but perhaps in a way that's more subtle than what you're
accustomed to.
'Subtlety' doesn't count in C. Either something is defined, or it's
not.
This is giving you the opportunity to grow, if you
decide to take advantage of it.
I'm doing just fine with regard to growth. It seems that it's *you*
who refuses to grow by refusing to acknowledge when you're wrong,
or to learn from your mistake (an off-topic post).

Despite the shrill squeaks from the peanut gallery,
Note that this 'peanut gallery' contains many world-class experts
in the C language, who could be of enormous benefit to you. But
now that you've insulted them, well, I wonder how willing they'll
be to help you in the future when you do have questions about C.

posting my query to
this newsgroup had very positive results.
Perhaps. Note that it has also had the negative result of branding
you as clueless as well as abusive.
I've received several
enlightened suggestions through responses and private emails.
All of which are necessarily off-topic for clc. Private email
is separate from this newsgroup and of course could contain anything
the correspondents desire without affecting the newsgroup, but
responses to your query other than an off-topic notice and
perhaps a redirection, are not appropriate for comp.lang.c

So, no, I don't by any means condemn this newsgroup.
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.
There are
obviously some highly intelligent and experienced people among your ranks.
And imo it's too bad you've gone and insulted them. You've probably
reduced considerably the chances of getting quality help from many
or all of them.


Regards,

It seems to me that you do *not* have any regard for this newsgroup
or its participants.

-Mike

[E. Robert Tisdale]

Mike Wahler wrote:

It seems to me that
you do *not* have any regard for this newsgroup
or its participants.

Mark Shelor is a new subscriber.
I can understand and tolerate his behavior in this thread --
mostly by ignoring him.
Your behavior, on the other hand, completely baffles me.
I would much rather that you brought Mark up to your level
than descending to his. :-(

[Mark Shelor]

Mike Wahler wrote:

Perhaps. Note that it has also had the negative result of branding
you as clueless as well as abusive.

There now, Mike, I hope that made you feel better.

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.

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.

And imo it's too bad you've gone and insulted them. You've probably
reduced considerably the chances of getting quality help from many
or all of them.

Yes, I've already started to lose sleep over that dismal prospect.
Earlier this evening, I had just started to nod off when jarred awake by
a startling nightmare:

Bruce Willis was imploring me: "Mark! A huge meteor is hurtling toward
earth, and we're all doomed unless you can calculate 73! using Standard
C. UNIX bc and the GMP multiple-precision library just won't cut it,
man! You gotta use the Standard!!"

Alas, since I had insulted the august members of comp.lang.c, all of
mankind perished, and I alone was responsible.

Chilling stuff.

Mark

[pete]

Mark Shelor wrote:

Despite the shrill squeaks from the peanut gallery,
posting my query to
this newsgroup had very positive results. I've received several
enlightened suggestions through responses and private emails.

"lurkers support me in email" is an old USENET joke.

Searched the web for "lurkers support me in email".
Results 1 - 10 of about 108. Search took 0.32 seconds.

http://www.bluejo.demon.co.uk/poetry...ia/lurkers.htm

--
pete

[Mark McIntyre]

On Sat, 07 Feb 2004 23:04:36 -0700, in comp.lang.c , Mark Shelor
<ms*****@comcast.removeme.net> wrote:

Mike Wahler wrote:

A person who describes the preferences of a group of virtually
thousands of people who participate in a several-years old newsgroup
(whose archives are freely available) based upon a single recent
thread, authored by a very small number of those people, is, well,
imo an 'idiot'. :-)

If you'll invest the effort to track the entire thread, you'll see that
the "idiot" epithet was not hurled originally by me. However, my use of
it was relatively fair and measured by comparison.

Personally, I consider someone who walks into a butchers and asks for
loon pants, and who then, when told he's in a butchers, insists on his
right to make his purchase there, to be a bit of an idiot. YMMV. HTH,
HAND.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/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]

On Sat, 07 Feb 2004 23:04:36 -0700, in comp.lang.c , Mark Shelor
<ms*****@comcast.removeme.net> wrote:

Mike Wahler wrote:

Read my lips:

This newsgroup discusses the ISO standard C language.
Your query was *not* about the C language.
If you put down your copies of the standards for the moment and slowly
back away from the table, you'll see that it has everything to do with
the C language:

Sorry, you fail the IQ test.
Despite the shrill squeaks from the peanut gallery, posting my query to
this newsgroup had very positive results. I've received several
enlightened suggestions through responses and private emails.
You presumably consider MSG's troll to be enlightened. Hmm.
So, no, I don't by any means condemn this newsgroup. There are
obviously some highly intelligent and experienced people among your ranks.

The one sensible thing you've posted in this thread.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/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]

On Sun, 08 Feb 2004 07:01:16 GMT, in comp.lang.c , "Mike Wahler"
<mk******@mkwahler.net> wrote:

"Mark Shelor" <ms*****@comcast.removeme.net> wrote in message
news:Kd********************@comcast.com...

it might behoove you to try and
contribute something technically

This group's archives can attest to my contributions here.

Consider them attested for.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/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]

On Sun, 08 Feb 2004 01:15:25 -0700, in comp.lang.c , Mark Shelor
<ms*****@comcast.removeme.net> wrote:

Mike Wahler wrote:

Perhaps. Note that it has also had the negative result of branding
you as clueless as well as abusive.

There now, Mike, I hope that made you feel better.

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.com/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]

"Mark Shelor" <ms*****@comcast.removeme.net> wrote in message
news:ja********************@comcast.com...

Mike Wahler wrote:

Perhaps. Note that it has also had the negative result of branding
you as clueless as well as abusive.

There now, Mike, I hope that made you feel better.

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.

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.

It seems some folks are beyond help.

*PLONK*

-Mike

[Nick Landsberg]

Mark Shelor wrote:

Sidney Cadot wrote:

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_.

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

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]

In article <Rb********************@comcast.com>,
Mark Shelor <ms*****@comcast.removeme.net> wrote:

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.

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]

On Sun, 08 Feb 2004 17:54:55 -0700, in comp.lang.c , Mark Shelor
<ms*****@comcast.removeme.net> wrote:

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*.

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.com/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]

On Sun, 08 Feb 2004 17:49:23 -0700, in comp.lang.c , Mark Shelor
<ms*****@comcast.removeme.net> wrote:

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.
cut out the hyperbole, it does nothing for your argument except make you
look an idiot.
But how utterly boring, and what a waste of talent. It
reduces the newgroups participants to a mere gaggle of lawyers.
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.programming for general programming issues.
Wow, isn't usenet wonderful.
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.
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.
As author of a portable
cryptographic digest package, I cannot predict which C compiler a
particular user might actually employ to build the package.
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.
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.
True. In a platform-independent manner.
For the newsgroup to eschew matters of
performance and efficiency is therefore short-sighted, and violates the
true spirit of the language.

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.com/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]

Mark McIntyre <ma**********@spamcop.net> scribbled the following:

On Sun, 08 Feb 2004 17:49:23 -0700, in comp.lang.c , Mark Shelor
<ms*****@comcast.removeme.net> wrote:

But how utterly boring, and what a waste of talent. It
reduces the newgroups participants to a mere gaggle of lawyers.

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.programming for general programming issues.
Wow, isn't usenet wonderful. 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. 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. As author of a portable
cryptographic digest package, I cannot predict which C compiler a
particular user might actually employ to build the package.

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.

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 (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/

[Michel Bardiaux]

Mark Shelor wrote:

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.
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.

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.
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...
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
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!
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

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 : [phone]

[Mark McIntyre]

On Mon, 09 Feb 2004 18:33:06 +0100, in comp.lang.c , Michel Bardiaux
<mi*************@peaktime.be> wrote:

Mark Shelor wrote:

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.
I agree 100% with you. This group has been taken over by a bunch of
fanatics.

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.
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.

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.com/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]

Mark Shelor <ms*****@comcast.removeme.net> wrote in message news:<z4********************@comcast.com>...

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?

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.x86
** Post the C code and possibly the assembly to
comp.os.linux.development.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]

On Sun, 08 Feb 2004 17:49:23 -0700, Mark Shelor
<ms*****@comcast.removeme.net> wrote:

Sidney Cadot wrote:
<snip>
Standard. But how utterly boring, and what a waste of talent. It
reduces the newgroups participants to a mere gaggle of lawyers.
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.

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.
Then perhaps you should try comp.programming. There, you not only get
clever C programmers (including some who frequent this group) but
cross-fertilization from expertise in other languages.

<snip>

--
Al Balmer
Balmer Consulting
re************************@att.net

[Martin Ambuhl]

Michel Bardiaux wrote:

Mark Shelor wrote:

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.

I agree 100% with you. This group has been taken over by a bunch of
fanatics.

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]

Mark Shelor wrote:

Sidney Cadot wrote:

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_.
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

[Mark Shelor]

Rob Thorpe wrote:

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.

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.

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.x86
** Post the C code and possibly the assembly to
comp.os.linux.development.apps
** Ask someone knowledgable in Perl internals about x86 and PowerPC
differences

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.

* Stop bitching about people telling you you're off topic it helps
nobody.

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

[Mike Wahler]

"Sidney Cadot" <si****@jigsaw.nl> wrote in message
news:c0**********@news.tudelft.nl...

Mark Shelor wrote:

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.

One could code separate source files for the platform-specifics,
with the desired one(s) selected at build time by e.g. a 'make'
utility's switches or arguments.

-Mike

[J. J. Farrell]

"Michel Bardiaux" <mi*************@peaktime.be> wrote in message
news:G4********************@giganews.com...

Mark Shelor wrote:

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.

I agree 100% with you. This group has been taken over by a bunch of
fanatics.

When did this takeover occur? I've only been reading this group for
about 18 years, but I've never noticed any particular change in its
nature. That nature has enabled me to continuously learn a great deal
from it in that time.

[Nils Petter Vaskinn]

On Mon, 09 Feb 2004 18:33:06 +0100, Michel Bardiaux wrote:

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...

Go to news.groups and propose a new group comp.lang.c.performance or
something like that. Have the charter include that platform/compiler
specific performance issues are on topic. Have the charter include that
performance comparisons are on topic. Have the charter include that
discussion of techniqes to get max performance across plattforms is on
topic. Have the charter include that discussion of non-standard technies
of increasing performance is on topic.

(I'd also recommend adviceing subject tags to indicate platform/compiler
combinations. So that eg someone that is only interested in issues for X86
could ignore threads other threads. Tags could look like [X86,PPC,GCC,ICC]
indicating that the poster is interested in performace on x86 and powerpc
using Gnu and Intel compilers)

Find 100+ people to vote for the group. I'd vote for and read the group
because I'd consider the discussion interesting. But it still doesn't
belong in comp.lang.c so if there currently is no place to discuss it you
need to make a place.

--
NPV

"the large print giveth, and the small print taketh away"
Tom Waits - Step right up

[Rob Thorpe]

Mark Shelor <ms*****@comcast.removeme.net> wrote in message news:<fv********************@comcast.com>...

Rob Thorpe wrote:

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.

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.

You're *right*, I agree completely.
What I said was there are no portable ways to assure performance, but
there are ways that work across a wide range of systems.
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.

That is not what I said either. I was simply saying that trying to
get a performance increase across a set of platforms is generally a
platform specific problem. Of course, if you're going to change the
algorithms you use it isn't so much. If you're going to improve the
caching behaviour it could improve for all the machines with caches,
etc. Language semantics and performance are certainly closely linked.

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.x86
** Post the C code and possibly the assembly to
comp.os.linux.development.apps
** Ask someone knowledgable in Perl internals about x86 and PowerPC
differences

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.

Ok then, first let me tell you some things about the static storage
class.

* On most platforms it's position in memory is separate from the heap
and the stack.
* It can be implemented in the same space as the global variables.
* In the Mac-OS "Mach-O" executable format uninitialized static
variables are separate, they are in the __bss section. In the Linux
ELF executable format uninitialized static variables are in the ".bss"
section in a similar way
* Again in both formats initialized variables go in the ".data" or
"__data" sections
* Uninitialized *global* variables may be anywhere, under Mach-O they
are in "__data", under Linux I think they generally are too. But they
may be in bss.
* Whenever a new process is forked off a running process these
sections will be marked copy-on-write.
* the bss is not shared, unlike the data section.
* When the program is loaded the loader creates the section, it does
not merely copy it into memory. f.e.g. the bss section can be simply
stored as a length.
* The compiler could possibly optimize static more, since it has a
smaller scope.
* As far as I know on most machines there should be little difference
in the instructions necessary to access global and "file static"
variables.
* Using heap memory will probably give you the most consistent
performance, but will probably not be the fastest.

I am only assuming you are comparing using "static" to global
variables, you haven't actually said so. Nor have you yet posted code
or pointed out where it could be found.

Any of the above could be wrong, I'm not an expert.

* Stop bitching about people telling you you're off topic it helps
nobody.

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.

I am not in the least bit frustrated by talking about this topic, I
don't mind. But it seems rather unnecessary to wind up those who are.

[Joona I Palaste]

Rob Thorpe <ro***********@antenova.com> scribbled the following:

Ok then, first let me tell you some things about the static storage
class. * On most platforms it's position in memory is separate from the heap
and the stack.
* It can be implemented in the same space as the global variables.
* In the Mac-OS "Mach-O" executable format uninitialized static
variables are separate, they are in the __bss section. In the Linux
ELF executable format uninitialized static variables are in the ".bss"
section in a similar way
* Again in both formats initialized variables go in the ".data" or
"__data" sections
* Uninitialized *global* variables may be anywhere, under Mach-O they
are in "__data", under Linux I think they generally are too. But they
may be in bss.
* Whenever a new process is forked off a running process these
sections will be marked copy-on-write.
* the bss is not shared, unlike the data section.
* When the program is loaded the loader creates the section, it does
not merely copy it into memory. f.e.g. the bss section can be simply
stored as a length.
* The compiler could possibly optimize static more, since it has a
smaller scope.
* As far as I know on most machines there should be little difference
in the instructions necessary to access global and "file static"
variables.
* Using heap memory will probably give you the most consistent
performance, but will probably not be the fastest.

I am only assuming you are comparing using "static" to global
variables, you haven't actually said so. Nor have you yet posted code
or pointed out where it could be found. Any of the above could be wrong, I'm not an expert.

Most of the above has exactly sod-all to do with C, or with any other
programming language. If you want to get deeper into the bare bones of
your computer, do it on a more appropriate newsgroup.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"The question of copying music from the Internet is like a two-barreled sword."
- Finnish rap artist Ezkimo