billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe,2847,) (06/02/89)
From article <7037@cbmvax.UUCP>, by jesup@cbmvax.UUCP (Randell Jesup): > as the hardware becomes faster, and the programs we write become more > complex, we are moving to higher levels of abstraction to keep the > complexity from overwhelming us (or making it too expensive to do). [...] > We trade off efficiency of execution/size for cost of production While this is certainly true, it should also be kept in mind that good optimizing compilers can and should violate levels of abstraction in search of improvements. Telesoft's TELEGEN 2 Ada compiler, for example, exploits this extensively in its global optimization mode, optimizing across package boundaries by eliminating the aspects of general-purpose packages which are not actually used by a particular application. Similarly, all the techniques of interprocedural optimization can be extended to procedures which are separated by impenetrable walls as far as the programmer is concerned, but which live in glass houses from the compiler's point of view. It may well be that in large projects, no amount of hand-coding will ever result in the levels of efficiency which can result from the global optimizations performed by a compiler while still preserving correctness; above a certain point, human cognitive limits force us to abandon hand-coding as a viable technique, even assuming that we could afford to continue using it. Bill Wolfe, wtwolfe@hubcap.clemson.edu
weide@elephant.cis.ohio-state.edu (Bruce Weide) (06/06/89)
If there is to be a "reusable components" cottage industry, probably many components will only be available as specifications plus runnable code in object form. This suggests that source-level optimizations that cross package/module boundaries may be of relatively little use. What, then, can be done about the (apparent) inefficiency of reusable components? The above argument suggests we should concentrate on designing abstract reusable components which at least permit efficient implementations, and then try to build very efficient realizations of these abstract components. Performance trade-offs among different operations of the same component are inevitable, so we'll need to allow multiple implementations of the same abstraction to give the client programmer a choice of performance alternatives. And perhaps we should concentrate on, say, advances in run-time system design and in architectures so that genericity and the like do not introduce additional run-time overheads and so procedure calls are much faster. These might be more productive approaches for the long term than ever more complex compiler tricks whose effectiveness would be thwarted if reusability actually became a reality. -Bruce ------ Prof. Bruce W. Weide Dept. of Computer and Information Science The Ohio State University 2036 Neil Ave. Mall Columbus, Ohio 43210-1277 USA Phone: 614-292-1517 E-mail: weide@cis.ohio-state.edu
rang@cpsin3.cps.msu.edu (Anton Rang) (06/06/89)
In article <51097@tut.cis.ohio-state.edu> weide@elephant.cis.ohio-state.edu (Bruce Weide) writes: If there is to be a "reusable components" cottage industry, probably many components will only be available as specifications plus runnable code in object form. This suggests that source-level optimizations that cross package/module boundaries may be of relatively little use. Several of the systems which would support component distribution easily also allow for "intermediate forms" of the code. It doesn't need to be a straight "source/object" distinction; you can distribute the intermediate code. For instance, a TeleSoft (<--prob. tm) Ada library contains information which can be used for global optimization. What, then, can be done about the (apparent) inefficiency of reusable components? The above argument suggests we should concentrate on designing abstract reusable components which at least permit efficient implementations, and then try to build very efficient realizations of these abstract components. Performance trade-offs among different operations of the same component are inevitable, so we'll need to allow multiple implementations of the same abstraction to give the client programmer a choice of performance alternatives. I agree. It would be nice to have some sort of routine hierarchy, which is typically handled transparently by the environment, but where the programmer can override it. I would love to be able to say "sort(x)" and let the environment do the work about figuring out how to do it (assuming that X is of some type it knows how to sort...arrays of records, perhaps, if I've defined a record-comparison routine). I could then use "sort.insertion(X)" if I decided that an insertion sort would give the best performance in a particular implementation. (Actually, I'd prefer specializing it without the source code changing.) Yes, this would be work, but I think it might be a goal worth aiming for. And perhaps we should concentrate on, say, advances in run-time system design and in architectures so that genericity and the like do not introduce additional run-time overheads and so procedure calls are much faster. True...though having a decent global optimizer, *** with inlining ***, takes care of most of the genericity arguments I've seen. (Of course, the code size gets much bigger once you start inlining.) These might be more productive approaches for the long term than ever more complex compiler tricks whose effectiveness would be thwarted if reusability actually became a reality. Might be. I'm not sure about what you can do in architectures, though. I think developing a good environment which can give "hints" to the compiler/linker might help.... +---------------------------+------------------------+ | Anton Rang (grad student) | "VMS Forever!" | | Michigan State University | rang@cpswh.cps.msu.edu | +---------------------------+------------------------+
adamsf@cs.rpi.edu (Frank Adams) (06/14/89)
In article <51097@tut.cis.ohio-state.edu> Bruce Weide <weide@cis.ohio-state.edu> writes: >If there is to be a "reusable components" cottage industry, probably >many components will only be available as specifications plus runnable >code in object form. I suspect that software components in object form will never be successful. There is too much need to diddle with things, too little which can be used as is. And inheritance with run-time binding is too often an inadequate method of diddling. Frank Adams adamsf@cs.rpi.edu
peirce@claris.com (Michael Peirce) (06/15/89)
In article <5479@rpi.edu> adamsf@cs.rpi.edu (Frank Adams) writes: >In article <51097@tut.cis.ohio-state.edu> Bruce Weide <weide@cis.ohio-state.edu> writes: >>If there is to be a "reusable components" cottage industry, probably >>many components will only be available as specifications plus runnable >>code in object form. > >I suspect that software components in object form will never be successful. >There is too much need to diddle with things, too little which can be used >as is. And inheritance with run-time binding is too often an inadequate >method of diddling. > >Frank Adams adamsf@cs.rpi.edu Never is a long time, but I agree that for the immediate future this will probably be true. I'm currently using MacApp, basically a class library for implementing Macintosh programs in Object Pascal. There a number of "components" within MacApp that I can simply use based on their spec, but often I need to look inside at the source code to figure out various things (debugging based on specs only isn't pretty). Of course, at some time, MacApp might be advanced enough and stable enough to not require source to really use make it work, but that will require quite some time. An aside. Why all this bickering between the OOPs people (mainly C++ folks) and the Ada folks? I used Ada at my previous job and OOPs now and I think they're both great. Both sides could learn something from the other rather than simply taking pot shots. Sure Ada, C++, Object Pascal, even SmallTalk have their short comings (lots and lots!), but they all do have their good points too. Claris Corp. | Michael R. Peirce -------------+-------------------------------------- | 5201 Patrick Henry Drive MS-C4 | Box 58168 | Santa Clara, CA 95051-8168 | (408) 987-7319 | AppleLink: peirce1 | Internet: peirce@claris.com | uucp: {ames,decwrl,apple,sun}!claris!peirce
apc@cbnews.ATT.COM (Alan P. Curtis) (06/17/89)
In <5479@rpi.edu> adamsf@cs.rpi.edu (Frank Adams) writes: }In <51097@tut.cis.ohio-state.edu> Bruce Weide <weide@cis.ohio-state.edu> writes: }>If there is to be a "reusable components" cottage industry, probably }>many components will only be available as specifications plus runnable }>code in object form. }I suspect that software components in object form will never be successful. }There is too much need to diddle with things, too little which can be used as is. }Frank Adams adamsf@cs.rpi.edu I think the point of truely reusable components is that you cannot, and should not diddle! Now there may be another industry for "interesting code fragments" with with you diddle, but if you are diddling with a thing that was claimed to be a "reusable component", then it wasn't reusable, or wasn't the right component, now was it? Do you diddle with quad nand gates? Do you diddle with the internals of a 68k? I din't think so. apc PS Hi Bruce... -- Alan P. Curtis | AT&T Bell Labs | apc@cblpe.ATT.COM