Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp2768254ybl; Sun, 8 Dec 2019 00:10:59 -0800 (PST) X-Google-Smtp-Source: APXvYqxI6Es4DUPQZYul2pU4KE24pKFZZHbPckqKSnEosRt3Hnm7LgpZMc3qw0adDCdzbrblScFs X-Received: by 2002:a05:6830:148d:: with SMTP id s13mr18164391otq.323.1575792659928; Sun, 08 Dec 2019 00:10:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575792659; cv=none; d=google.com; s=arc-20160816; b=AscM9C6tGvkkO99ez0Oh71wzpQ1eMqx5LyGadhvhVDl6WLonPofKtlljfLxY9GF9FY jL2ks+jSh40UJ55brot1BQcX822aIt3z6Bz0bl2NPeS57r1bDFrJg/s3bMnbFst83DJH in73BXiKuonVDd7PnLawYiVgiK9toXXIJFO8XdqqxIRAvCXN6ydpcdkwcuF4MBuTXCEO 1U0gDcwGZEsiwgibPAzNxFbSZD0wFSATO2rZgQ5QNMbGNIfvFdwhGsRM9bKcr+EZtSSV 7OVOPCni5CZBtwkuRYx/thPTpfeIxIjLjP1pL14PvJiEYLs2cfamPPQAZVJpwZJopfrj GJ8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:cc:subject:to :message-id:from:date; bh=Tx+JHZO4HZAtA28hkWsEuqM+mrVJEEZXmhYVQgdLsQU=; b=wQ8r7S6oIQsWMl3Wp6WA0sNmq4v+7XuuTm4wtnv40QNdFBqR0RD/E+vRCuLwKb2D4R 7mlCV8/rRQuCqJ3db8EftXdnDcD8ZXbUvBjUez2Dc+pQP7r2cPRTjD3vdipZHfttXT+N laM5pT9R4gnJSYBAhsnz0OgR3ynecWHe2G05QOePw8Q/kEtI2laAFvDf7R0Oezwnte79 uKliHYWzVE/5aEzI3U5jwaO0Ep3y1ZrqDXUoA6k9Q2Oagu/wyNL0SNnL4Wi8hZionpqI FKPtnD/Ofas1dF04ZVpewK3pv94Zs6sii/KmaxclA0XWWMrXud97Q3kkXsE4mJPUIwRO R1yw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d206si8846189oif.203.2019.12.08.00.10.16; Sun, 08 Dec 2019 00:10:59 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726001AbfLHIH2 (ORCPT + 99 others); Sun, 8 Dec 2019 03:07:28 -0500 Received: from mx.sdf.org ([205.166.94.20]:54683 "EHLO mx.sdf.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725815AbfLHIH2 (ORCPT ); Sun, 8 Dec 2019 03:07:28 -0500 X-Greylist: delayed 325 seconds by postgrey-1.27 at vger.kernel.org; Sun, 08 Dec 2019 03:07:27 EST Received: from sdf.org (IDENT:lkml@sdf.lonestar.org [205.166.94.16]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id xB881T8t023432 (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits) verified NO); Sun, 8 Dec 2019 08:01:29 GMT Received: (from lkml@localhost) by sdf.org (8.15.2/8.12.8/Submit) id xB881RO2001774; Sun, 8 Dec 2019 08:01:27 GMT Date: Sun, 8 Dec 2019 08:01:27 GMT From: George Spelvin Message-Id: <201912080801.xB881RO2001774@sdf.org> To: linux-kernel@vger.kernel.org, linux@rasmusvillemoes.dk, lkml@sdf.org Subject: Re: [PATCH 5/5] lib/list_sort: Optimize number of calls to comparison function Cc: akpm@linux-foundation.org, andriy.shevchenko@linux.intel.com, daniel.wagner@siemens.com, dchinner@redhat.com, don.mullis@gmail.com, geert@linux-m68k.org, st5pub@yandex.ru In-Reply-To: References: , , , <201903140158.x2E1wgFQ018649@sdf.org>, Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 22 Jun 2019 at 01:12:01, Rasmus Villemoes wrote: > On 14/03/2019 02.58, George Spelvin wrote: >> On Thu, 14 Mar 2019 at 00:28:16 +0100, Rasmus Villemoes wrote: > >>> Similarly one could do a SORT_SIMPLE_CMP() for when sorting an array of >>> structs according to a single numeric member. That sort is not stable, >>> so the comparison functions would have to do a full -1,0,1 return, of >>> course, but we'd still avoid indirect calls. >> >> Actually, while some sorts (notably fat-pivot quicksort) require >> a 3-way return to avoid O(n^2) performance, heapsort is just fine >> with a boolean return value. > > Hi George > > So I tried starting to implement this, and the timing results look > promising. However, currently I'm doing > > (*(u32*)ka > *(u32*)kb) - (*(u32*)ka < *(u32*)kb); > > in my do_cmp. Both existing invocations of the comparison function in > sort.c compare its return value >= 0, which is always true if I just > return the boolean (*(u32*)ka > *(u32*)kb). So it seems the algorithm > would have to be changed to allow the cmp function to return a bool. > Perhaps it's as simple as changing the two >= to >, but can I get you to > check that that would be ok? (Quick testing seems to suggest so, but > it's possible there are some corner cases where it would break.) The only reason for >= vs. > is to do less work in the == case. (I prefer to stay in the first backtracking loop, which does no data motion, and therby reduce the number of swaps performed in the second part of the backtracking.) If you want to preserve the logic exactly, you can replace "do_cmp(a, b, ...) >= 0" with "do_cmp(b, a, ...) <= 0" and then the conversion is straightforward.