Re: Mystery: static variables & performance

From: nrk (ram_nrk2000_at_devnull.verizon.net)
Date: 02/18/04 

Date: Wed, 18 Feb 2004 17:30:30 GMT

R. Rajesh Jeba Anbiah wrote:

> Mark Shelor <mshelor@comcast.removeme.net> wrote in message
> news:<rNmdnVGO_9XlNa_dRVn-hg@comcast.com>...
> <snip>
>> And, my *personal* view is that this group would be richer and more
>> broadly helpful if it oriented itself around the "computer language c"
>> instead of the "computer standard c". But these matters are ultimately
>> up to the newsgroup "in toto" to decide; they're not up to selected
>> groups of individuals to dictate, no matter how loud their voices.
>>
>> From a practical viewpoint, however, it is far more effective in the
>> long-run for participants to simply ignore posts that they don't
>> consider topical. Then, if most or all participants feel the same way,
>> no responses will be issued to questions that are thereby de-facto
>> off-topic. This is the way to manifest a true consensus. Off-topic
>> posters will quickly realize the situation when they receive no
>> responses to their questions. And, they may even get the motivation at
>> that point to read the newsgroup FAQ if they can't understand the
>> silence.
>>
>> In my own case, I received helpful responses to the query on static
>> variables and performance. And, these responses stand boldly in the
>> thread, so the "lurkers support me in email" disbelievers will have to
>> remain silent this time. Were my query truly off-topic, this wouldn't
>> have happened. Given the length of (and diversity of responses on) this
>> thread, it's obvious that there's no de-facto consensus on what's
>> strictly topical. Some people are simply louder and more aggressive
>> than others.
>
> I'm the idiot who read c.l.c almost frequently for about 4-years.
> If I recall correct, many of your comments are sometimes implied by
> many people and most of them are gone/plonked/few of them joined. The
> interesting thing I have found here is many regulars are respecting
> your views or at least listening to your views---which hardly happend
> before.
>

Rajesh, it is unfortunate that inspite of spending around 4 years in
CLC, you haven't realized why the regulars are sticklers for topicality and
to questions related to the ANSIC C Standard. It is not because C is a toy
language. It is not because all (or even most) regulars here are old
people who don't want to dig any more. It simply has to do with the fact
that C is a very versatile and pervasive language. If one were to start
answering any and all questions merely on the basis that it involved C in
some way, the group will become well near useless. As they say, you can
either be a rather poor jack of all trades or be a good master of one.
This group is a good master at answering questions related to the C
language as it is described in the ANSI/ISO standards. By being so picky
about topicality, CLC actually does a favor to off-topic posters. By
forcing them to go to a domain that's richer with experts in their specific
issues it helps them get better quality help than they would get here.

> Interestingly, in this thread I've found some good views about the
> topicality of c.l.c. For a very longtime, I was thinking myself: K&R
> says C is used to write OS/compilers/etc, but many people here why
> flame if such questions came here. I was also thinking myself: is ISO
> C is a toy language; sometimes ago someone posted a script for itoa()
> claiming that it's a "pure ISO C" code; I used to wonder if there is
> any compilers/OS written in ISO C; also I would think, this standard
> is for the old people who don't like to dig more. And,... of course
> yet I haven't got any valid answers.
>

The answers are right in front of your eyes. Don't wonder why you're not
able to see them as long as you have your eyes shut.

FWIW, Mark's original question was a marginal case IMO. For instance,
declaring his variable static inside a function has the effect that the
array is initialized exactly once. Making it non-static would change this.
Also, he could remove the static and try getting the same effect by passing
in the array in question as a parameter to the function. This way he gets
to maintain state across calls. He can even keep the same call interface
to the end-user by building a wrapper function that calls his inner
function in question. He could also try hinting to the compiler that
certain variables inside the function will be accessed very frequently by
making their storage class "register" (IMHO, most modern compilers
completely ignore this and do a better job of deciding how to allocate
registers).

Barring this, there might be issues as to how his compiler is compiling the
specific code in question. Those questions are best answered by experts
who know how his particular platform and implementation works.

There may also be algorithmic improvements that might benefit him more than
any of this kind of micro-optimizations. Again, that's best answered by
experts who reside elsewhere like comp.programming (or even cryptography
groups).

Mark simply refuses to accept that the generic *all*-platform-encompassing
answers to his question (barring algorithmic improvements) are borderline
useless and that he should perhaps restrict the scope to a handful of
architectures that dominate in today's world and optimize his
implementation for them. Once he does that, he can then ask experts in
those relevant architectures as to what he can do to optimize his code.

-nrk.

PS: Your book, section 4.2: The WAR style example of strcmp is atrocious
IMO. If you must insist on a single return, here's a clearer version of
strcmp:

    int strcmp(const char *s1, const char *s2) {
        while ( *s1 == *s2 && *s1 )
            ++s1, ++s2;

        return *s1 - *s2;
    }

> With lots & lots of wishes.
> 

-- 
Remove devnull for email

Relevant Pages

  • Re: turing completeness
    ... > Questions of topicality are always, by definition, on topic. ... that does not mean that the language ... The difficulty in developing a production OS is NOT resident in the ... wrote, for money, an entire compiler that is still in use 15 years ...
    (comp.programming)
  • Re: "STL from the Ground Up"
    ... high-level intermediate language than can interoperate with many other ... If your language lacks expressive features then you cannot write code ... memory management in comparison. ... Mostly because type errors mean that the programmer and compiler disagree ...
    (comp.programming)
  • Re: A note on computing thugs and coding bums
    ... It would handle international characters if the execution character ... method I used in "Build Your Own .Net Language and Compiler". ... work areas and counting on Nul is an illusion. ...
    (comp.programming)
  • Re: WaitForSingleObject() will not deadlock
    ... represent an incorrect implementation of the language. ... the *compiler* does not guarantee this. ... but to state it in terms of the execution instead of the formal semantics of the language ... as long as the optimizations do not change the semantics of the language). ...
    (microsoft.public.vc.mfc)
  • Re: subroutine stack and C machine model
    ... Use a compiler optimizer ... higher determinism means that optimizer has more information. ... C programmers like to brag that their "language" is more ... prospective computer science majors at Princeton. ...
    (comp.lang.c)