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 18771 invoked from network); 22 May 2020 19:31:59 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 22 May 2020 19:31:59 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 5B8A19C915; Sat, 23 May 2020 05:31:58 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 625CD9C5E5; Sat, 23 May 2020 05:31:45 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id A58C99C5E5; Sat, 23 May 2020 05:31:42 +1000 (AEST) Received: from mcvoy.com (mcvoy.com [192.169.23.250]) by minnie.tuhs.org (Postfix) with ESMTPS id 546BE9C194 for ; Sat, 23 May 2020 05:31:42 +1000 (AEST) Received: by mcvoy.com (Postfix, from userid 3546) id E72FA35E140; Fri, 22 May 2020 12:31:41 -0700 (PDT) Date: Fri, 22 May 2020 12:31:41 -0700 From: Larry McVoy To: John Gilmore Message-ID: <20200522193141.GH3357@mcvoy.com> References: <20200521182817.08C0318C093@mercury.lcs.mit.edu> <202005221109.04MB92D3016090@freefriends.org> <22671.1590172811@hop.toad.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22671.1590172811@hop.toad.com> User-Agent: Mutt/1.5.24 (2015-08-30) 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" On Fri, May 22, 2020 at 11:40:11AM -0700, John Gilmore wrote: > 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. Amen. > 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. Double amen. > 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. Triple amen. > (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.) Gazillion amens (I especially loved the jab at Sun's tools group, I wrote the SCM that Sun used for Solaris initially. They tried to get me to join the tools group to make my stuff "official" - it worked just fine being "unofficial". I took a look at the people in the tools group, no offense, but it was a big step down from working with people like srk and gingell and shannon, not to mention that all of my peers were smart. Tools group, just say no.)