Mystery: static variables & performance

[Mike Wahler]

Re: Mystery: static variables & performance

"Sidney Cadot" <sidney@jigsaw. nl> wrote in message
news:c09amm$jm1 $1@news.tudelft .nl...[color=blue]
> Mark Shelor wrote:[color=green]
> > As author of a portable
> > cryptographic digest package, I cannot predict which C compiler a
> > particular user might actually employ to build the package. Yet it's
> > reasonable to want to ensure that--no matter which implementation is
> > chosen--the result will execute efficiently.[/color]
>
> True. I think you should consider if 5--30% is really worth an effort
> though.
>[color=green]
> > And there are clever ways
> > to go about this that avoid the incremental approach of simply piling up
> > a mountain of #ifdef's in the code to handle specific cases.[/color]
>
> I wonder if there really is anything other than a mountain of ifdefs.[/color]

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]

Re: Mystery: static variables &amp; performance


"Michel Bardiaux" <michel.bardiau x@peaktime.be> wrote in message
news:G4idnfgZ0Z fCWbrdRVn2jQ@gi ganews.com...[color=blue]
> Mark Shelor wrote:
>[color=green]
> >
> > OK, Sidney, I am considering it. I can certainly understand the premise
> > that a group might choose to entertain ONLY those questions that can be
> > resolved purely by a reading or clarification of (drum roll please) The
> > Standard. But how utterly boring, and what a waste of talent. It
> > reduces the newgroups participants to a mere gaggle of lawyers.[/color]
>
> I agree 100% with you. This group has been taken over by a bunch of
> fanatics.[/color]

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]

OT: How to get what you want (was: Mystery: static variables &amp; performance)

On Mon, 09 Feb 2004 18:33:06 +0100, Michel Bardiaux wrote:
[color=blue]
> Yes, that's part of the standard (ha ha) strategy: QOI on platform X is
> supposed to be topical for a group devoted to platform X. Note that
> according to the mindset of the clc thought police, that group *should*
> decide that *any* reference to other platforms than X is OT! Questions
> of comparative QOI would thus be OT everywhere...[/color]

Go to news.groups and propose a new group comp.lang.c.per formance 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]

Re: Mystery: static variables &amp; performance

Mark Shelor <mshelor@comcas t.removeme.net> wrote in message news:<fvOdnaSQ1 8a7qrXdRVn-sA@comcast.com> ...[color=blue]
> Rob Thorpe wrote:
>[color=green]
> > There are no portable ways to assure performance.
> > There are ways that work on a wide range of systems.
> > Asking about the performance of a set of different platforms is a
> > highly *platform specific* question.[/color]
>
>
> With respect, Rob, you're simply not correct.
>
> There are clever ways to use the C language that--in general--are more
> efficient across a wide range of platforms. I illustrated this point
> earlier with a simple string-copy example.[/color]

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.
[color=blue]
> I have no desire to interfere with your right to believe that issues of
> C language definition are completely separable from issues of
> performance. On the other hand, you have an opportunity to learn
> something here: by making the realization that these two realms are
> indeed linked.[/color]

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.
[color=blue][color=green]
> > Do this:
> >
> > * Look at the assembly produced if you can
> > * If you can't figure it out
> > ** Post the C code and the assembly to somewhere like
> > comp.lang.asm.x 86
> > ** Post the C code and possibly the assembly to
> > comp.os.linux.d evelopment.apps
> > ** Ask someone knowledgable in Perl internals about x86 and PowerPC
> > differences[/color]
>
>
> First off, let me say that I appreciate your taking the time to
> enumerate this list of suggestions. They would indeed be helpful if I
> were only interested in the package's performance on a limited set of
> platforms.
>
> The citing of the Intel/Linux and PowerPC/BSD examples merely served to
> illustrate that there can be a *dramatic* difference in performance due
> to the use of the static storage class. Perhaps there are alternative
> ways to set up the SHA message schedule processing in C that are not
> only portable, but also more likely to be uniformly-efficient across a
> wide range of platforms? I appreciate that it might require a great
> deal of experience in language and compiler design to answer a question
> such as this, but I assume such folks inhabit this newsgroup.[/color]

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.
[color=blue][color=green]
> > * Stop bitching about people telling you you're off topic it helps
> > nobody.[/color]
>
>
> Not being a fan of censorship or churlish remarks, I'll overlook this
> demand. Perhaps you can save yourself a great deal of frustration by
> simply not participating in this thread, if that's acceptable to you.[/color]

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]

Re: Mystery: static variables &amp; performance

