Faster for() loops? - Page 4

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Faster for() loops?
Quoted text here. Click to load it

Most posts are *not* top posted, and this includes yours, therefore it
has been implicitly agreed upon by the majority of participants.

Had you checked the history of comp.lang.c you would find that this has
been the case for a long time, and also that the people who advocate
top-posting are *not* in general long time participants and that almost
every post by a long time participant in comp.lang.c on the subject has
been against top-posting and in favour of bottom and middle posting.

 > You are free to express your
Quoted text here. Click to load it

Feel free, but it is still true that the majority of the regulars on
comp.lang.c have only posted messages against top-posting and for
bottom/middle posting.

Quoted text here. Click to load it

And the majority of the regulars in comp.lang.c consider top posting to
be impolite.

Quoted text here. Click to load it

Most of the regulars do not respond because they agree with the posts
regulars (do I count as a regular yet?) or semi-regulars make against
top posting.

So far I have not seen any of those more knowledgeable than me from
comp.lang.c post in favour of top posting, and the posts from those
comp.lang.c regulars that have participated in this sub-thread have all
been against it.
--
Flash Gordon
Living in interesting times.
We've slightly trimmed the long signature. Click to see the full one.
Re: Faster for() loops?


Quoted text here. Click to load it

And how many regulars from comp.lang.c have come out in favor of
top-posting? Exactly none. This has been hashed out so many times that
most feel no need to chime in.

We (c.l.c) don't presume to speak for comp.arch.embedded, of course.





Brian

Re: Faster for() loops?

Quoted text here. Click to load it

The vast majority of long-term Usenet readers have lost whatever faith
in the educability of the human race that they might ever have had.

So when another person starts top-posting and insisting that they have
some divine right to ignore long-standing protocols that have developed
to ease communication in these groups, we just make use of the scoring
features on our news-reading programs.

Those who don't use news-readers with scoring appear to use killfiles
instead.

You'll never hear them complain because they can't hear you talk
anymore.

There *is* a reason long-standing cultures develop protocols for
communication, and it's not just to annoy others.

cheers, Rich.



--
rich walker         |  Shadow Robot Company | snipped-for-privacy@shadow.org.uk
technical director     251 Liverpool Road   |
We've slightly trimmed the long signature. Click to see the full one.
Re: Faster for() loops?
Quoted text here. Click to load it


I, for one, didn't see a need to post a "Me too!" signifying agreement
with the people who asked you not to top-post, as my -assumption- was
that you were a reasonable person who would be able to learn upon
hearing an idea once instead of having to have it repeated multiple
times. Was that a misjudgement on my part??


Quoted text here. Click to load it

"the vast majority" don't read literally hundreds of technical
messages every day and try to keep them mentally straight so they
can give the right advice to the right person. "the vast majority"
don't spend hours every day doing free technical research and
consulting for other people.
--
University of Calgary researcher Christopher Auld has found that
milk is the most "rational addiction" amongst the several studied.

Re: Faster for() loops?
(Walter Roberson) writes:
...
 > >Only 2 or 3 people told me not to top post.  That's 3 out of 1000?  3 out of
 > >10,000?  Who knows.  That suggests to me that the vast majority of people
 > >don't give a damn.
 >
 > I, for one, didn't see a need to post a "Me too!" signifying agreement
 > with the people who asked you not to top-post, as my -assumption- was
 > that you were a reasonable person who would be able to learn upon
 > hearing an idea once instead of having to have it repeated multiple
 > times. Was that a misjudgement on my part??

In general I ignore all articles that are toppostings and all articles
that do not quote anything from the article responded to.
--
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn  amsterdam, nederland; http://www.cwi.nl/~dik /

Re: top/bottom post was: Faster for() loops?



Quoted text here. Click to load it

You know, most mail clients have a setting to top or bottom post on
replies.  Conformance to the guidelines is something that should be
considered if one wants to be a 'good citizen,' (IMO, that what makes
ppl civilized) unless of course you get some satisfaction by giving anal
retentive ppl high blood pressure and even more, instill in them even
further need for their crusade.  I especially like it when they berate
ppl for a miscue of non-conformance.  Was it because they got sand
kicked in their face when they were in first grade and they made it the
lifes work to 'exercise power' over ppl?  Wow, some ppl really need to
get a life. lol
John

Re: top/bottom post was: Faster for() loops?


Quoted text here. Click to load it


Another idiot for the bozo bin. Man, comp.arch.embedded is coming off
WAY worse than I would have expected. Starting to think about just
filtering out X-posts to that group.


Brian

Re: top/bottom post was: Faster for() loops?
Quoted text here. Click to load it

<plonk>

Get your priorities straight, friend.

Steve
http://www.fivetrees.com



Re: top/bottom post was: Faster for() loops?
Quoted text here. Click to load it
This is the thread that never ends, it just goes on and on my friends!
Some people started posting to it, not knowing what it was, and they'll
be posting forever just because...

