Building With -03 Flags. - BSD

This is a discussion on Building With -03 Flags. - BSD ; On Jan 17, 3:58 pm, localhost.private.neotoma.org wrote: > What about -Os? As mentioned many times in this thread, this information is already in FreeBSD's "make.conf" manpage. FreeBSD base and kernel can use -O and -O2. - JT...

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3
Results 41 to 46 of 46

Thread: Building With -03 Flags.

  1. Re: Building With -03 Flags.

    On Jan 17, 3:58 pm, localhost.private.neotoma.org wrote:
    > What about -Os?


    As mentioned many times in this thread, this information
    is already in FreeBSD's "make.conf" manpage.

    FreeBSD base and kernel can use -O and -O2.

    - JT


  2. Re: Building With -03 Flags.

    On Jan 17, 3:58 pm, localhost.private.neotoma.org wrote:
    > What about -Os?


    On Jan 17, 4:12 pm, "JT" wrote:
    > FreeBSD base and kernel can use -O and -O2.


    I'm sorry I misread your message.
    It thought you said "-O", but you're asking about "-Os".

    Hmm... I don't recall any email messages about -Os.

    Reading gcc's documentation, it says it activates
    a subset of -O2 optimizations, plus some extra optimizations.
    It's these "extra" optimizations that I'm worried.
    So, I'm sorry I don't know if people have reported
    problems with it or not. But the official FreeBSD project
    will not help you fix bugs if it's due to -Os

    - JT


  3. Re: Building With -03 Flags.

    On 17 Jan 2007 08:15:57 -0800 in <1169050557.455994.54890@v45g2000cwv.googlegroups.c om> JT wrote:
    > On Jan 17, 3:58 pm, localhost.private.neotoma.org wrote:
    >> What about -Os?

    >
    > On Jan 17, 4:12 pm, "JT" wrote:
    >> FreeBSD base and kernel can use -O and -O2.

    >
    > I'm sorry I misread your message.
    > It thought you said "-O", but you're asking about "-Os".
    >
    > Hmm... I don't recall any email messages about -Os.
    >
    > Reading gcc's documentation, it says it activates
    > a subset of -O2 optimizations, plus some extra optimizations.
    > It's these "extra" optimizations that I'm worried.
    > So, I'm sorry I don't know if people have reported
    > problems with it or not. But the official FreeBSD project
    > will not help you fix bugs if it's due to -Os


    It should, in theory, optimize for space.
    I ask because I have seen one of the BSDs (probably OpenBSD)
    use it when building kernel and utilities for floppies.
    I've used it with OpenBSD on systems that were tight on memory.

    When excercised on the Linux kernel... it tended to find gcc bugs :-).


    --
    Chris Dukes
    < elfick> willg: you can't use dell to beat people, it wouldn't stand up
    to the strain... much like attacking a tank with a wiffle bat

  4. Re: Building With -03 Flags.

    On Wed, 17 Jan 2007 04:37:55 +0000 (UTC), Steven G. Kargl wrote:
    : After reviewing the thread, I'd say you're missing the point.

    If you're also fixating on -O3 you, as JT, are also missing my point.
    I don't *care* about -O3. I do care about the counterproductiveness
    of arrogance in that this is a volunteer project, it's good to have
    people try things and fix them if they're broken, and it's wrong to
    bite n00bs.

    Various facts about O3 are so much hand waving JT dragged out because
    for some inexplicable reason he took offense at my suggestion in my
    initial post at message id <1168975835.22087@news.queue.to> that
    Timmy14 should, yes why not?, try it out, fix it if he found it broken
    and were so inclined to do so, if he did fix it and bring patches back
    that we would appreciate it.

    I was probably wrong about the "we would appreciate it" part but the
    rest stands. Hopefully Timmy14 and everyone else unfortunate enough
    to face the sort of kneejerk snarky
    you-have-a-lot-of-nerve-wasting-our-precious-time response that he ran
    into at the top of this thread will stick around become contributors
    in spite of the snark.

  5. Re: Building With -03 Flags.

    On Jan 17, 6:52 pm, hgold...@mpcs.com (Howard Goldstein) wrote:
    > I do care about the counterproductiveness
    > of arrogance in that this is a volunteer project, it's good to have
    > people try things and fix them if they're broken, and it's wrong to
    > bite n00bs.


    I did not bite n00bs. As I said, which you deliberately snipped,
    that I was trying to spare n00bs the mountain of pain.

    You: Your advise was to go for it, it's not sacrilege,
    and that they may be able to help pinpoint the bug.

    Me: It will be a mountain of pain. n00bs will see mysterious
    failures, and think they typed something wrong.
    You've been using FreeBSD for many years (from your usenet
    posts), and you're the one who should have
    steered n00bs away from this *unwanted* help.
    (*unwanted* in the sense that FreeBSD developers
    and GCC developers don't want to work on it).

    On Jan 17, 6:52 pm, hgold...@mpcs.com (Howard Goldstein) wrote:
    > if he did fix it and bring patches back
    > that we would appreciate it.


    Ha... there's 0 chance that someone not familar
    with FreeBSD kernel source could pinpoint such a bug.

    I certainly cannot. And, even if the original poster
    is a great Linux kernel programmer, if he's not familiar
    with FreeBSD (as he stated), then there's 0 chance he could.

    The problem is compounded by the fact that a lot
    of GCC optimizations make sense in a single process,
    where there are explicit assumptions about the
    continueing of memory accesses, but in kernel,
    we need to worry about context switches that may
    change values from the registers out from under the code.
    So we are encountering corner cases that 99% GCC users
    won't see. Hence it is always very tricky to track down
    an object-alias error, or a memory barrier violation error
    resulting from over-aggressive optimizations.

    -

    My main point: if you're going to continue in this
    discussion, then please please respond to this point:
    * Timmy couldn't have helped.
    * Timmy would have suffered.
    * Your advice to him was kind and friendly.
    * I added to that advise, in a friendly way,
    that Jimmy shouldn't bother.
    * You then started getting ideological
    about why it must certainly be useful....

    - JT


  6. Re: Building With -03 Flags.

    pakrat@localhost.private.neotoma.org wrote:
    > > Reading gcc's documentation, it says it activates
    > > a subset of -O2 optimizations, plus some extra optimizations.
    > > It's these "extra" optimizations that I'm worried.
    > > So, I'm sorry I don't know if people have reported
    > > problems with it or not. But the official FreeBSD project
    > > will not help you fix bugs if it's due to -Os

    >
    > It should, in theory, optimize for space.
    > I ask because I have seen one of the BSDs (probably OpenBSD)
    > use it when building kernel and utilities for floppies.
    > I've used it with OpenBSD on systems that were tight on memory.
    >
    > When excercised on the Linux kernel... it tended to find gcc bugs :-).
    >
    >


    To give an example, this is just a numerical computation, a small
    Monte Carlo. This is what one gets at different optimizations:

    niobe% cc -Os -L/usr/local/lib -lf2c -o test test.c
    niobe% ls -l test
    -rwxr-xr-x 1 michel lpthe 10609 17 jan 23:37 test*
    niobe% time ./test
    ../test 6,59s user 0,00s system 99% cpu 6,589 total

    niobe% cc -O -L/usr/local/lib -lf2c -o test test.c
    niobe% time ./test
    ../test 6,31s user 0,00s system 99% cpu 6,310 total

    niobe% cc -O3 -L/usr/local/lib -lf2c -o test test.c
    niobe% time ./test
    ../test 6,47s user 0,00s system 99% cpu 6,476 total
    niobe% ls -l test
    -rwxr-xr-x 1 michel lpthe 12785 17 jan 23:41 test*

    Do you really beleive it is necessary to paint this bikeshed just
    for such a small difference? (either in execution time or in binary
    size).

    And now the Intel compiler, keep your eyes open!

    niobe% icc -O3 -L/usr/local/lib -lf2c -o test test.c
    niobe% time ./test
    ../test 2,74s user 0,00s system 99% cpu 2,738 total
    niobe% ls -l test
    -rwxr-xr-x 1 michel lpthe 185706 17 jan 23:42 test*

    I don't pretend i see such fantastic results in all cases. I have cases
    where Intel and gcc give almost same time. The difference is
    particularly big here because the computation fits in the cache, there
    are no memory accesses which slow down everyhing, and this is a P4 with
    a deep pipeline which benefits of the fine loop unrolling that the Intel
    compiler does. By the way if i begin playing with non standard options
    of gcc, then it appears less ridiculous:

    niobe% cc -O3 -funroll-all-loops -L/usr/local/lib -lf2c -o test test.c
    niobe% time ./test
    ../test 3,66s user 0,00s system 99% cpu 3,662 total
    niobe% ls -l test
    -rwxr-xr-x 1 michel lpthe 16945 17 jan 23:49 test*


    But what i almost ever see is that the different optimization levels -On
    of gcc make very little difference. Nothing which justifies taking risks.
    You can get good results with gcc only after *much* experimentation with
    various flags, and completely depending on the particular program. Do
    you understand now the wise advices of Steve Karl who asked to read
    info gcc from beginning to end and from end to beginning before even
    thinking of using -O3?


    --

    Michel TALON


+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3