Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Double increment question.

Reply
Thread Tools

Double increment question.

 
 
av
Guest
Posts: n/a
 
      07-26-2006
On Tue, 25 Jul 2006 08:03:14 -0400, Eric Sosman wrote:
>Robbie Hatley wrote:
>> [...]
>> memcpy did occur to me, yes. But I'm writing a program which I want to
>> be as small and fast as possible, so I'm doing things "manually". [...]

>
> Digging a hole in the ground is a wearisome and tedious
>task, and I'd like it to take as little time as possible.
>That's why I told that guy with the backhoe to go somewhere
>else, threw away my silly old shovel, and am now "doing things
>manually" by scrabbling in the dirt with my fingernails.
>
> More seriously, it seems more than a little likely that
>you are committing the sin of premature optimization. Until
>and unless you have MEASURED a performance problem -- not
>hypothecated, not supposed, not "it stands to reason-ed" --
>until you have made MEASUREMENTS it is irresponsible folly to
>micro-optimize.
>
> "Premature optimization is the root of all evil."
> -- D.E. Knuth


don't know

> "We follow two rules in the matter of optimization:
> Rule 1: Don't do it.
> Rule 2 (for experts only): Don't do it yet."
> -- M.A. Jackson


these rules are wrong

> "More computing sins are committed in the name of efficiency
> (without necessarily achieving it) than for any other single
> reason, including blind stupidity."
> -- W.A. Wulf


this can be for the c language too (that would find the speed with 0
terminated string but find only difficulties and buffers overflows)
it seems i can think of a string class that do everyting more simple
and with no possible errors in each its 'atomic' operations

> In other words, I'm not the only person crying that ab initio
>micro-optimization is folly; smart people do so, too. Be smart.


i not agree if assembly can reduce the executable dimendion for a
factor 10 and the code is in the cache of cpu
 
Reply With Quote
 
 
 
 
av
Guest
Posts: n/a
 
      07-26-2006
On Tue, 25 Jul 2006 07:58:19 GMT, Robbie Hatley wrote:
>"Richard Riley" wrote:
>> "Robbie Hatley" <(E-Mail Removed)> writes:
>>
>> > Hello, group. I've been doing too much C++ programming lately, and
>> > I'm starting to become rusty at some aspects of the C way of doing
>> > things, esp. efficient low-level data copies:
>> > while (ptr2 < right) *ptr1++ = *ptr2++; // WILL THIS WORK???
>> > Is it guaranteed that (*ptr2) will always get assigned to (*ptr1) before
>> > either increment occurs???

>>
>> Yes.

>
>Thanks.
>
>> Same as in C++ when dealing with char pointers isnt it?

>
>If it works that way with the one, I suppose it does with the
>other. However, my usual way of coping strings in C++ is:
>
> std::string str1 ("Fred"); // make string str1 containing "Fred"
> std::string str2 (str1); // make string str2 and copy str1 to str2
>
>A bit simpler than in C.


in c++ all can be more simple and secure than c
 
Reply With Quote
 
 
 
 
Flash Gordon
Guest
Posts: n/a
 
      07-26-2006
av wrote:
> On Tue, 25 Jul 2006 08:03:14 -0400, Eric Sosman wrote:
>> Robbie Hatley wrote:
>>> [...]
>>> memcpy did occur to me, yes. But I'm writing a program which I want to
>>> be as small and fast as possible, so I'm doing things "manually". [...]

>> Digging a hole in the ground is a wearisome and tedious
>> task, and I'd like it to take as little time as possible.
>> That's why I told that guy with the backhoe to go somewhere
>> else, threw away my silly old shovel, and am now "doing things
>> manually" by scrabbling in the dirt with my fingernails.
>>
>> More seriously, it seems more than a little likely that
>> you are committing the sin of premature optimization. Until
>> and unless you have MEASURED a performance problem -- not
>> hypothecated, not supposed, not "it stands to reason-ed" --
>> until you have made MEASUREMENTS it is irresponsible folly to
>> micro-optimize.
>>
>> "Premature optimization is the root of all evil."
>> -- D.E. Knuth

>
> don't know
>
>> "We follow two rules in the matter of optimization:
>> Rule 1: Don't do it.
>> Rule 2 (for experts only): Don't do it yet."
>> -- M.A. Jackson

>
> these rules are wrong


What makes you think that you know better than well respected experts?

>> "More computing sins are committed in the name of efficiency
>> (without necessarily achieving it) than for any other single
>> reason, including blind stupidity."
>> -- W.A. Wulf

