From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 5d0fbfda for ; Mon, 13 Jan 2020 00:31:45 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 047AA9BD96; Mon, 13 Jan 2020 10:31:44 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 36C029BD0F; Mon, 13 Jan 2020 10:31:17 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 762B39BD0F; Mon, 13 Jan 2020 10:31:13 +1000 (AEST) Received: from fourwinds.com (fourwinds.com [63.64.179.162]) by minnie.tuhs.org (Postfix) with ESMTPS id 41A3C9BCA8 for ; Mon, 13 Jan 2020 10:31:12 +1000 (AEST) Received: from darkstar.fourwinds.com (localhost [127.0.0.1]) by fourwinds.com (8.15.2/8.15.2) with ESMTPS id 00D0VAL1613945 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT) for ; Sun, 12 Jan 2020 16:31:10 -0800 Received: from darkstar.fourwinds.com (jon@localhost) by darkstar.fourwinds.com (8.15.2/8.15.2/Submit) with ESMTP id 00D0VAuW613942 for ; Sun, 12 Jan 2020 16:31:10 -0800 Message-Id: <202001130031.00D0VAuW613942@darkstar.fourwinds.com> From: Jon Steinhart To: The Eunuchs Hysterical Society In-reply-to: <20200113002219.GJ9174@mcvoy.com> References: <202001122225.00CMPc9S085970@tahoe.cs.Dartmouth.EDU> <202001122340.00CNeef0604557@darkstar.fourwinds.com> <20200112235051.GG9174@mcvoy.com> <202001130001.00D012bC608441@darkstar.fourwinds.com> <20200113002219.GJ9174@mcvoy.com> Comments: In-reply-to Larry McVoy message dated "Sun, 12 Jan 2020 16:22:19 -0800." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <613940.1578875470.1@darkstar.fourwinds.com> Date: Sun, 12 Jan 2020 16:31:10 -0800 X-JON-SPAM: local delivery Subject: Re: [TUHS] Tech Sq elevator [ really type-checking ] 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: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" Larry McVoy writes: > On Sun, Jan 12, 2020 at 04:01:02PM -0800, Jon Steinhart wrote: > > Larry McVoy writes: > > > On Sun, Jan 12, 2020 at 03:40:40PM -0800, Jon Steinhart wrote: > > > > Linux contains several sets of list_for_each_entry() macros that are essentially > > > > obfuscated for loops that generate inefficient code. > > > > > > Very common idiom in any real system. BitKeeper has them as well, they are > > > used everywhere. They are too useful to not use. The BitKeeper ones give > > > you most of Perl's list capabilities. > > > > I don't see it. In the cases that I've seen so far in linux the only uses are > > inserting, deleting, and traversing lists. My opinion that anyone who can't > > write > > for (p = list; p != NULL; p = p->next) > > > > shouldn't be programming, much less in the kernel. To me, type-checking and > > code clarity are vastly more important. If I want to program in Perl, I do > > so. When I program in C that's what I do. > > > > I do want to be clear that I'm coming at this from a code maintenance angle. > > I'd argue that the code we wrote for BitKeeper would hold up as some > of the most professionally written code ever. Every commit was peer > reviewed by at least 2 other people, code that add/changed/deleted user > interfaces had to have docs and tests. The philosophy is very much in > line with code maintenance, I vetoed stuff that was clever, my mantra was > "write once, read many so optimize for read". > > Some dude on twitter found our code when we open sourced it and tweeted > something like "Wow, I've just spent the afternoon reading some of the > best written C code I've ever seen. I didn't know C could be that nice". > So it's not just my opinion, I don't know that dude. > > The list code that we have is super pleasant to use and has been > in production use for over 2 decades. And we maintained it easily, > our 24x7 *average* responsive time on a bug report was 24 minutes. > The only reason it was that high was because we had to sleep (we were > spread out from East to West coast). During working hours, response time > was almost always under 10 minutes, usually 2-3 minutes. By "response", > I don't mean some automated nonsense that says "We value your input, > this is to let you know your report has been entered into our system". > I mean an engineer looked at the problem, figured out what was causing the > problem by looking at our source, about 90% of the time we knew what the > fix was, and we sent an update to the bug report with that information. > > The list structure was auto resizing, it knew both how much was allocated > and how much was used in the first word of the list (we resized only in > powers of 2 so we could store size in log2 bits, used the rest of the > bits for the length), you could have a list in as short as two words > and it scaled really well to millions of entries. > > It was, and is, super useful. Wayne is back at Intel and he's teasing > it out of our libc to use there. > > So you may not like it but that's you. It has worked well in an extremely > professional environment. Well coding professional, personalities might > have been a bit wonky :) I was commenting on what I found in the linux kernel. Your code and list interface may be better. Jon