Sorry. Last post, promised. :-)

S.

Re: Faster for() loops?
'king 'ell - Some people.

If you are going to "*plonk*", why do you have to broadcast it.  That's the
equivalent of putting your fingers in your ears and going, baaaa!  bblaah!
I'm not listening!

Plonker.


Quoted text here. Click to load it



Re: Faster for() loops?
Quoted text here. Click to load it

<SNIP>

You don't get it, eh. Nobody knowledgable is reading this.
Last message before plonk.

Quoted text here. Click to load it

Groetjes Albert

--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
We've slightly trimmed the long signature. Click to see the full one.
Re: Faster for() loops?
I think you don't get it.
You are an anal retent.

You'll find this on the google archives, I'm sure.
Otherwise, why bother to make the post, plonker.


Quoted text here. Click to load it



Re: Faster for() loops?
Quoted text here. Click to load it

If you are working with just 512 bytes of program memory, then you
probably should not be writing in C. C as a programming language makes
no attempt to mimimize code space. And though it is a matter outside of the
standards, most compilers prefer to trade off space for increased speed.
--
These .signatures are sold by volume, and not by weight.

Re: Faster for() loops?
If your counting bytes, all I can say is that you better make sure your
project does suffer from 'requirements creep'!  While it *may* be an
interesting exercise to find the most efficient compiler, coding style
in the form of the for loop in this thread, will also impact the
efficiencies.  I would bet there are plenty of other areas to save space
(i.e., how many useless libraries are being linked in?-a compiler issue,
or, what architectural changes should be made to your design such as
getting rid of large amounts of shared variables-do they really need to
be shared?).  OTOH, if you are in the $10 retail produce area then
saving $0.20 over the next processor in the line may be worth all the
extra engineering time.  Somehow, after living thought many sides of
this problem, throwing hardware at it is usually the best approach. Just
a personal opinion from experience, your mileage and situation may vary.....
John


Joe Butler wrote:

Quoted text here. Click to load it

Re: Faster for() loops?
Quoted text here. Click to load it

I think this is a very personal experience related thing. My experience for
example it the opposite of yours. I developed cost sensitive high volume
products for nearly 20 years and not once was throwing hardare at it a
viable solution. We used C twice and both times had to go in and make
significant changes to reduce code size. However, this was not so much the
fault of C itself or the compilers, we had assumed software engineers from
another department who were 'brought up' on C were capable of writing space
efficient code.  Thereafter we wrote everything in assembler.

At one million units, a saving of 20 cents is $200K. That buys a lot of
engineering time.

Ian


Re: Faster for() loops?

Quoted text here. Click to load it

The answer to that is the same remedy offered to all sufferers of
premature optimisation: Measure First.


Re: Faster for() loops?
On Mon, 26 Sep 2005 12:11:23 +0530, in comp.lang.c , "Neo"

Quoted text here. Click to load it

(that reversing loop order is faster)

The page is talking rot. It *may* be faster. It *may* be slower. The
only way to know is to benchmark your particular implementation in the
specific case you're examining.

Quoted text here. Click to load it

Benchmark.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html
We've slightly trimmed the long signature. Click to see the full one.
Re: Faster for() loops?
Quoted text here. Click to load it

Actually, the page is talking rubbish about a great deal more than just
this case.  It's full of generalisations that depend highly on the
compiler and target in question (the post is cross-posted to
comp.arch.embedded, so we are looking at a wide range of targets).  "Use
switch instead of if...else..." (varies widely according to
target/compiler and the size of the switch), "Avoid ++, -- in while ()
expressions" (good compilers work well with such expressions), "Use
word-size variables instead of chars" (great for PPC, indifferent for
msp430, terrible for AVR), "Addition is faster than multiplication - use
'val + val + val' instead of 'val * 3' " (wrong for most compiler/target
combinations).

It's a nice idea to try to list such tips, but the page is badly out of
date, and makes all sorts of unwarranted assumptions.

So, as Mark says, benchmark your implementation.  Also examine the
generated assembly code (you do understand the generated assembly?  If
not, forget about such minor "optimisations".)  And remember Knuth's
rules regarding such code-level optimisations:

1. Don't do it.
2. (For experts only) Don't do it yet.

Re: Faster for() loops?

Quoted text here. Click to load it

Catastrophic for PIC18.

Quoted text here. Click to load it

And the implication is especially wrong for any val*n where n>3.

--T


Re: Faster for() loops?
Depends what you're doing.  If you're accessing a large chunk of memory on a
system with
cache, you want to go through incrementing addresses to maximize the use of
cache.
Decrementing through memory is generally pessimal.

--
#include <standard.disclaimer>
 _
Kevin D Quitt  USA 91387-4454         96.37% of all statistics are made up

Site Timeline