🚀 go-pugleaf

Piercarlo Grandi (pcg@cs.aber.ac.uk) writes:
>Any technology should be examined as to it cost, not just as to
>its benefit. Are aggressive optimizers so effective that the
>added cost in compiler complexity and reliability, in encouraging
>more sloppily written programs, in resource usage, is worth it?

It is maybe totally irrelevant, but I cannot fail to notice
that Piercarlo Grandi is posting from an academic site. In
real life, it is in many cases not a question on whether to
write as fast code as possible, but to write code as fast as
possible. There are delivery deadlines to keep. And very seldom
can you advocate from an economic point of view to polish every
part of a big program. Let a good optimizer take care of the
main bulk, and then put the efforts where the bottlenecks are. (*)
  Also, you shouldn't spend the time on the wrong issues. With
the application I currently work, optimization of the Pascal
code probably has little significance since this is a database
application where the I/O is the critical part.

>The issue is then whether the reader of a program be it either
>human or program should not be required to second guess the
>author.

If you write a program to help the compiler to produce good code,
you very often run the risk of having another human reader to
second-guess (whatever that means) what you originally meant.

(*) And when you look at those bottlenecks, what you have to do
is often not to help the compiler, but improve the algorithm. I 
had a program which the profiler told me I spend a good deal of the
time inserting elements in linked lists. So what did I do? Did
I rewrite the linked-list package? No, I changed the way of working
with the lists to keep them down in size. (They were sorted.) When 
I was ready with it the insertion routine was below 1% of the 
executed time. -- 
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se