Page 1 of 2 12 LastLast
Results 1 to 10 of 12

Thread: DragonEgg 3.0 Puts GCC & LLVM In One Bed

  1. #1
    Join Date
    Jan 2007
    Posts
    14,529

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

    http://www.phoronix.com/vr.php?view=16786

  2. #2
    Join Date
    Jan 2009
    Posts
    291

    Default

    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

  3. #3
    Join Date
    Oct 2009
    Posts
    845

    Default

    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.

  4. #4

    Default

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

  5. #5
    Join Date
    Oct 2009
    Posts
    845

    Default

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

  6. #6

    Default

    Quote 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

  7. #7
    Join Date
    Nov 2008
    Posts
    147

    Default

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

  8. #8

    Default

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

  9. #9

    Default

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

    Quote 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; 12-05-2011 at 09:09 AM.

  10. #10
    Join Date
    Mar 2009
    Posts
    141

    Default

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •