Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!sunic!enea!sommar From: sommar@enea.se (Erland Sommarskog) Newsgroups: comp.lang.misc Subject: Re: 'register' variables and other goodies Message-ID: <808@enea.se> Date: 24 Feb 90 20:24:23 GMT References: <1624@aber-cs.UUCP> Organization: Enea Data AB, Sweden Lines: 36 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