Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!caen!uwm.edu!psuvax1!hsdndev!cmcl2!adm!smoke!gwyn From: gwyn@smoke.brl.mil (Doug Gwyn) Newsgroups: comp.sys.apple2 Subject: Re: Re- HLLs vs. Assembly Message-ID: <15742@smoke.brl.mil> Date: 7 Apr 91 01:20:15 GMT References: <9104051936.AA16687@apple.com> <15734@smoke.brl.mil> <13391@ucrmath.ucr.edu> Organization: U.S. Army Ballistic Research Laboratory, APG, MD. Lines: 67 In article <13391@ucrmath.ucr.edu> rhyde@ucrmath.ucr.edu (randy hyde) writes: >You (I assume "U.S. Army Ballistic Research Laboratory, APG, MD." implies >that you work at the ABRL) haven't developed any commercial quality software >products recently (that I've seen anyway) so ABRL is not under the same >performance pressures as, say Electronic Arts. The Army can afford machines >that run 10x faster, a typical PC user cannot. Furthermore, the Army often >needs to purchase computers of various archetectures, the average PC user >does not (they get locked into a Mac, PC, or [as you can tell by reading >posts in this newsgroup] an Apple IIgs). Therefore, portability is a much >bigger concern to the DoD (hence Ada) than it is to a typical PC user. You really shouldn't try to guess about an environment that you are not familiar with. I have personally developed interactive graphics systems for a company whose sole livelihood depended on its ability to compete in the commercial marketplace. Those systems were primarily coded in Fortran (also RatFor), even the tablet driver that was involved in tracking input where 1/10 second was the absolute upper limit that human physiology would allow for each complete cycle of input_coordinates- process-update_display. They ran on the DEC PDP-11/34a, which was less powerful than almost any machine you can find these days. The only assembly code (other than that used in the vendor's operating system, which was used solely for disk file I/O) was for that portion of the dynamic memory allocation package that had to temporarily fudge the memory management unit's segmentation registers, and the only reason for using assembler there is that the Fortran run-time environment assumed by the vendor's compiler was being temporarily violated while the MMU registers were being fiddled. The resulting systems did more things in better ways than any competing product, with better interactive response. Another system I was later involved with had as a major subcomponent a real-time data acquisition process. A contractor originally implemented it with a critical function coded in assembler supposedly for speed. A later rewrite by another employee of the company I worked for relied on careful analysis of the actual requirements, threw out the assembler code (resorting entirely to C), simplified the rest of the implementation, and ended up with better (and certainly more maintainable) performance than the original implementation. As to BRL, it is irresponsible of you to suggest that we are spending taxpayer funds prolifically in order to avoid doing things right. Quite to the contrary, our mission requirements caused us to develop our own interactive solid modeling system, which initially was based on small PDP-11s and PDP-11/70s, which we continued to use well past the availability of faster systems. Naturally these applications too were coded in C. Therefore, it was possible to PORT them to newer hardware when it eventually was advantageous to do so. We have never found the applications to run excessively slowly, and there is absolutely no basis for your repeated claims of factors of 10 execution speed differences between HLLs and assembler. A few carefuly identified "bottleneck" sections of code were, for some systems, recoded in assembler to see if it would help. In no case was there more than a few percent improvement, which makes this almost never worth doing. We have better ways to invest our limited software development resources. Perhaps you don't? >Be ye forewarned, however, when that day arrives, all you C jockeys are >going to be on the defensive. By then, people will be arguing for the use >of LISP, Prolog, ICON, APL, SETL, 4GLs, and other languages not in existence >yet for the same reasons you're claiming everyone should be using C (or Ada, >or Pascal). Unlike you, I have not made ridiculous claims that everybody ought to be using any specific programming language. I have said that assembler is seldom justified, but, like ANY programming language, when it is justified it should be used. You seem to have decided that there is only one criterion for programming, namely execution speed, and have further made unwarranted claims for the gains that assembler could provide even there. Considering the overall software development picture, most computing professionals have long since discovered the advantages of suitable HLLs.