From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 13467 invoked from network); 22 May 2020 18:41:07 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 22 May 2020 18:41:07 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 9F60B9C913; Sat, 23 May 2020 04:41:00 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id E7B739C5E5; Sat, 23 May 2020 04:40:28 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 16D399C5E5; Sat, 23 May 2020 04:40:26 +1000 (AEST) Received: from hop.toad.com (75-101-100-43.dsl.static.fusionbroadband.com [75.101.100.43]) by minnie.tuhs.org (Postfix) with ESMTPS id 585719C194 for ; Sat, 23 May 2020 04:40:25 +1000 (AEST) Received: from hop.toad.com (localhost [127.0.0.1]) by hop.toad.com (8.12.9/8.12.9) with ESMTP id 04MIeBm0022672; Fri, 22 May 2020 11:40:11 -0700 To: Tyler Adams In-reply-to: References: <20200521182817.08C0318C093@mercury.lcs.mit.edu> <202005221109.04MB92D3016090@freefriends.org> Comments: In-reply-to Tyler Adams message dated "Fri, 22 May 2020 14:15:18 +0300." Date: Fri, 22 May 2020 11:40:11 -0700 Message-ID: <22671.1590172811@hop.toad.com> From: John Gilmore Subject: Re: [TUHS] History of popularity of C X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: The Eunuchs Hysterical Society , jnc@mercury.lcs.mit.edu Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" Tyler Adams wrote: > Doesn't C++ also generate tight code and is fairly close to the metal? > Today C++ is the high performant language for game developers and HFT shops. > > But, I never found it on any of these embedded systems, it was straight C. My take on this is that programmers who understand the underlying hardware architecture can easily intuit the code that would result from what they write in C. There are only a few late features (e.g. struct parameters, longjmp) that require complex code to be generated, or function calls to occur where no function call was written by the programmer. Whereas in C++, Pascal, Python, APL, etc, a few characters can cause the generated code to do immense amounts of unexpected work. Think of string compares, hash table types, object initializers, or arbitrary amounts of jumping through tables of pointers to different kinds of objects. Automated memory allocation. Garbage collection. This is both a blessing and a curse. In C it was quite predictable how well or badly typical sections of your code would perform. If the performance was bad, it was YOUR fault! But at least YOU could fix it, without learning to hack a compiler instead of your own application. (I once found Berkeley SPICE code doing string compares in a triply nested loop, just to look up the names of the signals. In C. Making changes to a large state machine going into a custom chip was taking the Sun hardware engineers multiple hours per change. I spent weeks finding the source code (Sun's tools group was dysfunctional; I got it from UCB). In half a day of profiling it and fixing it to cache the result of the first string lookup on each signal name, four hour rebuilds went down to under a minute. A second day of profiling and cacheing, just for fun, took it down to 10 seconds.) John