>
> this can be for the c language too (that would find the speed with 0
> terminated string but find only difficulties and buffers overflows)
> it seems i can think of a string class that do everyting more simple
> and with no possible errors in each its 'atomic' operations


Classes are off topic here. In any case, what you are saying has nothing
significant that I can see that is relevant to optimisation. Buffer
overflows are a rather different problem, and micro-optimisation
increases the likely hood of them and other errors.

>> In other words, I'm not the only person crying that ab initio
>> micro-optimization is folly; smart people do so, too. Be smart.

>
> i not agree if assembly can reduce the executable dimendion for a
> factor 10 and the code is in the cache of cpu


Most people will *not* be able to get anything like that level of
improvement. They are even less likely to get it whilst staying with C,
as evidence a recent thread in which someone posted what they thought
was a more efficient solution, but it was demonstrated to be generally
*less* efficient.

One is in general far more likely to achieve significant improvements be
selecting the correct algorithm and design. Only when those are optimal,
and if there is still a demonstrable problem, should one use
measurements to find the problem areas and optimise them.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc
 
Reply With Quote
 
Chris Dollin
Guest
Posts: n/a
 
      07-26-2006
av wrote:

>> "We follow two rules in the matter of optimization:
>> Rule 1: Don't do it.
>> Rule 2 (for experts only): Don't do it yet."
>> -- M.A. Jackson

>
> these rules are wrong


Why do you think that?

Address what needs to be addressed when it needs to be addressed.

