473,573 Members | 2,778 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Mystery: static variables & performance

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

Nov 14 '05 #1
115 7521
On Fri, 06 Feb 2004 19:35:28 -0700, Mark Shelor
<ms*****@comcas t.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.l earn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Nov 14 '05 #2
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

Nov 14 '05 #3
Mark Shelor <ms*****@comcas t.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.hel sinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Insanity is to be shared."
- Tailgunner
Nov 14 '05 #4
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

Nov 14 '05 #5
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

Nov 14 '05 #6
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
Nov 14 '05 #7
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********@yah oo.com) (cb********@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!
Nov 14 '05 #8
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
Nov 14 '05 #9
MSG
Mark Shelor <ms*****@comcas t.removeme.net> wrote in message news:<z4******* *************@c omcast.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
Nov 14 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

109
4123
by: MSG | last post by:
Michel Bardiaux <michel.bardiaux@peaktime.be> wrote in message news:<G4idnfgZ0ZfCWbrdRVn2jQ@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...
0
8033
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. ...
0
8077
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the...
0
6426
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then...
1
5601
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes...
0
5294
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert...
0
3739
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
2224
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
1
1316
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
0
1044
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.