From owner-freebsd-current@FreeBSD.ORG Sun Jun 5 01:36:34 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 778E316A41C for ; Sun, 5 Jun 2005 01:36:34 +0000 (GMT) (envelope-from matt@gsicomp.on.ca) Received: from skippyii.compar.com (compar.com [216.208.38.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A1D043D48 for ; Sun, 5 Jun 2005 01:36:33 +0000 (GMT) (envelope-from matt@gsicomp.on.ca) Received: from hermes (CPE00062566c7bb-CM000039c69a66.cpe.net.cable.rogers.com [69.193.82.185]) by skippyii.compar.com (8.13.1/8.13.1) with ESMTP id j551lMIF033303; Sat, 4 Jun 2005 21:47:23 -0400 (EDT) (envelope-from matt@gsicomp.on.ca) Message-ID: <000701c5696f$0dee3b10$1200a8c0@gsicomp.on.ca> From: "Matt Emmerton" To: "Martin" , References: <42A242D1.4000002@nurfuerspam.de> Date: Sat, 4 Jun 2005 21:36:53 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Cc: Subject: Re: Optimizing libc/string for amd64(?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2005 01:36:34 -0000 > Hello, > > I ran nbench on different workstations and noticed that > amd64-platform is really bad when doing "STRINGSORT". > > Sempron 2200+ (i386) : 88 iterations/second > Athlon64 3000+ (amd64): 32.15 iterations/second > > I looked inside nbench and it seems to call memmove > very often. This is OK, in my opinion, so I investigated > further. > > I've just looked inside libc how memmove/memcpy is > handled there. The function is inside bcopy.c. > I noticed that the "word" which is used for copying > has the size of "int". > > Wouldn't it be better to set it to "typedef long word"? > OpenBSD is using "long" there, for example, as I noticed > later. > > I don't have amd64 at home, so I cannot really test > everything out. Can someone of you take a look at the > code in libc/string? There are various places that are > using "int" instead of "long", e.g. also in memset-code. It would probably be better to use int64_t and int32_t instead of long/int, in order to make the intention more obvious. -- Matt Emmerton