Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!exodus!rbbb.Eng.Sun.COM!chased From: chased@rbbb.Eng.Sun.COM (David Chase) Newsgroups: comp.lang.misc Subject: Re: Aggressive optimization vs HLL's Message-ID: <2452@exodus.Eng.Sun.COM> Date: 9 Nov 90 18:56:21 GMT References: <2060@aber-cs.UUCP> <65592@lanl.gov> <2677@l.cc.purdue.edu> <12175@ganymede.inmos.co.uk> <123@garth.UUCP> Sender: news@exodus.Eng.Sun.COM Organization: Sun Microsystems, Mt. View, Ca. Lines: 57 pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >The problem, bfore considering market demand, can also be expressed >thus: should David Chase and Jim Giles and Preston Briggs and Hank Dietz >(just to mention some frequent contributors to this sort of discussion) >spend their time devising ever more ingenious and complicated and hairy >code generator level hacks, or would their research and development >efforts be better spent on clever compilation of higher level languages >and source level programmer's assistants? I *was* working on (not yet clever) compilation of a slightly higher level language at Olivetti, but we all got laid off in February and had to find new jobs. It's very nice being employed, paid, and appreciated. Without a job, one tends to consider market demand, especially with a baby on the way and no national health insurance. There's no lack of higher level alternatives that would probably be more reliable than C, C++, and Fortran, optimized or not, and many of my colleagues, advisors, and advisors' advisors have tried hard to sell/give/push them to the rest of the world. So far, they've had little luck. I'll bide my time; there's many interesting aggressive optimizations that can also be applied to high level languages too, when they finally catch on. To quote Rovner (PARC CSL-84-7): "Time spent by programmers to solve storage management problems has decreased from an estimated 40% in Mesa to an estimated 5% in Cedar (...). Automatic storage deallocation can improve programmer productivity dramatically without affecting performance adversely." That's the big picture that you're looking at, and the one that I'd like to look at, but so far the programming public in general is not interested. We've tried very hard to get them interested, but not much luck yet. (I.e., at least in this case you are preaching to the choir). Now, once you've opted for C/C++/Fortran, and the ultimate importance of efficiency, one might as well deliver it as reliably and portably as one can. Optimizing compilers fill that (very large) niche; they tend to be less buggy at optimizing C/C++/Fortran than your average programmer, and tend to do a good job. Compilers can be regression-tested, and their known bugs can be catalogued, and hopefully repaired -- neither of these things holds for humans. Those people on the C/C++ bandwagon who *are* interested in garbage collection are discovering that optimizations (not even terribly aggressive ones) *correctly* applied to C/C++ can prevent the correct functioning of many garbage collectors, unless "volatile" is applied liberally to the code (this is massive overkill, but it makes the collectors work). Daniel Edelson's C++ collector is *probably* robust in a single-threaded process, especially if a small number of "volatile" declarations are used, and may be robust in a multi-threaded process (the possible non-robustness appears only if a compiler is very aggressive about tracking of aliases and reordering of loads and stores for scheduling or other purposes -- clearly, this is permitted -- else why would the language have "volatile" in it?) If I were king of the world, things would be different. But I'm not. David Chase Sun Microsystems