Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #18041 > unrolled thread

C language paradox

Back to article view | Back to comp.lang.c

Contents

  C language paradox pembed2012 <once@was.enough.invalid> - 2012-02-28 21:33 +0000
    Re: C language paradox Willem <willem@toad.stack.nl> - 2012-02-28 21:41 +0000
    Re: C language paradox Ian Collins <ian-news@hotmail.com> - 2012-02-29 10:44 +1300
    Re: C language paradox Shao Miller <sha0.miller@gmail.com> - 2012-02-28 16:51 -0500
    Re: C language paradox Kaz Kylheku <kaz@kylheku.com> - 2012-02-28 22:16 +0000
      Re: C language paradox Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-29 01:34 -0800
        Re: C language paradox James Kuyper <jameskuyper@verizon.net> - 2012-02-29 07:18 -0500
          Re: C language paradox "Scott Fluhrer" <sfluhrer@ix.netcom.com> - 2012-02-29 13:39 -0500
            Re: C language paradox Kenneth Brody <kenbrody@spamcop.net> - 2012-03-03 16:23 -0500
              Re: C language paradox James Kuyper <jameskuyper@verizon.net> - 2012-03-03 19:47 -0500
                Re: C language paradox Geoff <geoff@invalid.invalid> - 2012-03-03 18:05 -0800
                  Re: C language paradox Kenneth Brody <kenbrody@spamcop.net> - 2012-03-05 15:41 -0500
                    Re: C language paradox Robert Miles <milesrf@Usenet-News.net> - 2012-04-14 00:26 -0500
    Re: C language paradox James Kuyper <jameskuyper@verizon.net> - 2012-02-28 17:38 -0500
      Re: C language paradox Stephen Sprunk <stephen@sprunk.org> - 2012-02-28 18:52 -0600
        Re: C language paradox James Kuyper <jameskuyper@verizon.net> - 2012-02-28 22:14 -0500
    Re: C language paradox James Dow Allen <jdallen2000@yahoo.com> - 2012-02-28 15:08 -0800
      Re: C language paradox "io_x" <a@b.c.invalid> - 2012-02-29 03:42 +0100
      Re: C language paradox Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-29 01:37 -0800
        Re: C language paradox jgharston <jgh@arcade.demon.co.uk> - 2012-03-03 16:17 -0800
          Re: C language paradox nick_keighley_nospam@hotmail.com - 2012-03-04 02:54 -0800
            Re: C language paradox "BartC" <bc@freeuk.com> - 2012-03-04 11:43 +0000
            Re: C language paradox Keith Thompson <kst-u@mib.org> - 2012-03-04 04:01 -0800
              Re: C language paradox Nomen Nescio <nobody@dizum.com> - 2012-03-04 14:34 +0100
          Re: C language paradox Kaz Kylheku <kaz@kylheku.com> - 2012-03-04 17:01 +0000
            Re: C language paradox Kenneth Brody <kenbrody@spamcop.net> - 2012-03-05 15:45 -0500
    Re: C language paradox Keith Thompson <kst-u@mib.org> - 2012-02-28 17:45 -0800
      Re: C language paradox army1987 <army1987@ask-for-it.invalid> - 2012-03-05 10:42 +0000
        Re: C language paradox army1987 <army1987@ask-for-it.invalid> - 2012-03-05 10:48 +0000
          Re: C language paradox Keith Thompson <kst-u@mib.org> - 2012-03-05 09:35 -0800
            Re: C language paradox 88888 Dihedral <dihedral88888@googlemail.com> - 2012-04-16 13:01 -0700
        Re: C language paradox China Blue Water Navy <chine.bleu@yahoo.com> - 2012-03-05 04:24 -0800
        Re: C language paradox Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-03-05 07:49 -0500
    Re: C language paradox "io_x" <a@b.c.invalid> - 2012-02-29 03:42 +0100
    Re: C language paradox Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-28 21:46 -0500

Page 1 of 2  [1] 2  Next page →

#18041 — C language paradox

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?

[toc] | [next] | [standalone]

#18042

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

[toc] | [prev] | [next] | [standalone]

#18043

On 02/29/12 10:33 AM, 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");

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

[toc] | [prev] | [next] | [standalone]

#18044

On 2/28/2012 16:33, pembed2012 wrote:
> 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!

