Discussion in 'C Programming' started by pembed2012, Feb 28, 2012.

1. ### pembed2012Guest

Hello again

I saw that we shall always uses puts instead of printf for a constant
string. However I made the following experiments:

routine: for(i = 0;i < 100; i++) printf("\n");

time: 0.38 seconds

routine: for(i = 0;i < 100: i++) puts("\n");

time: 0.77 seconds

Conclusion: printf is more efficient than puts.

Can anyone explain me this paradox?

pembed2012, Feb 28, 2012

2. ### WillemGuest

pembed2012 wrote:
) Hello again
)
) I saw that we shall always uses puts instead of printf for a constant
) string. However I made the following experiments:
)
) routine: for(i = 0;i < 100; i++) printf("\n");
)
) time: 0.38 seconds
)
) routine: for(i = 0;i < 100: i++) puts("\n");
)
) time: 0.77 seconds
)
) Conclusion: printf is more efficient than puts.
)
) Can anyone explain me this paradox?

Have you compared the output of the two programs to see if it is the same?

SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

Willem, Feb 28, 2012

3. ### Ian CollinsGuest

On 02/29/12 10:33 AM, pembed2012 wrote:
> Hello again
>
> I saw that we shall always uses puts instead of printf for a constant
> string. However I made the following experiments:
>
> routine: for(i = 0;i< 100; i++) printf("\n");

This outputs one newline. It will probably be optimised to a putchar().

> time: 0.38 seconds
>
> routine: for(i = 0;i< 100: i++) puts("\n");

This outputs two newlines.

>
> Conclusion: printf is more efficient than puts.

Conclusion: outputting two characters takes longer than outputting one.

--
Ian Collins

Ian Collins, Feb 28, 2012
4. ### Shao MillerGuest

On 2/28/2012 16:33, pembed2012 wrote:
> Hello again

And you continue to keep your sources private. "I have heard that

>
> I saw that we shall always uses puts instead of printf for a constant
> string.

Where did you see that?

> However I made the following experiments:
>
> routine: for(i = 0;i< 100; i++) printf("\n");
>
> time: 0.38 seconds
>
> routine: for(i = 0;i< 100: i++) puts("\n");
>
> time: 0.77 seconds
>
> Conclusion: printf is more efficient than puts.
>

If you believe that you can generalize and conclude that this test's
result applies across all C implementations everywhere, I don't think
that's a good belief.

> Can anyone explain me this paradox?

What paradox? I heard that you were just trying to make the regulars on
comp.lang.c do a dance, as seems to be fairly common. But I doubt you
will respond to this post. Can you explain that paradox to me?

How about betting your friend \$5.00 that you can get 10 people to tell
you that the 'puts' above outputs two characters and the 'printf' just
one. You win!

Shao Miller, Feb 28, 2012
5. ### Kaz KylhekuGuest

On 2012-02-28, pembed2012 <> wrote:
> Hello again
>
> I saw that we ...

[...]
> Conclusion ...

[...]
> Can anyone explain me this paradox?

1. Whatever you read is false, and your conclusion from one experiment is also
a false generalization.

2. A difference between what you "saw" (whatever that means,
probably "read on some silly web page") and what you observed in an
is actually true.

Kaz Kylheku, Feb 28, 2012
6. ### James KuyperGuest

On 02/28/2012 04:33 PM, pembed2012 wrote:
> Hello again
>
> I saw that we shall always uses puts instead of printf for a constant
> string. However I made the following experiments:
>
> routine: for(i = 0;i < 100; i++) printf("\n");
>
> time: 0.38 seconds
>
> routine: for(i = 0;i < 100: i++) puts("\n");
>
> time: 0.77 seconds
>
> Conclusion: printf is more efficient than puts.
>
> Can anyone explain me this paradox?

Well, it would be better to compare things which produce the same
output. If you're trying to produce 100 lines, replace the puts() call
with puts("") (or better yet, putchar('\n')). If you're trying to
produce 200 lines, change the printf() call to printf("\n\n").

In principle, printf() has to do a lot more work than puts(), even if
only to figure out that the format string it's been given doesn't
require it to do anything special. However, for a short simple format
string like this one, the difference should be quite minor compared to
the time spent writing the data to the output stream. You're more likely
to see a significant difference favoring puts() with a significantly
longer format string.

