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 476926
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: GCC isn't all that great
by Alfman on Sat 11th Jun 2011 09:57 UTC in reply to "RE[3]: GCC isn't all that great"
Alfman
Member since:
2011-01-28

acobar,

"Well, I will repeat to you what I do to everyone I met and that would ask my advise (not your case) on programming: first look for a good, tested, implementation. Many people try to code fragments that are already optimized for ages. They don't look at Donald Knuth's ACP, fftw, lapack, atlas and many other well-thought code before they start and, as such, write subpar code."


I actually don't encourage people to optimize things at such small levels or in assembly. I'm just disturbed that so many people are under the false impression that their compilers are so difficult to beat.


"You get a pretty decent optimized code:"

Yes, I am aware that we can coerce the compiler to generate better instructions by rewriting the C code.

(Although it still isn't as good for the other reasons already discussed).

It concerns me that GCC converts our C code to assembly so literally instead of generating more optimal paths.

Should we really encourage devs to adjust thier programming style to compensate for GCC optimizer deficiency?

Does this mean that C devs will have to understand CPU internals in order to have GCC produce optimal code?

I really don't think we should be making excuses for GCC here. There is nothing unreasonable about expecting the original code to be optimized by the compiler.


Edit: By the way I am guilty of rewriting C code at the micro level in order to help GCC optimizer along. But we shouldn't have to do this in the first place.

Edited 2011-06-11 10:08 UTC

Reply Parent Score: 5

acobar Member since:
2005-11-15

Perhaps, I should have said it on a more direct style: I do not encourage people to write optimized code, I tell them to look for good algorithms and rather to good libraries whenever they are available.

To me, actually, all this talk about the better language to code in is a bit misleading, we should clearly concentrate on algorithms. We don't know on what we will be coding 20 years from now be we know that good algorithms will probably survive, like they did on past.

Sincerely, for most of the applications it does not matter a dime if you spend 1 millisecond or 1 microsecond doing something, and there are a factor of 1000 involved. And for the ones that matter, there are a chance that it is already well known and that a wise compromise was devised.

I see people everyday praising languages that make them write less code, or type less, or write more comfortable (understandable) code, or in the ones they like the syntax more. And all those arguments are sensible.

I, particularly, like languages that have all tools I feel I may need, like GUI generators, automation by scripts, code templates (not necessarily like on C++), profilers (for the very rare occasions where they are needed), many of modern OO concepts and, of course, that may be linked against good, well known tested libraries.

To be even more direct: people should learn more before code, unlike what we so repeatedly see. This would save time on rewrites and latter tunes.

Edited 2011-06-11 11:38 UTC

Reply Parent Score: 2

ebasconp Member since:
2006-05-09

OT: I enjoyed this thread... Though I cannot contribute here, the only thing I can say is that I like OSnews because it encourages so technical discussions like this. Thank you guys!!!

Reply Parent Score: 3

Alfman Member since:
2011-01-28

acobar,

"Perhaps, I should have said it on a more direct style: I do not encourage people to write optimized code, I tell them to look for good algorithms and rather to good libraries whenever they are available."

I'm not sure what this has to do with my original post, but we seem to be on the same track.

"To me, actually, all this talk about the better language to code in is a bit misleading, we should clearly concentrate on algorithms."

Ditto.

"Sincerely, for most of the applications it does not matter a dime if you spend 1 millisecond or 1 microsecond doing something, and there are a factor of 1000 involved."

Well I actually disagree here, but that's just me.

"And for the ones that matter, there are a chance that it is already well known and that a wise compromise was devised."

Yes, by far and large, it is very difficult to write truly original algorithms because it's extremely likely thousands of other developers have tried to solve the same problems before us. However just because someone else has already done it dosn't strictly mean that we need to copy and paste every single line of code either.

"I see people everyday praising languages that make them write less code...And all those arguments are sensible."

Yes they are.

Reply Parent Score: 2

vodoomoth Member since:
2010-03-30

Are you saying that GCC should have turned the code you wrote into the code by @acobar? Or that it should
magically guess the intentions in some code section?

I don't see a compiler failing to do that qualify as a "deficiency".

Reply Parent Score: 2

Alfman Member since:
2011-01-28

vodoomoth,

"Are you saying that GCC should have turned the code you wrote into the code by @acobar? Or that it should
magically guess the intentions in some code section?"

Not exactly, no.

It should have recognized that it would achieve the exact same logic semantics had it precomputed the number of iterations up front instead of testing array bounds on each iteration. This is a fairly common optimization for many use cases.

Reply Parent Score: 2