Rob Thorpe <robert.thorpe@ antenova.com> scribbled the following:[color=blue]
> Ok then, first let me tell you some things about the static storage
> class.[/color]
[color=blue]
> * 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.[/color]
[color=blue]
> Any of the above could be wrong, I'm not an expert.[/color]

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 (palaste@cc.hel sinki.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

[Alan Balmer]

Re: Mystery: static variables &amp; performance

On Mon, 09 Feb 2004 18:42:57 -0700, Mark Shelor
<mshelor@comcas t.removeme.net> wrote:
[color=blue]
>Rob Thorpe wrote:
>[color=green]
>> There are no portable ways to assure performance.
>> There are ways that work on a wide range of systems.
>> Asking about the performance of a set of different platforms is a
>> highly *platform specific* question.[/color]
>
>
>With respect, Rob, you're simply not correct.
>
>There are clever ways to use the C language that--in general--are more
>efficient across a wide range of platforms. I illustrated this point
>earlier with a simple string-copy example.[/color]

Yes, you presented:

<begin quote>
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
<end quote>

An observation - this is probably not the most efficient way to
perform a string copy. The most efficient way is probably to use the
strcpy() library function, because the implementor knows how to
optimize the operation on the specific platform he's implementing it
for.

"Clever" programmers sometimes outsmart themselves.

<snip>

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

[Mark McIntyre]

Re: Mystery: static variables &amp; performance

On Mon, 09 Feb 2004 18:42:57 -0700, in comp.lang.c , Mark Shelor
<mshelor@comcas t.removeme.net> wrote:
[color=blue]
>Rob Thorpe wrote:
>[color=green]
>> There are no portable ways to assure performance.
>> There are ways that work on a wide range of systems.
>> Asking about the performance of a set of different platforms is a
>> highly *platform specific* question.[/color]
>
>
>With respect, Rob, you're simply not correct.
>
>There are clever ways to use the C language that--in general--are more
>efficient across a wide range of platforms. I illustrated this point
>earlier with a simple string-copy example.[/color]

Did you? And what range of systems did you verify that it was more
efficient on, and where in the C standard does it say that this shall be
so?

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


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

[Mark Shelor]

Re: Mystery: static variables &amp; performance

Alan Balmer wrote:
[color=blue]
> Yes, you presented:
>
> <begin quote>
> 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
> <end quote>
>
> An observation - this is probably not the most efficient way to
> perform a string copy. The most efficient way is probably to use the
> strcpy() library function, because the implementor knows how to
> optimize the operation on the specific platform he's implementing it
> for.
>
> "Clever" programmers sometimes outsmart themselves.[/color]


Thanks for your attention, Alan, but you've still missed the point. The
purpose of the example was not to find the most efficient way to perform
string copies. Rather, it was to show that certain C language
constructs (such as combined pointer-dereferencing/post-incrementing)
are more efficient than others in carrying out prescribed tasks. This
demonstrates that language semantics and language definition are not
always de-coupled from issues of performance.

Regards, Mark

[Mark McIntyre]

Re: Mystery: static variables &amp; performance

On Tue, 10 Feb 2004 15:43:55 -0700, in comp.lang.c , Mark Shelor
<mshelor@comcas t.removeme.net> wrote:
[color=blue][color=green]
>> while ((*s++ = *t++) != '\0')
>> ;[/color][/color]
[color=blue]
>it was to show that certain C language
>constructs (such as combined pointer-dereferencing/post-incrementing)
>are more efficient than others in carrying out prescribed tasks.[/color]

In order to show that, you;d have to come up with a different way to do the
above, and then prove it was less efficient on all platforms. And you'll
have to provide a definition of efficient (less code, easier to type,
readable, faster, less likely to pagefault, fewer registers used? etc)
[color=blue]
>This
>demonstrates that language semantics and language definition are not
>always de-coupled from issues of performance.[/color]

When you've proved that it is more efficient, then I'll agree.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.c om/ms3/bchambless0/welcome_to_clc. html>


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

[Mark Shelor]

Re: Mystery: static variables &amp; performance

Mark McIntyre wrote:
[color=blue]
> On Tue, 10 Feb 2004 15:43:55 -0700, in comp.lang.c , Mark Shelor
> <mshelor@comcas t.removeme.net> wrote:
>[color=green][color=darkred]
>>> while ((*s++ = *t++) != '\0')
>>> ;[/color][/color]
>[color=green]
>>it was to show that certain C language
>>constructs (such as combined pointer-dereferencing/post-incrementing)
>>are more efficient than others in carrying out prescribed tasks.[/color]
>
> In order to show that, you;d have to come up with a different way to do the
> above, and then prove it was less efficient on all platforms. And you'll
> have to provide a definition of efficient (less code, easier to type,
> readable, faster, less likely to pagefault, fewer registers used? etc)
>[color=green]
>>This
>>demonstrate s that language semantics and language definition are not
>>always de-coupled from issues of performance.[/color]
>
> When you've proved that it is more efficient, then I'll agree.[/color]


With respect, Mark, your agreement or disagreement on this point is not
relevant to the topic.

If, on the other hand, you feel that the topic itself is not relevant to
this newsgroup, then ceasing to contribute to this thread will spare you
further frustration.

Regards, Mark

[Rich Dawes]

Re: Mystery: static variables &amp; performance

pete wrote:
[color=blue]
> [snip]
>
> http://www.bluejo.demon.co.uk/poetry...ia/lurkers.htm
>[/color]

Thank you, Pete (and to Jo Walton) -- that made my night!

-Rich

[Mark Shelor]

Re: Mystery: static variables &amp; performance

Rich Dawes wrote:
[color=blue]
> pete wrote:[color=green]
>>
>> http://www.bluejo.demon.co.uk/poetry...ia/lurkers.htm[/color]
>
> Thank you, Pete (and to Jo Walton) -- that made my night![/color]


Absolutely side-splitting. Let's hope that Triumph The Insult Comic Dog
doesn't read it and suffer a nervous breakdown.

It's now abundantly clear, given the length and content of this thread,
that the comp.lang.c guardians of purity are themselves not averse to
off-topic posting. They simply don't want others to enjoy the same
privileges. It even appears that some of these guardians have entered a
realm where jejune poems about newsgroup lurkers are somehow more
relevant to the C programming language than static variables and
performance.

Once again, there are certainly intelligent and helpful posts that occur
here. So, it's not quite fair to say that this newsgroup has the same
relation to the C language that a Star Trek convention does to rocket
science. But it IS demonstrably less helpful than newsgroups for other
languages such as Perl. Bear in mind that your abruptness--not even to
mention rudeness--only helps to stigmatize C as the language of
crotchety old men. Why give added ammunition to the Java generation who
argue that a new language is necessary for the modern world?

Perhaps one thing we could agree on is C's desirability and aptness for
system implementation in general. Why not contribute to serving that
end? It's a lot more satisfying than grandstanding, or hitting other
people over the head in a vain attempt to feel superior.

Mark

[Mark McIntyre]

Re: Mystery: static variables &amp; performance

On Sat, 14 Feb 2004 16:08:08 -0700, in comp.lang.c , Mark Shelor
<mshelor@comcas t.removeme.net> wrote:
[color=blue]
>Rich Dawes wrote:
>[color=green]
>> pete wrote:[color=darkred]
>>>
>>> http://www.bluejo.demon.co.uk/poetry...ia/lurkers.htm[/color]
>>
>> Thank you, Pete (and to Jo Walton) -- that made my night![/color]
>
>
>Absolutely side-splitting. Let's hope that Triumph The Insult Comic Dog
>doesn't read it and suffer a nervous breakdown.
>
>It's now abundantly clear, given the length and content of this thread,[/color]

FYI postings about topicality are topical.
[color=blue]
>that the comp.lang.c guardians of purity are themselves not averse to
>off-topic posting.[/color]

The occasional bit of humour is acceptable.
[color=blue]
>They simply don't want others to enjoy the same privileges.[/color]

Bullsh*t.
[color=blue]
>Perhaps one thing we could agree on is C's desirability and aptness for
>system implementation in general. Why not contribute to serving that
>end? It's a lot more satisfying than grandstanding, or hitting other
>people over the head in a vain attempt to feel superior.[/color]

Yeah, whatever. Another ottfopic nazi.

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


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

[Sidney Cadot]

Re: Mystery: static variables &amp; performance

Mark McIntyre wrote:
[color=blue]
> Yeah, whatever. Another ottfopic nazi.[/color]

Mark,

I live in a country that suffered from Nazi occupation in WWII.
Referring to someone as a nazi in an offhand way, as you do, is quite
deeply offensive, not only to the recipient, but also to people for whom
these terms hit a lot closer to home than you may think is possible. To
most Europeans, a nazi is not just some term coming from a sitcom, but a
name associated with perhaps the most despicable regime the world has
ever seen.

In other words, tone it down a bit, if you would.

Regards,
Sidney

[Mark Shelor]

Re: Mystery: static variables &amp; performance

Mark McIntyre wrote:
[color=blue]
> Yeah, whatever. Another ottfopic nazi.[/color]


If your purpose in using such an inflammatory term was to bring
unwarranted drama to your stunningly inconsequential post, you could
have found a far less offensive way to do it.

Make no mistake: you do not possess the comedic skills of Mel Brooks or
Jerry Seinfeld. Your remark was simply mean-spirited. Do you honestly
think you won any points by such a display?