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 ab379795 for ; Fri, 29 Jun 2018 12:59:08 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 7D905A1B15; Fri, 29 Jun 2018 22:59:07 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 80D86A181B; Fri, 29 Jun 2018 22:58:55 +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=WYRKr5Rd; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 81D05A181B; Fri, 29 Jun 2018 22:58:53 +1000 (AEST) Received: from imap.thunk.org (imap.thunk.org [74.207.234.97]) by minnie.tuhs.org (Postfix) with ESMTPS id 3939AA1815 for ; Fri, 29 Jun 2018 22:58:52 +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=aVZhNtqBbfGih1QCLcVihl6FW7y+H/piPDiblM0gc6I=; b=WYRKr5RdSc74s7PG4N4jubKF2O LmcoiGoMU1KA7ZTqJs9xu/QacHbGSvz+y2KgwbC2xHC0IhmLlvBfAABSG3tM/N8ZrIzui2sb0YWqY 9xgRFk0ps2z062pCs5HPnmz6+fjghdOZDZHdx+/k6gBP9obzwe2A9r7td45ZOmjoXRmk=; Received: from root (helo=callcc.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.89) (envelope-from ) id 1fYszB-0005oH-RW; Fri, 29 Jun 2018 12:58:49 +0000 Received: by callcc.thunk.org (Postfix, from userid 15806) id BFEA97A4481; Fri, 29 Jun 2018 08:58:48 -0400 (EDT) Date: Fri, 29 Jun 2018 08:58:48 -0400 From: "Theodore Y. Ts'o" To: Bakul Shah Message-ID: <20180629125848.GD1231@thunk.org> References: <81277CC3-3C4A-49B8-8720-CFAD22BB28F8@bitblocks.com> <20180628141538.GB663@thunk.org> <20180629020219.1AAB4156E517@mail.bitblocks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180629020219.1AAB4156E517@mail.bitblocks.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 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 Thu, Jun 28, 2018 at 07:02:11PM -0700, Bakul Shah wrote: > 3. As Perry said, we are using parallel and distributed > computing more and more. Even the RaspberryPi Zero has a > several times more powerful GPU than its puny ARM "cpu"! > Most all cloud services use multiple cores & nodes. We may > not set up our services but we certainly use quite a few of > them via the Internet. Even on my laptop at present there > are 555 processes and 2998 threads. Most of these are > indeed "embarrassingly" parallel -- most of them don't talk > to each other! In order to think clearly about the problem, it's important to distingish between parallel and distributed computing. Parallel computing to me means that you have a large number of CPU-bound threads that are all working on the same problem. What is mean by "the same problem" is tricky, and we need to distinguish between stupid ways of breaking up the work --- for example, in Service Oriented Architectures, you might do an RPC call to multiple a dollar value by 1.05 to calculate the sales tax --- sure, you can call that "distributed" computing, or even "parallel" computing because it's a different thread (even if it is I/O bound waiting for the next RPC call, and most of the CPU power is spent marshalling and unmarshalling the parmeter and return values). But it's a __dumb__ way of breaking up the problem. At least, unless the problem is to sell lots of extra IBM hardware and make IBM shareholders lots of money, in which case, it's brilliant. :-) It's also important to distinguish between CPU-bound and I/O-bound threads. You may have 2998 threads, and but I bet they are mostly I/O bound, and are there for programmer convenience. Very often such threads are not actually a terribly efficent way to break up the problem. In my career, where the number of threads are significantly greater than the number of CPU's, you can actually make a tradeoff between programmer convenience and CPU efficiency by taking those hundreds of threads, and transforming PC and a small state structure into something that is much more of a continuation-based implementation which uses significantly fewer threads. That particular architecture still had cores that were mostly I/O bound, but it meant we could use significantly cheaper CPU's, and it saved millions and millions of dollars. All of this is to point out that talking about 2998 threads really doesn't mean much. We shouldn't be talking about threads; we should be talking about how many CPU cores can we usefully keep busy at the same time. Most of the time, for desktops and laptops, except for brief moments when you are running "make -j32" (and that's only for us weird programmer-types; we aren't actually the common case), most of the time, the user-facing CPU is twiddling its fingers. > 4. The reason most people prefer to use one very high perf. > CPU rather than a bunch of "wimpy" processors is *because* > most of our tooling uses only sequential languages with > very little concurrency. The problem is that I've been hearing this excuse for two decades. And there have been people who have been working on this problem. And at this point, there's been a bit of "parallelism winter" that is much like the "AI winter" in the 80's. Lots of people have been promisng wonderful results for a long time; Sun bet their company (and lost) on it; and there haven't been much in the way of results. Sure, there are specialized cases where this has been useful --- making better nuclear bumbs with which to kill ourselves, predicting the weather, etc. But for the most part, there haven't been much improvement for anything other than super-specialzied use cases. Machine learning might be another area, but that's one where we're seeing specialied chips that are doing one thing and exactly one thing. Whether it's running a nueral network, or doing AES encryption in-line, this is not an example of better parllel programming languages or better software tooling. > 5. You may well be right that most people don't need faster > machines. Or that machines optimized for parallel languages > and codes may never succeed commercially. > > But as a techie I am more interested in what can be built > (as opposed to what will sell). It is not a question of > whether problems amenable to parallel solutions are the > *only problems that matter*. If we can build something which is useful, the money will take care of itself. That means generally useful. The market of weather prediction or people interested in building better nuclear bombs is fairly small compared to the entire computing market. As a techie, what I am interested in is building something that is useful. But part of being useful is that it has to make economic sense. That problably makes me a lousy acdemic, but I'm a cynical industry engineer, not an academic. > 6. The conventional wisdom is parallel languages are a failure > and parallel programming is *hard*. Hoare's CSP and > Dijkstra's "elephants made out of mosquitos" papers are > over 40 years old. It's a failure because there hasn't been *results*. There are parallel languages that have been proposed by academics --- I just don't think they are any good, and they certainly haven't proven themselves to end-users. > We are doing adhoc distributed systems but we > don't have a theory as to how they behave under stress. > But see also [1] Actually, there are plenty of people at the hyper-scaler cloud companies (e.g., Amazon, Facebook, Google, etc.) who understand very well how they behave under stress. Many of these companies regularly experiment with putting their systems under stress to see how they behave. More importantly, they will concoct full-blown scenarios (sometimes with amusing back-stories such as extra-dimensional aliens attacking Moffet Field) to test how *humans* and their *processes* manging these large-scale distributed systems react under stress. > Here is a somewhat tenuous justification for why this topic does > make sense on this list: Unix provides *composable* tools. How many of these cases were these composable tools actually ones where it allowed CPU resources to be used more efficiently? A pipeline that involves sort, awk, sed, etc. certainly is better because you didn't have to write an ad-hoc program. And i've written lots of Unix pipelines in my time. But in how many cases were these pipelines actually CPU bound. I think if you were to examine the picture closely, they all tended to be I/O bound, not CPU bound. So while Unix tools' composability is very good thing, I would question whether they have proven to be a useful tool in terms of being able to use computational resources more efficiently, and how much they really leveraged computational parllelism. - Ted