C language paradox

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

  1. pembed2012

    pembed2012 Guest

    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?
     
    pembed2012, Feb 28, 2012
    #1
    1. Advertising

  2. pembed2012

    Willem Guest

    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
     
    Willem, Feb 28, 2012
    #2
    1. Advertising

  3. pembed2012

    Ian Collins Guest

    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
     
    Ian Collins, Feb 28, 2012
    #3
  4. pembed2012

    Shao Miller Guest

    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!
     
    Shao Miller, Feb 28, 2012
    #4
  5. pembed2012

    Kaz Kylheku Guest

    On 2012-02-28, pembed2012 <> 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.
     
    Kaz Kylheku, Feb 28, 2012
    #5
  6. pembed2012

    James Kuyper Guest

    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.
     
    James Kuyper, Feb 28, 2012
    #6
  7. On Feb 29, 4: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.


    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
    #7
  8. 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
    #8
  9. pembed2012 <> writes:
    > 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.)

    --
    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
    #9
  10. pembed2012

    Eric Sosman Guest

    On 2/28/2012 4:33 PM, pembed2012 wrote:
    > 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.

    --
    Eric Sosman
    d
     
    Eric Sosman, Feb 29, 2012
    #10
  11. pembed2012

    James Kuyper Guest

    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
    #11
  12. On Feb 28, 10:16 pm, Kaz Kylheku <> wrote:
    > On 2012-02-28, pembed2012 <> 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).
     
    Nick Keighley, Feb 29, 2012
    #12
  13. On Feb 28, 11:08 pm, James Dow Allen <> wrote:
    > On Feb 29, 4: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.

    >
    > 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
    #13
  14. pembed2012

    James Kuyper Guest

    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:

    >
    >>> 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
     
    James Kuyper, Feb 29, 2012
    #14
  15. pembed2012

    jgharston Guest

    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
    #15
  16. pembed2012

    James Kuyper Guest

    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
    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
     
    James Kuyper, Mar 4, 2012
    #16
  17. pembed2012

    Geoff Guest

    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
    #17
  18. pembed2012

    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
    #18
  19. pembed2012

    BartC Guest

    <> 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
    #19
  20. 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
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?VVJHRU5ULi5QbGVhc2U=?=

    Is this a PARADOX?

    =?Utf-8?B?VVJHRU5ULi5QbGVhc2U=?=, Sep 5, 2004, in forum: ASP .Net
    Replies:
    3
    Views:
    381
    Greg Burns
    Sep 5, 2004
  2. Ricardo Magalhaes

    Connecting with paradox file..

    Ricardo Magalhaes, Apr 12, 2005, in forum: ASP .Net
    Replies:
    0
    Views:
    504
    Ricardo Magalhaes
    Apr 12, 2005
  3. Ricardo Magalhaes

    Viewing Paradox Data Without Correct Accentuation

    Ricardo Magalhaes, Apr 14, 2005, in forum: ASP .Net
    Replies:
    0
    Views:
    367
    Ricardo Magalhaes
    Apr 14, 2005
  4. KiwiBrian

    Streaming paradox

    KiwiBrian, Dec 4, 2005, in forum: HTML
    Replies:
    7
    Views:
    451
  5. kabamarou

    Paradox Language driver change

    kabamarou, May 11, 2007, in forum: C++
    Replies:
    1
    Views:
    458
    Zeppe
    May 11, 2007
Loading...

Share This Page