Also, keep in mind that a sufficiently clever implementation of C might
translate either of your loops by creating an array with 100 (or 200
characters, all but the last set to '\n', and the last one set '\0'. It
could then replace either of your loops with a single call to puts()
using that array. If you want to prevent such optimizations, C is not
the language for you.

James Kuyper, Feb 28, 2012
7. ### James Dow AllenGuest

On Feb 29, 4:33 am, pembed2012 <> wrote:
> Hello again
>
> I saw that we shall always uses puts instead of printf for a constant
> string.

I find such substitution for 'printf' INTENSELY annoying.
It's not at all unusual that I search for every instance
of printf in a file. To miss some where the "clever"
programmer had "optimized" to puts() or putc() would
infuriate me, perhaps even enough for
rm -rf idiots_source

BTW, if you're in the "optimization is fun even where
unneeded" camp, I'm one of the few in this ng who's on your side.
Writing The_Worlds_Fastest_Jpeg(tm) was great fun for me,
and involved some "clever" tricks worth much less than 1%
speedup each. But these were optimizations intended to
.... er ... optimize!, not inane trivia like bypassing
printf.

James

James Dow Allen, Feb 28, 2012
8. ### Stephen SprunkGuest

On 28-Feb-12 16:38, James Kuyper wrote:
> In principle, printf() has to do a lot more work than puts(), even if
> only to figure out that the format string it's been given doesn't
> require it to do anything special.

.... unless the compiler is smart enough to recognize that case and
substitute a call to puts() instead. GCC, for instance, has been doing
that for ages.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking

Stephen Sprunk, Feb 29, 2012
9. ### Keith ThompsonGuest

pembed2012 <> writes:
>
> I saw that we shall always uses puts instead of printf for a constant
> string. However I made the following experiments:
>
> routine: for(i = 0;i < 100; i++) printf("\n");
>
> time: 0.38 seconds
>
> routine: for(i = 0;i < 100: i++) puts("\n");
>
> time: 0.77 seconds
>
> Conclusion: printf is more efficient than puts.
>
> Can anyone explain me this paradox?

Get a faster computer. It shouldn't take that long to write 100 or
200 empty lines. (Unless you have a test harness that you haven't
shown us.)

I usually use puts() for constant strings, but only because it's
simpler than printf(); I don't have to worry about '%' characters in
the argument being interpreted, and it provides a newline character
(assuming I want one).

On the other hand, for a beginner using printf consistently is
probably simpler, since there's only one function to remember (which
may be why the classic "hello, world" uses printf rather than puts).

If the performance difference between equivalent puts and printf
calls is a significant concern for you, either you're doing
something strange or you're overly concerned about things that
really don't matter much. "Something strange" might include using
an old and/or tiny system where the code size for printf and its
internal interpreter is a significant burden.

