Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!mit-eddie!uw-beaver!ubc-vision!ubc-cs!manis From: manis@ubc-cs.UUCP (Vincent Manis) Newsgroups: comp.lang.c Subject: Re: Portable C vs Efficient C or "Cost of Portability" Message-ID: <1287@ubc-cs.UUCP> Date: Sun, 26-Apr-87 14:36:34 EDT Article-I.D.: ubc-cs.1287 Posted: Sun Apr 26 14:36:34 1987 Date-Received: Tue, 28-Apr-87 00:40:40 EDT References: <213@pyuxe.UUCP> <636@edge.UUCP> <1316@frog.UUCP> <658@edge.UUCP> <1017@ubc-cs.UUCP> <682@edge.UUCP> Reply-To: manis@ubc-cs.UUCP (Vincent Manis) Organization: UBC Department of Computer Science Lines: 58 In article <682@edge.UUCP> doug@edge.UUCP (Doug Pardee) writes, quoting me: >> I'm certainly not a C zealot, but I can't think of *any* application for >> which C is a poor choice as a language but assembler is a good one. >Well, let's see. There are some obvious ones, like real-time life-support >or safety-monitor applications in which it is absolutely necessary to show >that in the worst case, the response time will be less than x microseconds. >(This requires not only assembler language, but also relatively primitive >CPUs and system designs in which the hardware performance can be determined >exactly, none of this "depends on the percent of cache hits" stuff allowed. I said *language*, not *compiler*. It may well be that on a particular machine a particular problem requires the use of assembly language. But there is nothing in the specification of C (or other high-level languages) which mandates they be less efficient. In fact, it is often the case that the use of a high-level language makes possible the implementation of substantially more efficient algorithms than would be reasonable for an assembler programmer. >> Of course, that does not mean that a particular C compiler will give code of >> adequate efficiency. > >This is the more important consideration. There's a lot of talk about what >compilers *could* do in optimization. And somehow that's gotten translated >into the mistaken belief that all of this wonderful optimization is really >happening, or will happen soon. In 1973, when UNIX was rewritten in C, the estimate was that the new system was about 1/3 larger (in space) than the old, though the new system was substantially more powerful. Compilers have gotten a lot smarter since then. >The truth is that most C compilers are based on PCC, and produce absolutely >terrible code. Any programmer who has only PCC available should *not* believe >any of the jive about C code being efficient. Agreed. pcc is not my idea of a good compiler. But we were discussing the language. >And even with the decent optimizing compilers, code size in C is awful. See >the discussion in comp.sys.amiga about how to get "hello, world" down from >8K to 1K! In assembler, it'd be maybe 50 bytes. I'm not an Amiga expert. However, I hope that Doug isn't labelling Lattice C as a decent optimisisng compiler. >Don't get lost, I'm getting to a subtle point (I hope). Because there are >so many C programmers, who will work for low pay under less-than-thrilling >conditions, many employers insist that their employees write in C. If I were a programming manager, I would insist that employees write in a high-level language. Whether this language is C, Modula-2, Pascal, or even (ugh) Ada is not the point. For reasons of efficiency, reliability, and portability, there is simply no alternative. (BTW, employers who want less than the best so they can pay less than the best generally don't last too long, at least in my experience). ----- Vincent Manis {seismo,uw-beaver}!ubc-vision!ubc-cs!manis Dept. of Computer Science manis@cs.ubc.cdn Univ. of British Columbia manis%ubc.csnet@csnet-relay.arpa Vancouver, B.C. V6T 1W5 manis@ubc.csnet (604) 228-6770 or 228-3061 "Long live the ideals of Marxism-Lennonism! May the thoughts of Groucho and John guide us in word, thought, and deed!"