Linked by ebasconp on Fri 10th Jun 2011 22:22 UTC
Benchmarks "Google has released a research paper that suggests C++ is the best-performing programming language in the market. The internet giant implemented a compact algorithm in four languages - C++, Java, Scala and its own programming language Go - and then benchmarked results to find 'factors of difference'."
Thread beginning with comment 477016
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: GCC isn't all that great
by _xmv on Sun 12th Jun 2011 11:57 UTC in reply to "RE: GCC isn't all that great"
_xmv
Member since:
2008-12-09

this is hardly the norm amongst programmers. Hence very few programmers out there can actually beat the optimized output of compilers.

i think you're confusing "programers" and "i fired up a shell and a compiler and i think i can program stuff"

Seriously, in fact.

Sure few will code in asm for the hell of it (except MenuetOS people ;-), but any who's actually a real programmer will insert asm wherever he needs it properly.
Coding everything asm is just too time consuming and can be major hair pulling due to the size of the projects without a strong incentive to manage things (like menuet does)

Reply Parent Score: 2

Alfman Member since:
2011-01-28

_xmv,

"Sure few will code in asm for the hell of it (except MenuetOS people ;-), but any who's actually a real programmer will insert asm wherever he needs it properly.
Coding everything asm is just too time consuming and can be major hair pulling due to the size of the projects without a strong incentive to manage things (like menuet does)"

GCC could improve in the future, but until then, the common perceptions don't do justice to the skill of assembly level programmers.

I still think that for most programmers/projects, there are very strong reasons not to going down the ASM route regardless of asm skill.

It's usually too much of a maintenance burden, and I don't have the time or hardware to test all the hardware combinations that GCC/C can support.

There are some times when I'm not left with much choice though.

In the last performance critical project I worked on I needed to divide a 64bit number by a 32bit number such that the result would always fit in a 32bit register. Obviously this is exactly what the x86 DIV instruction does since the 386.

Unfortunately, GCC (on x86) cannot optimize this case and instead emulates a full 64bit division (numerator, divisor, dividend) in a hidden call to "__divdi3", which has terrible performance.

GCC does what's required of the C spec (full 64bit division, and then demoting to 32bit), but it doesn't bother trying to optimize the case.

Conversely, GCC does optimize the case where two 32bit variables are multiplied into a 64bit variable:

uint32_t a,b;
uint64_t ab;
...
ab = (uint64_t)a*(uint64_t)b;

GCC does not perform a 64bit multiplication above, it calls the x86 MUL instruction, which multiplies 32bit numbers and returns a 64bit number.


Fun times!

Reply Parent Score: 2