Re: Programming languages

"António" == António Marques <entonio@xxxxxxxxx> writes:

>> If that tiny piece of code only takes up 0.1% of the
>> execution time (after doing all other optimizations), does
>> it worth the human time/effort to hand-optimize it?

António> I think the answer lies in the ASM code one does find in
António> real world performance-critical software. The issue is not
António> some tiny pieces of code that take 0.1% of the execution
António> time; it's the code itself that is typically 0.1% of the
António> total code, but used in a disproportionately high
António> frequency.

Neither the frequency nor the length of the code matters here. What
matters is: how much time the CPU *really* spends on that fragment of
code. If a piece of code (A) is invoked a billion times in the course
of 10 hours, but each invocation takes only 1 microsecond (including all
call-return overheas), that's only 1000s out of 10 hours, or 2.8% of the
total execution time. That's not a good candidate for optimization.
There may be another piece of code (B) that gets invoked only 1000
times, but spends the CPU 4 hours (14.4s per call). This is a better
candidate for optimization because it occupies 40% of the execution
time.

Why?


Suppose you can very skillfully optimize code fragment A to reduce its
execution time down to 10% of the original. i.e. 0.1ms per call. So, 1
billion calls now takes only 100s instead of 1000s. That saves 900s
(out of 10 hours).

OTOH, I choose to optimize code fragment B instead. I'm not as smart
and skillful as you are. So, I can only reduce the execution time of B
by 10%. i.e. the time it takes for each invocation of B is reduce down
to 90% of the original. Each call now takes 12.96s instead of 14.4s.
But don't forget that this code gets called "merely" 1000 times. So,
the total time taken by this code fragment is now 12960s instead of
14400 sec. That's a saving of 1440s (out of 10 hours).


So, who is smarter? The one who uses all his highly specialized skills
and spends a lot of time effort, saving 900s in the end? Or the one who
just pulls a few simple tricks (or turns on a few compiler flags) and
effectively saves 1440s?



That's why one should profile the code to locate good candidates for
optimization.



António> Maybe compilers will be able to cope wit it too in the near
António> future, but right now they're not so powerful as
António> convenience would have us believe.

I used to think like that 10 years ago. But playing with 'gcc -O3 -s'
has changed my mind.



António> GCC isn't the end and all of compilers, either, in what
António> regards producing optimal binaries, only the one with the
António> highest number of supported front-ends and targets.

Yes. But it's already very amazing in terms of aggressive
optimizations. It does more than I would/could have done manually.


António> I think it will be necessary to build better expressiveness
António> into languages ('inline' is but a small step, and a
António> misguided one at that, if there is comething the compiler
António> should be able to do by itself, it should be inlining)

Well... "inline" is just like "register", or writing "++i;" instead of
"i++;". Things that some programmers thought would help the compiler.
But it turns out that modern compilers are better at this than we are.
Just leave it to the compiler, and only intervene when find that it is
really less smart than you are.

"misguided"... haha... modern compiler writers discourage programmers
from using "register". This is because compilers can now identify
candidates for register allocation much better than the human
programmer. If the compiler really obey your "register" hint, the
resulting code may be even less efficient than what the compiler would
choose. In other words, it is you the program who is "misguiding" the
compiler. (So, some compilers simply ignore "register" and the like,
and makes its own decision, allowing you to override this with
command-line switches or pragma directives. Usually, you won't be
better of with the overriding.)



António> before we get to the next level of optimisations (and here,
António> yes, it may not be worth the cost, though it would be
António> nice). Then there is the problem that you optimise one way
António> but lose the other way. Maybe we're hitting a wall.

So, just trust the modern compilers, and examine the generated code.
Most of the time, they can get it right. Save yourself the time for
more challenging optimization tasks.



António> Maybe the only way forward is to develop languages better
António> suited to parallelism. Not that functional languages don't
António> do a good job, but the world has to make do with average
António> programmers and those can't cope with anything else than
António> imperative stuff.

Fire those who cannot think outside the imperative jail!

If a programmer writes SQL imperatively, he's likely to get very
inefficient code like this:

resultSet = conn.execute("SELECT * FROM users");
while (resultSet.next()) {
if (resultSet.get("expiry_date")+7 < today()) {
userId = resultSet.get("id");
// issue more 'SELECT *' statements to pull in more
// info about this user from other tables
// and then send reminder email to 'userId'
}
}
resultSet.close();

This code not only runs more slowly, but also puts unnecessary load on
the DB server and the network. Don't laugh. Many "programmers" write
code like this. They simply can't think in a non-imperative way:
relational algebra (joins, projections, selections), declarative
programming, etc.


Well... but you should be happy that there are so many such sloppy
programmers. They have driven higher and higher demands for computers
of bigger and bigger computational and storage capacities. This
economic power drives applied research for faster computers and higher
storeage capacities at lower and lower prices. So, we can now buy
computers that are 1000s times more powerful than those 20 years ago, at
half the price.


--
Lee Sau Dan 李守敦 ~{@nJX6X~}

E-mail: danlee@xxxxxxxxxxxxxxxxxxxxxxxxxx
Home page: http://www.informatik.uni-freiburg.de/~danlee
.

Relevant Pages

  • Re: Brian Kernighan, maybe Im not worthy, maybe Im scum
    ... what experienced programmers do, ... optimization, ... Thugs" ad nauseum fits that a lot more closely than discussing compiler ... be modified outside a loop, and guessing ...
    (comp.programming)
  • Re: Brian Kernighan, maybe Im not worthy, maybe Im scum
    ... No, you assumed, and admitted so, that the compiler would address it ... Randy, the Computer Thug. ... manual code optimization for quite a long time. ... Not that you would know necessarily, but programmers have been writing ...
    (comp.programming)
  • Re: the quality of assembly language code
    ... what people considered "optimization" when Tony Hoare wrote this paper ... > this potential of assembly language code "beating" the compiler is ... programmers are too lazy to write the code efficiently. ...
    (comp.lang.asm.x86)
  • Re: the quality of assembly language code
    ... so the programmer doesn't see the gaffes the compiler is ... If code today were written to that level of optimization, ... programmers are too lazy to write the code efficiently. ... > Compiler optimizers usually do an adequate job. ...
    (comp.lang.asm.x86)
  • Re: Simple example of database made "forth way"?
    ... arise situations in which code readability and maintainability are of ... advantages of abstraction for readability. ... fields where the optimization is not about sequential fields at ... optimization in the compiler, or to switch to assembler to do it. ...
    (comp.lang.forth)