(Oh, and the two snippets aren't equivalent, as everyone else has

--
Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson, Feb 29, 2012
10. ### Eric SosmanGuest

On 2/28/2012 4:33 PM, pembed2012 wrote:
> Hello again

Bad idea. If you're the same person who just two weeks ago (under
a different name but from the same address) posted a beginner's question
about `for' loops, you are doing yourself a disservice by wasting time
on irrelevancies. A graduate of Le Cordon Bleu may legitimately ponder
whether to add a dash of nutmeg to a recipe calling for mace, but the
same is not appropriate in someone who is still learning to separate
eggs.

Jackson's Laws of Program Optimization are

First Law: Don't do it.

Second Law (for experts only): Don't do it yet.

> I saw that we shall always uses puts instead of printf for a constant
> string. However I made the following experiments:
>
> routine: for(i = 0;i< 100; i++) printf("\n");
>
> time: 0.38 seconds
>
> routine: for(i = 0;i< 100: i++) puts("\n");
>
> time: 0.77 seconds
>
> Conclusion: printf is more efficient than puts.

Conclusion: At your current state of development, the Second Law
does not apply.

--
Eric Sosman
d

Eric Sosman, Feb 29, 2012
11. ### James KuyperGuest

On 02/28/2012 07:52 PM, Stephen Sprunk wrote:
> On 28-Feb-12 16:38, James Kuyper wrote:
>> In principle, printf() has to do a lot more work than puts(), even if
>> only to figure out that the format string it's been given doesn't
>> require it to do anything special.

>
> ... unless the compiler is smart enough to recognize that case and
> substitute a call to puts() instead. GCC, for instance, has been doing
> that for ages.

That is (one of the reasons) why I said "in principle".
--
James Kuyper

James Kuyper, Feb 29, 2012
12. ### Nick KeighleyGuest

On Feb 28, 10:16 pm, Kaz Kylheku <> wrote:
> On 2012-02-28, pembed2012 <> wrote:

[...]

> 2. A difference between what you "saw" (whatever that means,
>    probably "read on some silly web page") and what you observed in an
>    is actually true.

"All Cretans are liars" or better "this statement is false"

at all but a simple mismatch between common sense and experiment (or
theoretical predication anyway).

Nick Keighley, Feb 29, 2012
13. ### Nick KeighleyGuest

On Feb 28, 11:08 pm, James Dow Allen <> wrote:
> On Feb 29, 4:33 am, pembed2012 <> wrote:
>
> > Hello again

>
> > I saw that we shall always uses puts instead of printf for a constant
> > string.

>
> I find such substitution for 'printf' INTENSELY annoying.
> It's not at all unusual that I search for every instance
> of printf in a file.  To miss some where the "clever"
> programmer had "optimized" to puts() or putc() would
> infuriate me, perhaps even enough for
>    rm -rf idiots_source
>
> BTW, if you're in the "optimization is fun even where
> unneeded" camp, I'm one of the few in this ng who's on your side.
> Writing The_Worlds_Fastest_Jpeg(tm) was great fun for me,
> and involved some "clever" tricks worth much less than 1%
> speedup each.  But these were optimizations intended to
> ... er ... optimize!, not inane trivia like bypassing
> printf.

me and a collegue drove our boss nuts by spending a morning trying to
write the fastest MultiplyByTen() function in assembler (no multiply
instruction available).
I think mine was shorter by a byte but he saved a cycle!

Nick Keighley, Feb 29, 2012
14. ### James KuyperGuest

On 02/29/2012 04:34 AM, Nick Keighley wrote:
> On Feb 28, 10:16ï¿½pm, Kaz Kylheku <> wrote:
>> On 2012-02-28, pembed2012 <> wrote:

>

>
> [...]
>
>> 2. A difference between what you "saw" (whatever that means,
>> ï¿½ ï¿½probably "read on some silly web page") and what you observed in an
>> ï¿½ ï¿½is actually true.

>
>
> "All Cretans are liars" or better "this statement is false"

Strictly speaking, you're correct; but it's common usage to use the term
to refer to seemingly contradictory combinations of statements where
there isn't really a contradiction, due to the use of incorrect
premises, defective logic, or word play.

> at all but a simple mismatch between common sense and experiment (or
> theoretical predication anyway).

Re: "anyway": strictly speaking, no pair of human twins have had
sufficiently large differences in their travelling speeds to produce a
detectable effect. However, for pairs of identical sub-atomic particles,
the experiment has been conducted and did produce results matching the
theory, rather than "common sense". Particles which naturally decay into
smaller particles take much longer to do so when accelerated to
relativistic velocities. It's difficult to accelerate anything much
larger than an entire molecule to high enough speeds to make the effect
measurable.
--
James Kuyper

James Kuyper, Feb 29, 2012
15. ### jgharstonGuest

Nick Keighley wrote:
> me and a collegue drove our boss nuts by spending a morning trying to

"Me ... drove (my) boss nuts" ?

JGH

jgharston, Mar 4, 2012
16. ### James KuyperGuest

On 03/03/2012 04:23 PM, Kenneth Brody wrote:
> On 2/29/2012 1:39 PM, Scott Fluhrer wrote:
>> "James Kuyper"<> wrote in message
>> news:jil51r\$m86\$...
>>>
>>> Re: "anyway": strictly speaking, no pair of human twins have had
>>> sufficiently large differences in their travelling speeds to produce a
>>> detectable effect.

>
> I suppose that we need more identical twins in the astronaut program.
>
>>> However, for pairs of identical sub-atomic particles,
>>> the experiment has been conducted and did produce results matching the
>>> theory, rather than "common sense". Particles which naturally decay into
>>> smaller particles take much longer to do so when accelerated to
>>> relativistic velocities. It's difficult to accelerate anything much
>>> larger than an entire molecule to high enough speeds to make the effect
>>> measurable.

>
> What about GPS satellites? I think they are bit bit "larger than an entire
> molecule".

I guess I have to explain in a little more detail. I'm keeping in mind a
misinterpretation of special relativity that I've run into several
times, in various forms. It does not deny that clocks run at different
rates in frames of reference that are accelerated relative to each
other, but claims that this is somehow distinct from the actual passage
of time, which continues at the same rate regardless of how fast the
clocks tick. This implies, in particular, that people will actually be
able to perceive that they are in an rapidly moving frame of reference,
by observing physical processes (other than their own aging, which is
"somehow" not a physical process). Implicit in this concept is the
existence of a preferred frame of reference in which the clocks click at
the fastest possible rate - the "rest frame" of the entire universe, so
to speak.

The net result is that, according to this interpretation, the twin who
was accelerated to high velocity relative to Earth, accelerated again to
reverse his velocity relative to Earth, and accelerated again to match
his velocity with Earth's at the same time that he returns to Earth,
will indeed see his clocks measuring out a smaller amount of time than
the twin who stayed on Earth. However, both twins will have aged by
precisely the same amount.

Feel free to point out the logical inconsistencies of this point of
view; there are too many to easily count. It is, however, the point of
view that I tend to think of as the opposition who needs to be convinced

No matter how many successful measurements you make of time-dilation
using high precision clocks, they won't refute this interpretation. It's
"just" a change in the clock speed, not an actual change in the rate of
passage of time. What's needed is a biological system actually aging at
a noticeably slower rate, and systems that are actually subject to aging
tend to be vary large - there's no such thing as "old age" for a
bacterium. It would be very difficult to accelerate such organisms up to
velocities high enough to show significant differences in the actual
rate of aging.

However, I feel that there's a certain symbolic similarity between the
spontaneous decay of unstable particles (such as neutrons), and the
death of a human being. That this decay occurs less rapidly for rapidly
moving particles that for slower moving ones seems, to me, to more
directly attack the misinterpretation that I've described, than the fact
that rapidly moving clocks tick more slowly. I suppose that I'm probably
being optimistic about the openness of those people to accepting
relevant evidence.
--
James Kuyper

James Kuyper, Mar 4, 2012
17. ### GeoffGuest

On Sat, 03 Mar 2012 19:47:29 -0500, James Kuyper
<> wrote:

>I guess I have to explain in a little more detail. I'm keeping in mind a
>misinterpretation of special relativity that I've run into several
>times, in various forms. It does not deny that clocks run at different
>rates in frames of reference that are accelerated relative to each
>other, but claims that this is somehow distinct from the actual passage
>of time, which continues at the same rate regardless of how fast the
>clocks tick. This implies, in particular, that people will actually be
>able to perceive that they are in an rapidly moving frame of reference,
>by observing physical processes (other than their own aging, which is
>"somehow" not a physical process). Implicit in this concept is the
>existence of a preferred frame of reference in which the clocks click at
>the fastest possible rate - the "rest frame" of the entire universe, so
>to speak.

This is a common mistake when considering general relativity. It stems
from the concept of the "special" frame of reference. The twin paradox
is only a paradox when one doesn't take the effects of special
relativity into account. In all cases, the twin who ages less is
always the one who underwent the acceleration relative to the other
twin. The one who maintained his path along the geodesic of space-time
would age faster.

But when considering clocks in orbit vs. clocks on earth one has to
account for the "acceleration" of the clocks on the surface of the
earth due to gravity and the lesser acceleration of an object in orbit
where the gravity field is weaker as well as the relative velocity of
the clock on orbit.

But this analogy is completely inapplicable to a "C language paradox".

Geoff, Mar 4, 2012
18. ### Guest

On Sunday, March 4, 2012 12:17:47 AM UTC, jgharston wrote:
> Nick Keighley wrote:
> > me and a collegue drove our boss nuts by spending a morning trying to

>
> "Me ... drove (my) boss nuts" ?
>
> JGH

is this a grammar flame? The boss was the boss of both me and of the collegue. How would you phrase it?

, Mar 4, 2012
19. ### BartCGuest

<> wrote in message
news:9531290.1305.1330858499123.JavaMail.geo-discussion-forums@vbbfy7...
> On Sunday, March 4, 2012 12:17:47 AM UTC, jgharston wrote:
>> Nick Keighley wrote:
>> > me and a collegue drove our boss nuts by spending a morning trying to

>>
>> "Me ... drove (my) boss nuts" ?
>>
>> JGH

>
> is this a grammar flame? The boss was the boss of both me and of the
> collegue. How would you phrase it?

"A colleague and I ..."?

BartC, Mar 4, 2012
20. ### Keith ThompsonGuest

writes:
> On Sunday, March 4, 2012 12:17:47 AM UTC, jgharston wrote:
>> Nick Keighley wrote:
>> > me and a collegue drove our boss nuts by spending a morning trying to

>>
>> "Me ... drove (my) boss nuts" ?
>>
>> JGH

>
> is this a grammar flame? The boss was the boss of both me and of the
> collegue. How would you phrase it?

"A colleague and I drove our boss nuts by ..."

--
Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson, Mar 4, 2012