Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261188AbVAWCjj (ORCPT ); Sat, 22 Jan 2005 21:39:39 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261189AbVAWCji (ORCPT ); Sat, 22 Jan 2005 21:39:38 -0500 Received: from one.firstfloor.org ([213.235.205.2]:17879 "EHLO one.firstfloor.org") by vger.kernel.org with ESMTP id S261188AbVAWCjh (ORCPT ); Sat, 22 Jan 2005 21:39:37 -0500 To: Felipe Alfaro Solana Cc: Trond Myklebust , linux-kernel@vger.kernel.org, Buck Huppmann , Neil Brown , Andreas Gruenbacher , "Andries E. Brouwer" , Andrew Morton , Olaf Kirch Subject: Re: [patch 1/13] Qsort References: <20050122203326.402087000@blunzn.suse.de> <20050122203618.962749000@blunzn.suse.de> From: Andi Kleen Date: Sun, 23 Jan 2005 03:39:34 +0100 In-Reply-To: (Felipe Alfaro Solana's message of "Sun, 23 Jan 2005 03:03:32 +0100") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 806 Lines: 19 Felipe Alfaro Solana writes: > > AFAIK, XOR is quite expensive on IA32 when compared to simple MOV > operatings. Also, since the original patch uses 3 MOVs to perform the > swapping, and your version uses 3 XOR operations, I don't see any > gains. Both are one cycle latency for register<->register on all x86 cores I've looked at. What makes you think differently? -Andi (who thinks the glibc qsort is vast overkill for kernel purposes where there are only small data sets and it would be better to use a simpler one optimized for code size) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/