("Not optimising" doesn't mean "write stupidly slow code".)

--
Chris "slow and steady beats SIGSEGV" Dollin
"We did not have time to find out everything we wanted to know." /A Clash of Cymbals/

 
Reply With Quote
 
av
Guest
Posts: n/a
 
      07-26-2006
On Wed, 26 Jul 2006 12:19:13 +0100, Flash Gordon wrote:
>av wrote:
>> On Tue, 25 Jul 2006 08:03:14 -0400, Eric Sosman wrote:
>>> Robbie Hatley wrote:
>>>> [...]
>>> "Premature optimization is the root of all evil."
>>> -- D.E. Knuth

>>
>> don't know
>>
>>> "We follow two rules in the matter of optimization:
>>> Rule 1: Don't do it.
>>> Rule 2 (for experts only): Don't do it yet."
>>> -- M.A. Jackson

>>
>> these rules are wrong

>
>What makes you think that you know better than well respected experts?


i find a lot of fun searching for optimisation code (and algorithm)
and until now not have wrong experiences
i would translate my c files in assembly and i'm sure in the
translated files, instructions will be between 1/10 and 1/100 than C
files, but the cpu has enough cache for the code and i'm lazy

>>> "More computing sins are committed in the name of efficiency
>>> (without necessarily achieving it) than for any other single
>>> reason, including blind stupidity."
>>> -- W.A. Wulf

>>
>> this can be for the c language too (that would find the speed with 0
>> terminated string but find only difficulties and buffers overflows)
>> it seems i can think of a string class that do everyting more simple
>> and with no possible errors in each its 'atomic' operations

>
>Classes are off topic here. In any case, what you are saying has nothing
>significant that I can see that is relevant to optimisation. Buffer
>overflows are a rather different problem, and micro-optimisation
>increases the likely hood of them and other errors.


don't all you want to optimise when use 0 ended strings?
is it that a "More computing sins ..."?

>>> In other words, I'm not the only person crying that ab initio
>>> micro-optimization is folly; smart people do so, too. Be smart.

>>
>> i not agree if assembly can reduce the executable dimendion for a
>> factor 10 and the code is in the cache of cpu

>
>Most people will *not* be able to get anything like that level of
>improvement.
>They are even less likely to get it whilst staying with C,
>as evidence a recent thread in which someone posted what they thought
>was a more efficient solution, but it was demonstrated to be generally
>*less* efficient.


think for find efficiency is never wrong because one can test the
solution. the only wrong i see is the time someone spend to think
about it. But is "to think" wrong?

>One is in general far more likely to achieve significant improvements be
>selecting the correct algorithm and design. Only when those are optimal,
>and if there is still a demonstrable problem, should one use
>measurements to find the problem areas and optimise them.


one good idea is better that all the optimal-ways walk

 
Reply With Quote
 
av
Guest
Posts: n/a
 
      07-26-2006
On Wed, 26 Jul 2006 13:39:24 +0100, Chris Dollin wrote:
>av wrote:
>>> "We follow two rules in the matter of optimization:
>>> Rule 1: Don't do it.
>>> Rule 2 (for experts only): Don't do it yet."
>>> -- M.A. Jackson

>>
>> these rules are wrong

>
>Why do you think that?
>
>Address what needs to be addressed when it needs to be addressed.
>
>("Not optimising" doesn't mean "write stupidly slow code".)


i have a routine R1 that with input A has output B that follow the
algo C.
optimisation is
search a routine R2 that with input A has output B that follow an algo
H that has minimum instructions for doing calculation

are we agreeing on that definition?

why i would not try to write the "H" routine?
in my little experience errors could be in R1 too ...
and think on that routine can make to see errors in R1 too
 
Reply With Quote
 
Andrew Poelstra
Guest
Posts: n/a
 
      07-26-2006
On 2006-07-26, av <(E-Mail Removed)> wrote:
> On Tue, 25 Jul 2006 07:58:19 GMT, Robbie Hatley wrote:
>>"Richard Riley" wrote:
>>> "Robbie Hatley" <(E-Mail Removed)> writes:
>>>
>>> > Hello, group. I've been doing too much C++ programming lately, and
>>> > I'm starting to become rusty at some aspects of the C way of doing
>>> > things, esp. efficient low-level data copies:
>>> > while (ptr2 < right) *ptr1++ = *ptr2++; // WILL THIS WORK???
>>> > Is it guaranteed that (*ptr2) will always get assigned to (*ptr1) before
>>> > either increment occurs???
>>>
>>> Yes.

>>
>>Thanks.
>>
>>> Same as in C++ when dealing with char pointers isnt it?

>>
>>If it works that way with the one, I suppose it does with the
>>other. However, my usual way of coping strings in C++ is:
>>
>> std::string str1 ("Fred"); // make string str1 containing "Fred"
>> std::string str2 (str1); // make string str2 and copy str1 to str2
>>
>>A bit simpler than in C.

>
> in c++ all can be more simple and secure than c


Hardly. In C you can see exactly what's happening. No black boxes, hidden
*this pointers, overridden functions, *shudder* passing by reference with
no discernable change in how you call it, and no *also shudder* overloaded
operators.

That, and a monkey could read some manpages and figure out what any line
of C does (although he obviously would be unable to recreate that or
figure out /why/ each line does what it does. Monkeys aren't the brilliant
typists that people would like us to believe.) C++ has a plethora of new
concepts, keywords, styles, etc. Not everything is simpler in C++.

Finally, C itself is not insecure. Just because you're a bad programmer
(and a lazy typist) does not mean that you should switch to a language
where your inadequacies are hidden. It means that you should learn your
language well. Buffer overflows are easy to avoid ("Don't use gets()!"
will prevent 90% of them), as are pretty well all of the common pitfalls.

--
Andrew Poelstra <website down>
My server is down; you can't mail
me, nor can I post convieniently.
 
Reply With Quote
 
Andrew Poelstra
Guest
Posts: n/a
 
      07-26-2006
On 2006-07-26, av <(E-Mail Removed)> wrote:
> On Wed, 26 Jul 2006 12:19:13 +0100, Flash Gordon wrote:
>>av wrote:
>>> On Tue, 25 Jul 2006 08:03:14 -0400, Eric Sosman wrote:
>>>> Robbie Hatley wrote:
>>>>> [...]
>>>> "Premature optimization is the root of all evil."
>>>> -- D.E. Knuth
>>>
>>> don't know
>>>
>>>> "We follow two rules in the matter of optimization:
>>>> Rule 1: Don't do it.
>>>> Rule 2 (for experts only): Don't do it yet."
>>>> -- M.A. Jackson
>>>
>>> these rules are wrong

>>
>>What makes you think that you know better than well respected experts?

>
> i find a lot of fun searching for optimisation code (and algorithm)
> and until now not have wrong experiences
> i would translate my c files in assembly and i'm sure in the
> translated files, instructions will be between 1/10 and 1/100 than C
> files, but the cpu has enough cache for the code and i'm lazy
>


Set the compiler to its maximum optimization level, and see whether or
not you're smarter than it.

>>One is in general far more likely to achieve significant improvements be
>>selecting the correct algorithm and design. Only when those are optimal,
>>and if there is still a demonstrable problem, should one use
>>measurements to find the problem areas and optimise them.

>
> one good idea is better that all the optimal-ways walk
>


This is a typical sentence of yours: please use proper grammar and
punctuation, and try to make your sentences more coherant (if you
don't speak English natively, this will be harder than the others).
As it stands, I have no idea what you just said.

--
Andrew Poelstra <website down>
My server is down; you can't mail
me, nor can I post convieniently.
 
Reply With Quote
 
Robbie Hatley
Guest
Posts: n/a
 
      07-26-2006

Eric Sosman wrote of my string copy experiments:

> ... it seems more than a little likely that you are
> committing the sin of premature optimization.


If this was a large app for long-term use by many, being
built and maintained by a team, then perhaps that might be
true.

But it's actually a tiny hobby app which I wrote expressly
for the purpose of optimization experimentation.

> Until and unless you have MEASURED a performance problem
> not hypothecated, not supposed, not "it stands to reason-ed"
> until you have made MEASUREMENTS it is irresponsible folly to
> micro-optimize.


It's already in a batch file like so:

clock
MyProgram
clock

So I can instantly see whether making a particular change
causes execution time to go up, go down, or stay about the
same.

Hypotheses must come first. Then experimentation to determine
whether your hypotheses are brilliance or bunk. That's the
scientific method.

> "Premature optimization is the root of all evil."
> -- D.E. Knuth


No, I think religiosity (addiction to untested ideas) is the
cause of most evil (including many bad computer programs, and
also including most wars).

> "We follow two rules in the matter of optimization:
> Rule 1: Don't do it.
> Rule 2 (for experts only): Don't do it yet."
> -- M.A. Jackson


That's stupid. Fear gains nothing. Say instead:
1. If you see an opportunity to optimze, do it, as long as it
doesn't significantly damage readibility or modularity.
2. Test it.
3. If it didn't significantly improve performance, revert.

> "More computing sins are committed in the name of efficiency
> (without necessarily achieving it) than for any other single
> reason, including blind stupidity."
> -- W.A. Wulf


I think far more computing sins have been commited in the name
of impatience and the desire to "get this **** done and get out
of here so I can go home and have a beer and watch the game",
as my (fired) former boss used to say.

> In other words, I'm not the only person crying that ab initio
> micro-optimization is folly; smart people do so, too. Be smart.


False reasoning. Imitating superficial aspects of the behavior
of smart people will not make one smart.

And while it is perhaps true that most programs should not be
"optimized ab inito", some should be.

--
Cheers,
Robbie Hatley
East Tustin, CA, USA
lone wolf intj at pac bell dot net
(put "[usenet]" in subject to bypass spam filter)
home dot pac bell dot net slant earnur slant


 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      07-26-2006
Andrew Poelstra wrote:
> On 2006-07-26, av <(E-Mail Removed)> wrote:
>> On Wed, 26 Jul 2006 12:19:13 +0100, Flash Gordon wrote:
>>> av wrote:
>>>> On Tue, 25 Jul 2006 08:03:14 -0400, Eric Sosman wrote:
>>>>> Robbie Hatley wrote:
>>>>>> [...]
>>>>> "Premature optimization is the root of all evil."
>>>>> -- D.E. Knuth
>>>> don't know
>>>>
>>>>> "We follow two rules in the matter of optimization:
>>>>> Rule 1: Don't do it.
>>>>> Rule 2 (for experts only): Don't do it yet."
>>>>> -- M.A. Jackson
>>>> these rules are wrong
>>> What makes you think that you know better than well respected experts?

>> i find a lot of fun searching for optimisation code (and algorithm)
>> and until now not have wrong experiences
>> i would translate my c files in assembly and i'm sure in the
>> translated files, instructions will be between 1/10 and 1/100 than C
>> files, but the cpu has enough cache for the code and i'm lazy

>
> Set the compiler to its maximum optimization level, and see whether or
> not you're smarter than it.


And use a modern compiler. Compiler optimisation has moved on a lot in
the last 20 years.

>>> One is in general far more likely to achieve significant improvements be
>>> selecting the correct algorithm and design. Only when those are optimal,
>>> and if there is still a demonstrable problem, should one use
>>> measurements to find the problem areas and optimise them.

>> one good idea is better that all the optimal-ways walk

>
> This is a typical sentence of yours: please use proper grammar and
> punctuation, and try to make your sentences more coherant (if you
> don't speak English natively, this will be harder than the others).
> As it stands, I have no idea what you just said.


Agreed. We can cope with bad English to a degree, but av is extremely
hard to understand.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Post increment ++ has higher precedence than pre increment ++. Why? Alf P. Steinbach /Usenet C++ 0 05-22-2011 12:03 PM
why prefix increment is faster than postfix increment? jrefactors@hotmail.com C++ 99 06-11-2010 12:51 PM
post increment or pre increment? Peng Yu Perl Misc 7 11-23-2008 11:44 PM
why prefix increment is faster than postfix increment? jrefactors@hotmail.com C Programming 104 10-27-2005 11:44 PM
cannot convert parameter from 'double (double)' to 'double (__cdecl *)(double)' error Sydex C++ 12 02-17-2005 06:30 PM



Advertisments