From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S265950AbTL3US3 (ORCPT ); Tue, 30 Dec 2003 15:18:29 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S265948AbTL3US2 (ORCPT ); Tue, 30 Dec 2003 15:18:28 -0500 Received: from neon-gw-l3.transmeta.com ([63.209.4.196]:46863 "EHLO neon-gw.transmeta.com") by vger.kernel.org with ESMTP id S265923AbTL3USJ (ORCPT ); Tue, 30 Dec 2003 15:18:09 -0500 To: linux-kernel@vger.kernel.org From: "H. Peter Anvin" Subject: Re: [PATCH] optimize ia32 memmove Date: 30 Dec 2003 12:17:59 -0800 Organization: Transmeta Corporation, Santa Clara CA Message-ID: References: <200312300713.hBU7DGC4024213@hera.kernel.org> <1072779479.16344.95.camel@ixodes.goop.org> <3FF15DAB.8080203@colorfullife.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Disclaimer: Not speaking for Transmeta in any way, shape, or form. Copyright: Copyright 2003 H. Peter Anvin - All Rights Reserved Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Followup to: <3FF15DAB.8080203@colorfullife.com> By author: Manfred Spraul In newsgroup: linux.dev.kernel > > AMD recommends to perform bulk copies backwards: That defeats the hw > prefecher, and results in even better access patterns. Doesn't matter in > this case, memmove is never used for bulk copies. > That's also a microoptimization for one particular microarchitecture *bug*. Hardware prefetchers are going omnidirectional going forward. Additionally, nearly all bulk copies are performed forward (DF=0) in existing codebases. -hpa -- at work, in private! If you send me mail in HTML format I will assume it's spam. "Unix gives you enough rope to shoot yourself in the foot." Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64