From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: tuhs-bounces@minnie.tuhs.org X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE, T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id c70fd6cb for ; Wed, 27 Jun 2018 02:45:22 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id C2E29A18AD; Wed, 27 Jun 2018 12:45:20 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 0C358A181A; Wed, 27 Jun 2018 12:44:57 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=thunk.org header.i=@thunk.org header.b=sn6PX6Qb; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id A33A1A181F; Wed, 27 Jun 2018 12:44:55 +1000 (AEST) X-Greylist: delayed 1567 seconds by postgrey-1.35 at minnie.tuhs.org; Wed, 27 Jun 2018 12:44:54 AEST Received: from imap.thunk.org (imap.thunk.org [74.207.234.97]) by minnie.tuhs.org (Postfix) with ESMTPS id 8B6529EDF1 for ; Wed, 27 Jun 2018 12:44:54 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=dJEFAhxLvGuSB/NrWrSX+wkxj2G8SZDDn3dOWGGgNvM=; b=sn6PX6QbsBqcpMymnMFWt/XF4f rmgMmkipfNHb+mX0xBjLn7H7f6C2CGkP6VI4jiFlX/a3L075KttwMYzsS9ZbgM5jO2z1zfUcFDdBS a8HyTpEq1LWhWBCgKWbhUu+pqPPp3dcgzddLsnYQmh8Qh4GAS/LRGcJlLLkUB8TvF/Vw=; Received: from root (helo=callcc.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.89) (envelope-from ) id 1fY02e-0005qb-Af; Wed, 27 Jun 2018 02:18:44 +0000 Received: by callcc.thunk.org (Postfix, from userid 15806) id 460B07A4480; Tue, 26 Jun 2018 22:18:43 -0400 (EDT) Date: Tue, 26 Jun 2018 22:18:43 -0400 From: "Theodore Y. Ts'o" To: Larry McVoy Message-ID: <20180627021843.GA31920@thunk.org> References: <1f8043fd-e8d6-a5e6-5849-022d1a41f5bf@kilonet.net> <20180626215012.GE8150@mcvoy.com> <20180626215905.GH8150@mcvoy.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180626215905.GH8150@mcvoy.com> User-Agent: Mutt/1.10.0 (2018-05-17) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Subject: Re: [TUHS] PDP-11 legacy, C, and modern architectTures X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: tuhs@minnie.tuhs.org Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" One of the things which is probably causing a lot of hang ups is the phrase "low-level language". What is exactly meant by that? The article actually uses multiple definitions of "low-level language", and switches between them when it is convenient, or as a rhetorical trick. There is at least one of his points that I very much agree with, which is the abstract model which is exported by the C programming paradigm is very different from what totality of what the CPU can do. Consider the oft-made admonition that most humans can't program in assembler more efficiently than the compiler. Think about that for a moment. That saying is essentially telling us that the compiler is capable of doing a lot of things behinds our back (which goes against the common understanding of what low-level language does), and second, that modern CPU's has gotten too complicated for most humans to be able to program directly, either comfortably or practically. Also, all of these compiler optimizations are not _mandatory_. They are there because people really want performance. You are free to disable them if you care about predictability and avoiding the "any sufficiently advanced compiler is indistinguishable from a malicious adversary" dynamic. In fact, if are writing a program where you are, more often than not, I/O bound and/or fundamentally bound by memory bandwidth, turning off a lot of these compiler optimizations might be the right thing to do, as they may not buy you much, and given you much in the way of headaches. There is a reason why the Linux kernel compiles with the GCC flags: -fno-asynchronous-unwind-tables -fno-delete-null-pointer-checks \ -fstack-protector-strong -fno-var-tracking-assignments \ -femit-struct-debug-baseonly -fno-var-tracking \ -fno-inline-functions-called-once -fno-strict-overflow \ -fno-merge-all-constants -fmerge-constants -fno-stack-check By the way, I disagree with Chisnall's assertion that low-level languages are fast. If you believe that compilers can often do a better job than humansh writing assembly, does that mean that since assembly code isn't fast that it's not a low-level language?) And the performance wars is an important part of dynamic --- at the end of the day, the vast majority of people choose performance as the most important driver of their purchasing decision. They may pay lip service to other things, including security, robustness, etc., but if you take a look at what they actually _do_, far more often than not, they choose fast over slow. I see this an awful lot in file system design. People *talk* a great game about how they care about atomicity, and durability, etc., but when you look at their actual behavior as opposed to expressed desires, more often than not what they choose is again, fast over slow. And so I have an extension to the fictional dialog to Pillai's presentation for his 2014 OSDI paper: Experienced Academic: Real file systems don't do that. But <...> does just that. Academic: My students would flunk class if they built a file system that way. Cynical Industry Developer's rejoinder: A file system designed the way you propose would likely be a commercial failure, and if it was the only/default FS for an OS, would probably drag the OS down to failure with it. And this goes to Spectre, Meltdown, TLBleed, and so on. Intel built processors this way because the market _demanded_ it. It's for the same reason that Ford Motor Company built gas-guzzling pickup trucks. Whether or not Maimi Beach will end up drowning under rising sea levels never entered into the the consumer or the manufacturer's consideration, at least not in any real way. It's very easy to criticize Intel for engineering their CPU's the way they did, but if you want to know who to blame for massively high ILP's and caching, and compilers that do all sorts of re-ordering and loop rewriting behind the developer's back, just look in the mirror. It's the same as why we have climate change and sea level rise. "We have met the enemy and he is us". -- Pogo (Walt Kelly) - Ted