Announcement

Collapse
No announcement yet.

DragonEgg 3.0 Puts GCC & LLVM In One Bed

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

  • DragonEgg 3.0 Puts GCC & LLVM In One Bed

    Phoronix: DragonEgg 3.0 Puts GCC & LLVM In One Bed

    LLVM 3.0 was released last week as a major update to this increasingly popular open-source compiler infrastructure. With the release of LLVM 3.0 proper also came major updates to the Clang C/C++ compiler front-end and the DragonEgg GCC plug-in. In this article is a look at DragonEgg for LLVM 3.0 that plugs into GCC to replace its optimizers and code generators with those from LLVM.

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Its pretty cool that it does offer some speedup for some code even if it doesn't for code that is already designed with optimisation in mind.

    I wonder how compling desktop applications like firefox would fair... Firefox alreayd supports -O3 ... I wonder how it would run on Dragonegg

    Comment


    • #3
      from the article:
      -"The single-threaded POV-Ray benchmark with its stock compiler flags was also much faster when taking advantage of the LLVM technologies than vanilla GCC."
      Read this post here on Phoronix: http://phoronix.com/forums/showthrea...367#post224367

      How can Micheal in light of this information still stick with the 'stock' settings for PovRay? Why is he spending ALL this time on pumping out tests when he can't even take the time to properly configure them? He must really be subscribing to the 'quantity before quality' mantra.

      I understand why the LLVM and GCC devs think Phoronix's tests are worthless, and it's damn sad because with some effort he COULD make them worthwhile.

      Comment


      • #4
        Originally posted by XorEaxEax View Post
        from the article:


        Read this post here on Phoronix: http://phoronix.com/forums/showthrea...367#post224367

        How can Micheal in light of this information still stick with the 'stock' settings for PovRay? Why is he spending ALL this time on pumping out tests when he can't even take the time to properly configure them? He must really be subscribing to the 'quantity before quality' mantra.

        I understand why the LLVM and GCC devs think Phoronix's tests are worthless, and it's damn sad because with some effort he COULD make them worthwhile.
        POVRay is using the upstream settings... So either inform upstream POVRay or you can supply a patch as well and it can be happily integrated.
        Michael Larabel
        https://www.michaellarabel.com/

        Comment


        • #5
          Originally posted by Michael View Post
          POVRay is using the upstream settings... So either inform upstream POVRay or you can supply a patch as well and it can be happily integrated.
          Is PovRay even maintained anymore? Why don't you instead change the config to actually reflect the cpu's being tested or simply scrap this test alltogether since all it shows now is that llvm does LESS tuning towards K8 which makes the performance suffer LESS when running this K8 optimized binary on different cpu architecture. It's totally pointless. Atleast place a goddamn disclaimer then, like -'hey, yes we are running this benchmark on core i7 but we are tuning the binary for K8, eeh'.

          Nonsense like this means you can't trust one single benchmark coming from Phoronix.

          Comment


          • #6
            Originally posted by XorEaxEax View Post
            Is PovRay even maintained anymore? Why don't you instead change the config to actually reflect the cpu's being tested or simply scrap this test alltogether since all it shows now is that llvm does LESS tuning towards K8 which makes the performance suffer LESS when running this K8 optimized binary on different cpu architecture. It's totally pointless. Atleast place a goddamn disclaimer then, like -'hey, yes we are running this benchmark on core i7 but we are tuning the binary for K8, eeh'.

            Nonsense like this means you can't trust one single benchmark coming from Phoronix.
            In terms of changing the config, yes, patches are welcome and happily accepted for those wishing to be helpful and do more than just complain.

            It's been said time and time again why upstream defaults are used... There's a generally safe assumption (although in the case of POVRay I am not sure what reasoning the developers have) that they know how to best tune their own code and have some reasoning to justify their defaults, the tests are meant to be reproducible so that even if you fetch the source package outside of PTS you can still try to mirror similar results, regardless of any PTS-specific changes made someone is always going to bitch about an option, etc etc
            Michael Larabel
            https://www.michaellarabel.com/

            Comment


            • #7
              Originally posted by XorEaxEax View Post
              from the article:

              How can Micheal in light of this information still stick with the 'stock' settings for PovRay? Why is he spending ALL this time on pumping out tests when he can't even take the time to properly configure them? He must really be subscribing to the 'quantity before quality' mantra.
              Michael is right. Only the default settings matter for 99.99% of us.

              Comment


              • #8
                Originally posted by zoomblab View Post
                Michael is right. Only the default settings matter for 99.99% of us.
                With one little difference. The defaults that matter are not the defaults chosen by upstream, but by the distributions. And those tend to override any random cflags with -O2 (at least Debian does, so Ubuntu will as well), unless there's a good reason to change them.

                Comment


                • #9
                  Originally posted by phoronix View Post
                  Phoronix: DragonEgg 3.0 Puts GCC & LLVM In One Bed

                  LLVM 3.0 was released last week as a major update to this increasingly popular open-source compiler infrastructure. With the release of LLVM 3.0 proper also came major updates to the Clang C/C++ compiler front-end and the DragonEgg GCC plug-in. In this article is a look at DragonEgg for LLVM 3.0 that plugs into GCC to replace its optimizers and code generators with those from LLVM.

                  http://www.phoronix.com/vr.php?view=16786
                  First, the Core i7 990X is a 6-core processor, not a 12-core processor. If you want to describe by threads, you should describe it as being 12-thread.

                  Second, please set CFLAGS and CXXFLAGS to "-march=native -O2" when you benchmark. That is the standard way to compile things. Ask any Gentoo Linux user.

                  Third, nothing stops you from doing benchmarks with different compilation flags.

                  Originally posted by AnonymousCoward View Post
                  With one little difference. The defaults that matter are not the defaults chosen by upstream, but by the distributions. And those tend to override any random cflags with -O2 (at least Debian does, so Ubuntu will as well), unless there's a good reason to change them.
                  They sometimes compile packages with -Os instead of -O2.
                  Last edited by Shining Arcanine; 05 December 2011, 10:09 AM.

                  Comment


                  • #10
                    Originally posted by Michael View Post
                    It's been said time and time again why upstream defaults are used... There's a generally safe assumption[...]
                    It's never safe to assume. Upstream does whatever they feel like, including using hacked together custom makefiles which don't repsect your CFLAGS anyway. This is the challenge of packaging for distros.
                    ...that they know how to best tune their own code and have some reasoning to justify their defaults
                    In the event that this is the case, it's still generally expected that the packager define -march/-mtune and possibly -On to be joined with whatever special secret sauce flags upstream wants (which may not be applied the same for every source file). It can't be assumed that these are set to something sane by default.

                    Comment

                    Working...
                    X