Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.lang.c Subject: Re: Portable C vs Efficient C or "Cost of Portability" Message-ID: <5801@brl-smoke.ARPA> Date: Sun, 26-Apr-87 03:05:00 EDT Article-I.D.: brl-smok.5801 Posted: Sun Apr 26 03:05:00 1987 Date-Received: Sun, 26-Apr-87 23:07:59 EDT References: <213@pyuxe.UUCP> <636@edge.UUCP> <1316@frog.UUCP> <658@edge.UUCP> <1017@ubc-cs.UUCP> <682@edge.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 62 I tried to ignore this debate, but here goes: In article <682@edge.UUCP> doug@edge.UUCP (Doug Pardee) writes: >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.) While sufficient, that approach is not necessary. I know of several real-time applications coded in a variety of high-level languages that work just fine. One just has to know what one is doing. >Less obviously, almost anything having to do with character handling. Most >CPUs provide hardware instructions for string copies, compares, and searches. >C provides no statements which could be compiled into these instructions. This also is not correct. C these days includes a standard run-time support library with a substantial number of string-handling routines; most reasonable implementations make use of special machine instructions when they exist (and when they are faster than ordinary instructions, which amazingly is not always the case). It is even possible to avoid function call overhead and generate in-line code for these routines under most circumstances, although generally it's not worthwhile to do so. >Also, anything that has to do with direct hardware manipulation (like device >drivers). There may occasionally be problems, but I (among others) have written device drivers that port between radically different machine types with several orders of magnitude less work than would be required for assembly- language versions, and performance is quite acceptable. Virtually all UNIX device drivers are written in C. I even find C an easier way to access device registers on my Apple (since such access is only a small fraction of the necessary operations for most device-handling algorithms). >Any programmer who has only PCC available should *not* believe >any of the jive about C code being efficient. Most of us learned long ago that there are better ways to spend our time than trying to squeeze every last drop of performance out of a particular system. There are several kinds of "efficiency", including "programmer efficiency". It's certainly true that C is not always the best choice for every programming project. However, it is usually a pretty good one, and if one has to concentrate on a single language for a random assortment of projects, C is probably a better choice than any other language. Some relevant considerations are availability, portability, efficiency, closeness to the machine, and so on. In spite of much experience in programming in a variety of assembly languages, I do so now only when absolutely necessary (such as in creating run-time support for C compilers). It just isn't good economics to do otherwise. I don't quite understand the argument about C programmers being less skilled than for other languages. It takes MORE skill to be really proficient in C than in languages such as Fortran and BASIC. If you mean that home hobbyists tend to be less than professional, and that they often use C (or BASIC!), then that's probably true. So what? Incompetents will do a much worse job using assembler, and skilled professionals will do a better job using C.