Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!hplabs!hpcea!hpfcdc!hpldola!ben From: ben@hpldola.HP.COM (Benjamin Ellsworth) Newsgroups: comp.software-eng Subject: Re: Software Technology is NOT Primitive Message-ID: <1420001@hpldola.HP.COM> Date: Wed, 28-Oct-87 12:28:26 EST Article-I.D.: hpldola.1420001 Posted: Wed Oct 28 12:28:26 1987 Date-Received: Thu, 5-Nov-87 06:57:24 EST References: <3471@sol.ARPA> Organization: HP Logic Design Oper. -ColoSpgs Lines: 189 > Are we to be limited to those features which are portable to all machines? If > we do this, the only arithmetic operations we can allow are fairly short inte- > ger arithmetic; of the machines I have looked into in the past few years, no > two have the same floating-point arithmetic. This includes the CDC6x00, VAX, > CYBER205, CRAY, PYRAMID, IBM360 and its relatives. And should we use the same > algorithm on different machines? This problem is best answered inside of the code generator of the compiler. The HLL doesn't need to know about the machine's abilities, but the compiler writer MUST. The language shouldn't have to be extended in order to take advantage of the machine. The compiler should produce efficient code for the machine. > I am not advocating a language to optimize a specifice machine. I believe that > a language should be sufficiently powerful that the intelligent programmer can > optimize on whatever machine is being used at the time. Once again this optomization should be the responsibility of the compiler not the application programmer. > After a program is > written, especially a library program, it may be found that quirks in the > machine cause the program to be too inefficient. These problems are not quirks in the machine! They are the result of poor code generation by the compiler. > A good programmer will soon learn > what is good on a particular machine and what is not. He(She) shouldn't have to! When given a statement, the compiler should exploit the machine to the fullest advantage of the user. > However, every compiler I have had access to is sufficiently slow > and produces sufficiently bad code that it would be hard to do worse. I can hardly disagree. However, your solution is to have the programmer become the code generator. I find this a step backwards. If you sincerely feel that compiler technology is hopeless, then I suggest that you refine your assembly writing skills and work on enlarging your personal macro library. > The user should be able to introduce type definitions (structures in C), new > operators (such as the very important &~, which may or may not compile > correctly), and overload old operators. This should be very flexible. This is already available, if I understand you correctly, in C++ and ADA. However, efficiency may not be up to your standards yet. > First execution time, second storage. Ahh... The narrow minded short-sighted perspective of a specialized professional. How refreshing! I restores my faith in the nature of mankind. :-) :-) I have a degree in Computer Science and Statistics, so I will presume to have more than a passing familiarity with the class of problems which you spend most of your time solving. In your environment, at the present, nothing runs nearly fast enough. Perhaps you have spent so much emotional energy in frustration at 24hr. machine runs that you are no longer able to see other first priority than speed. However, I think that you just haven't tried. A case to consider is a small battery powered system. Let's say a security application. In this case 10 or 20 sec. slower is not of much concern, however, a fast processor with fast memories is going to kill your batteries in short order. Cutting response time to 1usec just isn't worth the cost to your power supply. I can think of many other examples. I think that the one above is sufficiently general and simple to illustrate the trade-offs that exist outside of AOV. Trade-offs that you have chosen to ignore. > The VAX has twelve general-purpose registers available. If I write a program > which uses eleven registers, I object to the compiler, which does not need any ^^^^^^^^ > registers for other purposes, only giving me six. I object also. However, once again, it is the compiler which is at fault not the language. > An obvious example of this is structured programming and the denial of such > simple elegant ideas as goto. This statement identifies you as one who has worked exclusively in research, the purer the better. I would bet that you have NEVER worked on a large software product (PRODUCT, not project). These products must of neccessity have a long market life in order to recoup the large investment required to produce them. A long market life requires easily grasped algorithms, and more importantly easily modifiable coding style. In order to have a long market life the product must be enhanced, often in ways unforeseen at product introduction. Unconditional branching in the name of speed is not cost justifiable. I suspect that for you however, programs are just tools. Tools which are very problem specific, and which can be discarded as you go. This is entirely defensible for academia. Just don't blindly attribute your constraints to the rest of the world. > The bit-efficient algorithm above starts out > with a case structure; I immediately observed that, by 99.999% of the time > keeping the case as a location only and using goto's, the code would be > considerably speeded up without any loss of clarity. Once again a problem which could be solved by better compiler technology. Once again, you have chosen (perhaps under duress) to be your own code generator. > I agree that the resulting program will probably be non-portable. And unsuitable for those of us who rely on sales instead of tuition to eat and pay our rent. > This is because of the badness of the languages. Nope, the badness of the compilers. Your original statement (i.e. efficient code takes no longer to produce than inefficient code) is Horse-Pucky in any case. A program's first constraints are input and desired output. You wish to add to these first constraints that the program be as fast and small as possible. You then state that it is no harder (takes no longer) to solve the problem in this further constrained state. This (your assertion) is only true when the algorithm is already known and understood because the majority of the time is spent translating the algorithm not solving the problem. Sorry prof. can't pass you this semester (I will consider giving you an incomplete :-). > I do not mean completely > efficient code is easy to produce, but I thik that 80% to 90% will not be > that hard to get. Once again your background is showing through. Most of the problems to which you apply a computer (again I presume) have algorithms which rest upon well known and well understood numerical analysis techniques. Because you are not generating very much of the algorithm when you code, you have lots of free "brain cycles" to devoted to efficiency. For you in your environment it really isn't that hard to get the efficiency, given assembly language hooks. Many of us operate in a totally different environment. My problems have to do with the presentation, organization and storage of data. I have to consider human factors, and worse yet the marketplace. Adding demanding efficiency constraints greatly slows me down. (I work under them anyway but I would be MUCH faster without them.) > I think that if a reasonable language were produced, we will see that there > will be a new era in algorithm development, and that the hackers will be > competing in producing efficient software. I think that you have an interesting definition of the computer idiom "hacker." I also think that what is necessary is better compilers rather than different languages. For you these compilers should come with complete well written math libraries. > It is true that the language does not directly affect the algorithm. I disagree. This like saying that the form in which the data is available does not directly affect the actual analyses done (Most people will work with it in its given form before going to the effort of translation). Perhaps it oughtn't have any effects, but it usually does. > I would be hesitant in using it rather > than a less efficient one which does not unless square root is a hardware > instruction, which it should be but is not on most machines. And a closing note emhpasizing mathematical speed as the measure of a compiler/machine performance. > -- > Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 > Phone: (317)494-6054 > hrubin@l.cc.purdue.edu (ARPA or UUCP) or hrubin@purccvm.bitnet ----- Benjamin Ellsworth Hewlett Packard Company P.O. Box 617 Colorado Springs, CO 80901 (303) 590-5849 ...hplabs!hpldola!ben