DragonEgg 3.0 Puts GCC & LLVM In One Bed

[phoronix]

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

[cb88]

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

[XorEaxEax]

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.

[Michael]

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.

[XorEaxEax]

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.

[Michael]

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

[zoomblab]

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.

[AnonymousCoward]

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.

[Shining Arcanine]

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.

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.

[Smorg]

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.