Announcement

Collapse
No announcement yet.

Benchmarks Of GCC 4.5.0 Compiler Performance

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    Here's what I would like to know: what exactly was compiled?
    All of the regressions seem to be in the area of graphics, implying that the graphics libraries were not recompiled as well. If that is the case, the test data isn't really all that valid and should be redone. Also with the new flags.

    Comment


    • #42
      run multiple times report statistically valid results

      Michael:

      I think the Phoronix Test Suite is a great idea. Application level benchmarking is sadly neglected by systems engineers, and in my humble opinion it is really valuable.

      But, are the PTS results that you are reporting the results of a single run? If so, then there's no way to tell if the results are one-time flukes or are a reproducible pattern.

      In not, could you please add to your reports information showing how often each test was run and what the distribution of results were? (You could just report quartiles, or min-max-mean-median-stdev, or just report all the results, or whatever.)

      If that is too much information to fit into the article itself then you could put it on a separate page and hyperlink it from the main article.

      Ideally of course the graphs themselves should show min-max-median or otherwise indicate the distribution of the results.

      This would shake out random flukes and help make the PTS results more compelling to engineers.

      Thanks for listening!

      Regards,

      Zooko

      Comment


      • #43
        It's a shame that the compiling options used aren't mentionned in the article.

        Originally posted by D?niel Fraga View Post
        The benchmarks should use options like -O3 -march=native -fexcess-precision=fast -ftree-parallelize-loops=[n] -floop-parallelize-all -floop-interchange -floop-strip-mine -floop-block
        I think it's better to stick with safe flags, so -O2. From what I read a while ago, -floop-[interchange|strip-mine|block] are safe, -ftree-parallelize-loops not so much and -floop-parallelize-all not at all, although I may remember it wrong.

        I'll also echo the plea for some -flto action, perhaps even coupled with -fwhole-program -combine.

        Comment


        • #44
          Originally posted by that guy View Post
          I think it's better to stick with safe flags, so -O2. From what I read a while ago, -floop-[interchange|strip-mine|block] are safe, -ftree-parallelize-loops not so much and -floop-parallelize-all not at all, although I may remember it wrong.

          I'll also echo the plea for some -flto action, perhaps even coupled with -fwhole-program -combine.
          I agree with you. I am not using -ftree-parallelize-loops anymore. It's a big headache in some cases.

          I tried -flto (compilation and linker stages) without success but I didn't insist too much on it. I will try later.

          Comment


          • #45
            GCC 4.5 broke it's inlining algorithm

            As of GCC 4.5 all custom kernels I've compiled resulted in kernel panics. Disabling CONFIG_OPTIMIZE_INLINING solved the problem.

            Comment

            Working...
            X