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.8 required=5.0 tests=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 49a6a9f2 for ; Fri, 29 Jun 2018 16:09:59 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 6EBC4A188C; Sat, 30 Jun 2018 02:09:58 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 8B9C7A181B; Sat, 30 Jun 2018 02:09:46 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id E6EDAA181B; Sat, 30 Jun 2018 02:09:43 +1000 (AEST) Received: from hacklheber.piermont.com (hacklheber.piermont.com [166.84.7.14]) by minnie.tuhs.org (Postfix) with ESMTPS id 4EFCAA1815 for ; Sat, 30 Jun 2018 02:09:43 +1000 (AEST) Received: from snark.cb.piermont.com (localhost [127.0.0.1]) by hacklheber.piermont.com (Postfix) with ESMTP id A566C217; Fri, 29 Jun 2018 12:09:42 -0400 (EDT) Received: from jabberwock.cb.piermont.com (jabberwock.cb.piermont.com [10.160.2.107]) by snark.cb.piermont.com (Postfix) with ESMTP id 885B62DED80; Fri, 29 Jun 2018 12:09:42 -0400 (EDT) Date: Fri, 29 Jun 2018 12:09:42 -0400 From: "Perry E. Metzger" To: tfb@tfeb.org Message-ID: <20180629120942.6cd4b67d@jabberwock.cb.piermont.com> In-Reply-To: <8881414B-FF5C-4BD9-B518-AD22366DE4BC@tfeb.org> References: <81277CC3-3C4A-49B8-8720-CFAD22BB28F8@bitblocks.com> <20180628141538.GB663@thunk.org> <20180628144017.GB21688@mcvoy.com> <20180628105538.65f82615@jabberwock.cb.piermont.com> <20180628145825.GE21688@mcvoy.com> <2B710879-7659-47A4-AA86-03F232F7B78B@tfeb.org> <20180628160202.GF21688@mcvoy.com> <79022674-0FFA-4B1B-8A27-4C403D51540E@tfeb.org> <20180628170955.GH21688@mcvoy.com> <8881414B-FF5C-4BD9-B518-AD22366DE4BC@tfeb.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: , Cc: tuhs@minnie.tuhs.org Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On Fri, 29 Jun 2018 16:32:59 +0100 tfb@tfeb.org wrote: > On 28 Jun 2018, at 18:09, Larry McVoy wrote: > > > > I'm not sure how people keep missing the original point. Which > > was: the market won't choose a bunch of wimpy cpus when it can > > get faster ones. It wasn't about the physics (which I'm not > > arguing with), it was about a choice between lots of wimpy cpus > > and a smaller number of fast cpus. The market wants the latter, > > as Ted said, Sun bet heavily on the former and is no more. > > [I said I wouldn't reply more: I'm weak.] > > I think we have been talking at cross-purposes, which is probably > my fault. I think you've been using 'wimpy' to mean 'intentionally > slower than they could be' while I have been using it to mean 'of > very tiny computational power compared to the power of the whole > system'. Your usage is probably more correct in terms of the way > the term has been used historically. > > But I think my usage tells you something important: that the > performance of individual cores will, inevitably, become > increasingly tiny compared to the performance of the system they > are in, and will almost certainly become asymptotically constant > (ie however much money you spend on an individual core it will not > be very much faster than the one you can buy off-the-shelf). You've touched the point with a needle. This is exactly what I was getting at. It's not a question of whether you want a better single CPU or not, they don't exist, and one CPU is a tiny fraction of the power in a modern distributed or parallel system. > So, if you want to keep seeing performance improvements (especially > if you want to keep seeing exponential improvements for any > significant time), then you have no choice but to start thinking > about parallelism. > > The place I work now is an example of this. Our machines have the > fastest cores we could get. But we need nearly half a million of > them to do the work we want to do (this is across three systems). And that's been the case for a long time now. Supercomputers are all giant arrays of CPUs, there hasn't been a world-beating single core supercomputer in decades. > I certainly don't want to argue that choosing intentionally slower > cores than you can get is a good idea in general (although there > are cases where it may be, including, perhaps, some HPC workloads). And anything where power usage is key. If you're doing something that computationally requires top-end single core performance you run the 4GHz core. Otherwise, you save a boatload of power and also _cooling_ by going a touch slower. Dynamic power rises as the square of the clock rate so you get quite a lot out of backing off just a bit. But it doesn't matter much even if you want to run flat out, because no single processor can do what you want any more. There's a serious limit to how much money you can throw at the vendors to give you a faster core, and it tops out (per core) at a lot less than you're paying your top engineers per day. > However let me add something about the Sun T-series machines, which > were 'wimpy cores' in the 'intentionally slower' sense. When these > started appearing I worked in a canonical Sun customer at the time: > a big retail bank. And the reason we did not buy lots of them was > nothing to do with how fast they were (which was more than fast > enough), it was because Sun's software was inadequate. Your memory of this is the same as mine. I was also consulting to quite similar customers at the time (most of my career has been consulting to large investment banks. Haven't done much on the retail side though that's changed in recent years.) > (As an addentum: what eventually happened / is happening I think is > that applications are getting recertified on Linux/x86 sitting on > top of ESX, *which can move VMs live between hosts*, thus solving > the problem.) At the investment banks, the appetite for new Sun hardware when cheap Linux on Intel was available was just not there. As you noted, too many eggs in one basket was one problem, but another was the combination of better control on an open source OS and just plain cheaper and (by then sometimes even nicer) hardware. Sun seemed to get fat in the .com bubble when people were throwing money at their stuff like crazy, and never quite adjusted to the fact that the world was changing and people wanted lots of cheap boxes more than they wanted a few expensive ones. Perry -- Perry E. Metzger perry@piermont.com