GCC vs. LLVM-GCC Benchmarks

[ioannis]

Not to rush the cook in the kitchen but how is the testing of CLang coming along. I fully realize it is a compiler fresh from the oven but the question is does it lead to tasty code or do the bits end up in the dogs dish?

As a new flavor for our bit baking endeavors I want to know if CLang is ready to spice up our code. Apple seems to think it is close to being ready for a topping of ice cream and to call it the best desert ever. I'm a bit reluctant and would like to see the test test results of others, before serving up CLang with my special sauces.


Dave

damn it! now I'm hungry...

[wizard69]

I'm wondering when we are going to see the CLang tests?

Not to rush the cook in the kitchen but how is the testing of CLang coming along. I fully realize it is a compiler fresh from the oven but the question is does it lead to tasty code or do the bits end up in the dogs dish?

As a new flavor for our bit baking endeavors I want to know if CLang is ready to spice up our code. Apple seems to think it is close to being ready for a topping of ice cream and to call it the best desert ever. I'm a bit reluctant and would like to see the test test results of others, before serving up CLang with my special sauces.


Dave

[wizard69]

No it is a new approach top to bottom.

Shouldn't make any difference, Clang is just the frontend, right?

This has likely been answered already but it has the potential to make a huge difference. I say potential because CLang is no where near what most people would call mature. In any event authoritative answers can be had on the LLVMM and CLang web sites.

Dave

[deanjo]

Yes you can have a tiny code size and then allocate a dynamically allocate lots of memory. You can also use a terrible amount of CPU but you will often find smaller code does equal fewer resources.

You would be surprised. There was a SLE bug filed a ways back by an ISV that reports VM intensive microbenchmark slows down by about 45%, and real world (for them) performance drop by 10-20% by using -Os rather than -O2 in SLES11 kernel.

This was verified by another ISV as well.

[lwatcdr]

Not always

code size!=less resources

Yes you can have a tiny code size and then allocate a dynamically allocate lots of memory. You can also use a terrible amount of CPU but you will often find smaller code does equal fewer resources.

[deanjo]

I would love to see LLVM, GCC, and the Intel compiler go head to head. It is an interesting discussion as to what optimization is more important to an end users.
My opinion is that for many applications code size is more important than code speed. If the program is faster than the user then the code size will come into play. Quicker to load, uses less ram and so on. For other applications it is code speed.
That is one of the reasons I am not all that fond of 100% 64bit environments. ls does not need to use 64 bit pointers!

code size!=less resources

[lwatcdr]

Full comparison.

I would love to see LLVM, GCC, and the Intel compiler go head to head. It is an interesting discussion as to what optimization is more important to an end users.
My opinion is that for many applications code size is more important than code speed. If the program is faster than the user then the code size will come into play. Quicker to load, uses less ram and so on. For other applications it is code speed.
That is one of the reasons I am not all that fond of 100% 64bit environments. ls does not need to use 64 bit pointers!

[nanonyme]

GCC is not just a C-compiler...

This also has no relevance to anything whatsoever. I didn't say anyone would be giving up GCC. Mostly whether they'll set CC="clang" or whatever the binary is.

[yesterday]

Errr, what on Earth does that have to do with anything? That's just like complaining Sun's Java compiler doesn't compile C. :P

GCC is not just a C-compiler...

[RealNC]

Nope, Gentoo users aren't interested in giving up runtime performance for build speed. Who wants software that runs slower? Only developers might find it useful.