[toc] | [prev] | [next] | [standalone]

#18045

On 2012-02-28, pembed2012 <once@was.enough.invalid> wrote:
> 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.

[toc] | [prev] | [next] | [standalone]

#18062

On Feb 28, 10:16 pm, Kaz Kylheku <k...@kylheku.com> wrote:
> On 2012-02-28, pembed2012 <o...@was.enough.invalid> wrote:

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

[toc] | [prev] | [next] | [standalone]

#18066

On 02/29/2012 04:34 AM, Nick Keighley wrote:
> On Feb 28, 10:16�pm, Kaz Kylheku <k...@kylheku.com> wrote:
>> On 2012-02-28, pembed2012 <o...@was.enough.invalid> wrote:
> 
>>> 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.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#18071

"James Kuyper" <jameskuyper@verizon.net> wrote in message 
news:jil51r$m86$1@dont-email.me...
>
> 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.

Actually, it has been tested with atomic clocks and airplanes; see 
http://en.wikipedia.org/wiki/Hafele%E2%80%93Keating_experiment for a general 
overview.

[From the 'Nits R Us' department; now, back to your regularly scheduled 
discussion of C]

-- 
poncho

[toc] | [prev] | [next] | [standalone]

#18164

On 2/29/2012 1:39 PM, Scott Fluhrer wrote:
> "James Kuyper"<jameskuyper@verizon.net>  wrote in message
> news:jil51r$m86$1@dont-email.me...
>>
>> 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".  :-)

> Actually, it has been tested with atomic clocks and airplanes; see
> http://en.wikipedia.org/wiki/Hafele%E2%80%93Keating_experiment for a general
> overview.

I took a quick look at the mentioned article, but consider the entire GPS 
system, which needs to take this into account, lest the GPS be off by 10km 
per day.

   http://www.astronomy.ohio-state.edu/~pogge/Ast162/Unit5/gps.html

> [From the 'Nits R Us' department; now, back to your regularly scheduled
> discussion of C]

:-)


-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#18179

On 03/03/2012 04:23 PM, Kenneth Brody wrote:
> On 2/29/2012 1:39 PM, Scott Fluhrer wrote:
>> "James Kuyper"<jameskuyper@verizon.net>  wrote in message
>> news:jil51r$m86$1@dont-email.me...
>>>
>>> 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
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.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#18182

On Sat, 03 Mar 2012 19:47:29 -0500, James Kuyper
<jameskuyper@verizon.net> 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".

[toc] | [prev] | [next] | [standalone]

#18243

On 3/3/2012 9:05 PM, Geoff wrote:
[... time / relativity ...]
> 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".

Does "for(;;);" complete sooner on the system in orbit, or on the Earth's 
surface?  :-)

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#19645

On 3/5/2012 2:41 PM, Kenneth Brody wrote:
> On 3/3/2012 9:05 PM, Geoff wrote:
> [... time / relativity ...]
>> 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".
>
> Does "for(;;);" complete sooner on the system in orbit, or on the
> Earth's surface? :-)

Depends heavily on the speed of systems you can put in orbit
versus the speed of systems you can use on the Earth's surface.

Robert Miles

[toc] | [prev] | [next] | [standalone]

#18047

On 02/28/2012 04:33 PM, 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?

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.

[toc] | [prev] | [next] | [standalone]

#18050

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

[toc] | [prev] | [next] | [standalone]

#18055

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

[toc] | [prev] | [next] | [standalone]

#18049

On Feb 29, 4:33 am, pembed2012 <o...@was.enough.invalid> 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.

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

[toc] | [prev] | [next] | [standalone]

#18053

"James Dow Allen" <jdallen2000@yahoo.com> ha scritto nel messaggio
news:bf5194de-3755-4fe3-845c-71e4197b4eb6@y10g2000vbn.googlegroups.com...
On Feb 29, 4:33 am, pembed2012 <o...@was.enough.invalid> 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.

>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

i agree, if someone call one function that function has to be
called

[toc] | [prev] | [next] | [standalone]

#18063

On Feb 28, 11:08 pm, James Dow Allen <jdallen2...@yahoo.com> wrote:
> On Feb 29, 4:33 am, pembed2012 <o...@was.enough.invalid> 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.
>
> 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!

[toc] | [prev] | [next] | [standalone]

#18178

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

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

JGH

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web