C language paradox

P

pembed2012

Hello again
I continue to read about optimization in C.

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?
 
W

Willem

pembed2012 wrote:
) Hello again
) I continue to read about optimization in C.
)
) 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
 
I

Ian Collins

Hello again
I continue to read about optimization in C.

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.
 
S

Shao Miller

Hello again
I continue to read about optimization in C.

And you continue to keep your sources private. "I have heard that
malloc also allocate additional memory to hold some header information."
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!
 
K

Kaz Kylheku

Hello again
I continue to read about optimization in C.

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
experiment is not a "paradox". A paradox is an apparent contradiction which
is actually true.
 
J

James Kuyper

Hello again
I continue to read about optimization in C.

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.
 
J

James Dow Allen

Hello again
I continue to read about optimization in C.

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
 
S

Stephen Sprunk

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
 
K

Keith Thompson

pembed2012 said:
I continue to read about optimization in C.

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
already pointed out.)
 
E

Eric Sosman

Hello again
I continue to read about optimization in C.

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.
 
J

James Kuyper

... 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".
 
N

Nick Keighley

I continue to read about optimization in C.
[...]

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

really? I thought a paradox was unresolvable contradiction

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

Something like the so-called Relativity "Twin Paradox" isn't a paradox
at all but a simple mismatch between common sense and experiment (or
theoretical predication anyway).
 
N

Nick Keighley

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!
 
J

James Kuyper

I continue to read about optimization in C.
[...]

2. A difference between what you "saw" (whatever that means,
� �probably "read on some silly web page") and what you observed in an
� �experiment is not a "paradox". �A paradox is an apparent contradiction which
� �is actually true.

really? I thought a paradox was unresolvable contradiction

"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.
Something like the so-called Relativity "Twin Paradox" isn't a paradox
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.
 
J

James Kuyper

I suppose that we need more identical twins in the astronaut program.


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
in any twin-paradox discussion.

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.
 
G

Geoff

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".
 
K

Keith Thompson

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 ..."
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,579
Members
45,053
Latest member
BrodieSola

Latest Threads

Top