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=FROM_EXCESS_BASE64, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE 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 795610fe for ; Fri, 29 Jun 2018 06:08:09 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 1E57CA1877; Fri, 29 Jun 2018 16:08:08 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id E80DBA182F; Fri, 29 Jun 2018 16:07:30 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 54E05A182F; Fri, 29 Jun 2018 16:07:27 +1000 (AEST) X-Greylist: delayed 540 seconds by postgrey-1.35 at minnie.tuhs.org; Fri, 29 Jun 2018 16:07:26 AEST Received: from ste-pvt-msa2.bahnhof.se (ste-pvt-msa2.bahnhof.se [213.80.101.71]) by minnie.tuhs.org (Postfix) with ESMTPS id C16C5A1815 for ; Fri, 29 Jun 2018 16:07:26 +1000 (AEST) Received: from localhost (localhost [127.0.0.1]) by ste-pvt-msa2.bahnhof.se (Postfix) with ESMTP id 7A2953F8EF for ; Fri, 29 Jun 2018 07:58:24 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at bahnhof.se Received: from ste-pvt-msa2.bahnhof.se ([127.0.0.1]) by localhost (ste-ftg-msa2.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pO9oRPKAd3a0 for ; Fri, 29 Jun 2018 07:58:20 +0200 (CEST) Received: from h-174-65.A328.priv.bahnhof.se (h-174-65.A328.priv.bahnhof.se [81.170.174.65]) (Authenticated sender: mc179410) by ste-pvt-msa2.bahnhof.se (Postfix) with ESMTPA id 338D83F8EC for ; Fri, 29 Jun 2018 07:58:19 +0200 (CEST) Received: from h-174-65.A328.priv.bahnhof.se (localhost [127.0.0.1]) by h-174-65.A328.priv.bahnhof.se (Postfix) with ESMTPS id 8DFEB96A for ; Fri, 29 Jun 2018 07:58:19 +0200 (CEST) Date: Fri, 29 Jun 2018 05:58:18 +0000 From: Michael =?utf-8?B?S2rDtnJsaW5n?= To: tuhs@minnie.tuhs.org Message-ID: <20180629055818.GR29822@h-174-65.A328.priv.bahnhof.se> References: <81277CC3-3C4A-49B8-8720-CFAD22BB28F8@bitblocks.com> <20180628141538.GB663@thunk.org> <20180628104329.754d2c19@jabberwock.cb.piermont.com> <20180628145609.GD21688@mcvoy.com> <20180628154246.3a1ce74a@jabberwock.cb.piermont.com> <20180628170317.14d65067@jabberwock.cb.piermont.com> <20180628222954.GD8521@thunk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180628222954.GD8521@thunk.org> Subject: Re: [TUHS] PDP-11 legacy, C, and modern architectures 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: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On 28 Jun 2018 18:29 -0400, from tytso@mit.edu (Theodore Y. Ts'o): > And if you are really worried about potential > problems with Spectre and Meltdown, what that means is that sharing > caches is perilous. So if you have 128 wimpy cores, you need 128 > separate I and D cacaches. If you have 32 stronger cores, you need 32 > separate I and D caches. What's more, I suspect that in order to get good performance out of those wimpy cores, you'd rather need _more_ cache per core, than less or the same, simply because there's less of an advantage in raw clock. One doesn't have to look hard to find examples of where adding or increasing cache in a CPU (these days on-die) have, at least for workloads that are able to use such cache effectively, led to huge improvements in overall performance, even at similar clock rates. Of course, I can't help but find it interesting that we're having this discussion at all about a language that is approaching 50 years old by now (Wikipedia puts the earliest design in 1969, which sounds about right, and even K&R C is 40 years old by now). Sure, C has evolved -- for example, C11 added language constructs for multithreaded programming, including the _Thread_local storage class specifier) -- but it's still in active use and it's still recognizably an evolved version of the language specified in K&R. I can pull out the manual for a pre-ANSI C compiler and look at the code samples, and sure there are things about that code that a modern compiler barfs at, but it's quite easy to just move a few things around a little and end up with pretty close to modern C (albeit code that doesn't take advantage of new features, obviously). I wonder how many of today's programming languages we'll be able to say the same thing about in 2040-2050-ish. -- Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se “The most dangerous thought that you can have as a creative person is to think you know what you’re doing.” (Bret Victor)