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

Sorry, but I fail to find where the code I showed is "less understandable". It is actually a very well known technique, i.e., reduce the number of unneeded comparisons.

I was thinking about how you used trigraphs and put the loop's iterator inside of the loop's body instead of putting it within the for() itself.

Anyway, it was used only to point out one of the many gross assumptions people do about code efficiency, compiler optimizations and related stuff. We clearly should teach more about algorithms than about languages like we do today.

But then wouldn't there be a feeling among both students and their future employers that they have learned lots of pretty theory, but not how to actually do things in practice ?

Also, is there such a thing as a language-independent algorithm ? Different languages have very different ways of expressing things, and algorithmic course generally teach students about an imperative algorithmic language pretty close to the structure of Pascal and C.

Edited 2011-06-11 11:00 UTC

Reply Parent Score: 1

vodoomoth Member since:

But then wouldn't there be a feeling among both students and their future employers that they have learned lots of pretty theory, but not how to actually do things in practice ?

I hear this often in the professional world, as if theory was the natural antonym of "practice". But do you think that Oracle made the piles of money they've made through the years without using Codd's relational algebra? Instead of relying on "indexes", hints and DBAs to make SQL queries more efficient, it is sometimes faster to rewrite a query, which means you know about relational algebra, you understand that it is always better to reduce the number of tables in a join, you know when nested queries are a valuable contribution to the overall efficiency. In that specific real-life case I'm implicitly referring to, the query was rewritten by me and the response time that was above the 10-minute timeout fell to something like 30 seconds on average.

In practice, the goal is to query the database (or execute code on the CPU). Any elements that get me closer to that goal, be they elements of theory, are welcome.

My point is: knowing the theory behind things doesn't take a thing away from people. If I was to hire someone to fill a position, I'd rather take the guy who knows the theory. And, as a side note, the "professionals" I've worked with who disparaged "nice theory" not only have terrible justifications for their bad practices, but they are resistant to thinking outside the box. Err, "their" box.

I'm still waiting to see an example of theory ruining or impeding some work instead of making it better IN PRACTICE.

Reply Parent Score: 2

Alfman Member since:


Speaking of Oracle's optimizations:

I was terribly disappointed with the Oracle 9i cost based optimizer, or was it 10GRAC? Things tend to blur after a few years.

After upgrading, many of the resulting queries went from nearly instantaneous to 30s or several minutes long. It was the version which started preferring hash joins for everything, even when /*+FIRST*/ was requested. Updating statistics for all tables had no effect. There may have been a few DB links in there, but I don't recall them being the cause.

In theory the cost based optimizer should have been better than the rule based optimizer.

At the time we were told to either add /*+RULE*/ or manually specify an index hint, either of which solved the problem. Oracle always had us running patched versions to solve solve one glitch or another.

I do remember tracking down some tricky oracle logic bugs, such as the time it thought to_date('2099-12-31')+1 > to_date('2099-12-31') was false.

This bug manifested itself as broken business rules, we ultimately traced the 2099-12-31 value to bad user data.

Ah oracle, still my favorite RDB though! These days I work predominantly with mysql (yuck), also owned by oracle.

Reply Parent Score: 2