If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

DragonEgg 3.0 Puts GCC & LLVM In One Bed

12-05-2011, 05:10 AM

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.

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.

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.

Comment

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

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

Comment

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

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

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.

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

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.