From owner-freebsd-chat@FreeBSD.ORG Wed Oct 29 15:56:56 2003 Return-Path: Delivered-To: freebsd-chat@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6687F16A4CE for ; Wed, 29 Oct 2003 15:56:56 -0800 (PST) Received: from mta4.adelphia.net (mta4.adelphia.net [68.168.78.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BF7243F75 for ; Wed, 29 Oct 2003 15:56:54 -0800 (PST) (envelope-from wmoran@potentialtech.com) Received: from potentialtech.com ([68.68.113.33]) by mta4.adelphia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20031029235655.YOVL16324.mta4.adelphia.net@potentialtech.com>; Wed, 29 Oct 2003 18:56:55 -0500 Message-ID: <3FA053B3.20708@potentialtech.com> Date: Wed, 29 Oct 2003 18:56:35 -0500 From: Bill Moran User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Schwartz References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: "Chat@Freebsd. Org" Subject: Re: How much better are 64 but platforms X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2003 23:56:56 -0000 David Schwartz wrote: >>I've never used FreeBSD on a 64 bit platform, and with a recent >>project I've got >>a client asking me, "How much faster would this run if we put it >>on an Itanium." >> >>So, in the future, I'll probably be getting a 64 bit machine to >>try this out on. >> >>But it got me thinking, what should I _expect_ to see in >>improvement? This >>application is mostly comparing strings, there are no 64 bit >>integers or floats >>to be obvious bottlenecks on a 32 bit platform, so (lacking >>actual experience) >>how much can I expect the application to speed up if I move it to a 64 bit >>platform? > > Applications that primarily manipulate strings are not faster on 64-bit > platforms and, in some cases, run more slowly. We suspect this is because, > in relative terms, single byte accesses are more expensive. I was wondering about that, specifically. I guess it depends on how the compiler does things. If it could do strcmp() 64 bits (8 bytes) at a time, it could probably be faster, but I don't know how feasable that is with regard to string operations. Perhaps there's a way to optimize my code by casting strings as 64 bit integers and comparing them. Hopefully I'll get a chance to try that theory out. Of course, strings longer than 8 bytes will have to be compared 8 bytes at a time, but in this particular case, the strings should never be that long anyway. Hmmm ... > Applications that manipulate small integers (that fit in 32-bits) generally > run at about the same speed. We do see slight slowdowns simply because of > extra memory bandwidth being used due to 64-bits values taking twice as much > space on the bus as 32. Applications that deal with large numbers (like > cryptography) or bulk data (like compression) tend to get a boost. Database > applications generally do get a performance boost because of the better > ability to deal with large amounts of memory. Well ... I seriously doubt that my percentage calculating code would benefit at all then. > In previous steps, 8-bit to 16-bit and 16-bit to 32-bit, quantities that > previously had to be manipulated as multiple units could now be handled as a > single unit. Most counters and integers exceed 8-bits, to moving to 16-bits > halved the work for almost anything. Still, many such things didn't fit in > 16-bits, so 32-bits halved the work for many things. However, almost > everything fits in 32-bits. So 64-bits either gets no benefit for most > things or just results in dragging extra bytes across the memory bus, which > doesn't get any faster. Now that you've got me thinking of it, metaphones shouldn't ever be any longer than 4 bytes anyway, so (as it stands now) I could cast them as integers and compare the ints instead of using strcmp(), which should be faster. Still doesn't demonstrate any need for a 64 bit system, though. > However, we'll all need to smoothly handle more than 4Gb of memory real > soon now. Memory mapping an 8Gb database may speed things up as well. It's > too early for me to tell about these kinds of things yet. Well, that's likely as well. Thanks for the reply, David. I appreciate the input. -- Bill Moran Potential Technologies http://www.potentialtech.com