From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f21b19265de84351 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1993-03-03 23:39:49 PST Newsgroups: comp.lang.ada Path: sparky!uunet!pmafire!news.dell.com!swrinde!cs.utexas.edu!sdd.hp.com!sgiblab!sgigate!sgi!wdl1!scf16!bashford From: bashford@srs.loral.com (Dave Bashford) Subject: Re: Ada Embedded Systems Efficiencies Message-ID: <1993Mar4.015054.22689@scf.loral.com> Sender: bashford@scf.loral.com (Dave Bashford) Organization: Loral Space & Range Systems References: <1993Mar2.223618.18978@intellistor.com> <1993Mar3.143900.10592@saifr00.cfsat.honeywell.com> <1n3enhINNsec@umbc4.umbc.edu> Date: Thu, 4 Mar 1993 01:50:54 GMT Date: 1993-03-04T01:50:54+00:00 List-Id: I'm jumping in a little late with my experience, so I don't have the original article to quote. What I would like to address is the subject of optimizing on the micro/macro level. I was brought onto a R/T graphics program that had been "optimized" at the micro level in order to implement a certain feature. The problems though were that graphics hardware doubles in speed every 6 months (more or less :-) and requirements change every 3.8ms. It was eventually decided that the sacrifices made to implement that one feature were too costly and what we really needed was higher update rates. In order to accomplish this we needed to optimize at the highest levels of our program which was not possible because of the tightly coupled nature of the micro-optimizations. We were not able to take advantage of the new hardware they kept throwing at the problem. After many months, I convinced management that we should scrap the system and start over with the experience and requirements that had been learned from the past (a S/W engineer's dream !). Eight months later (the original program had been going on for four years) we had a new system that was running _many_ times faster, was infinitely easier to maintain (the requirements are still changing), and now has the original "feature" implemented without the original sacrifices. I believe, like many others, that the compilers are much better at micro-level optimizations; that requirements are _never_ static; and that "optimizations" that tighten coupling are extremely costly in the long run (if they work at all). -- db bashford@srs.loral.com (Dave Bashford, Sunnyvale, CA)