From owner-freebsd-amd64@FreeBSD.ORG Tue Mar 14 12:44:12 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD1E016A400 for ; Tue, 14 Mar 2006 12:44:12 +0000 (UTC) (envelope-from ray@redshift.com) Received: from mail-fs2.redshift.com (mail-smtp.redshift.com [216.228.2.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2817543D45 for ; Tue, 14 Mar 2006 12:44:12 +0000 (GMT) (envelope-from ray@redshift.com) Received: (qmail 7318 invoked by uid 89); 14 Mar 2006 12:44:11 -0000 Received: by simscan 1.2.0 ppid: 7314, pid: 7315, t: 0.0894s scanners: attach: 1.2.0 clamav: 0.88/m:36/d:1318 Received: from unknown (HELO workstation) (216.228.19.21) by mail-fs2.redshift.com with SMTP; 14 Mar 2006 12:44:11 -0000 Message-Id: <3.0.1.32.20060314044416.00af7f30@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Tue, 14 Mar 2006 04:44:16 -0800 To: JoaoBR From: ray@redshift.com In-Reply-To: <200603140927.00320.joao@matik.com.br> References: <3.0.1.32.20060314034932.00ae9678@pop.redshift.com> <200603140740.38388.joao@matik.com.br> <3.0.1.32.20060314034932.00ae9678@pop.redshift.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: kono@kth.se, freebsd-amd64@freebsd.org Subject: Re: amd64 slower than i386 on identical AMD 64 system? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2006 12:44:12 -0000 At 09:27 AM 3/14/2006 -0300, JoaoBR wrote: | On Tuesday 14 March 2006 08:49, ray@redshift.com wrote: | > At 12:38 PM 3/14/2006 +0100, Alexander Konovalenko wrote: | > | On Tuesday 14 March 2006 11:40, JoaoBR wrote: | > | > so where is your comparism? My point was that the same hardware is | > | > faster running i386 | > | > | > | I have experienced that -O3 and -ffast-math optimizations flags on AMD64 | > | might cause degrade in performance, meaning that -O2 is the fastest. When | > | you compile your ports what opt. flags do you use? Try to reinstall | > | ubench with different flags. Also code produced with gcc4.x is faster | > | then system compiler and has no degrade effect. Some time ago I was | > | interested in fast scientific computations and did some primitive | > | benchmark tests | > | (http://daemon.nanophys.kth.se/~kono/testfcpu) | > | | > | I just wonder what will happen if you run ubench (compiled for i386) on | > | AMD64, will performance overcome amd64 ubench? | > | | | and what would be the point here? | | the amd64 systems I checked are running amd64 | the i386 systems I checked are running i386 | | and entirely I mean | | > | > I'm just coming in on the tail end of the message (missed the previous | > stuff). I recently did some benchmarks between AMD64 and i386 (version 5.4) | > on the same hardware. I initially saw that the i386 ran faster also. | > However, after searching a bit further, I discovered that I had made an | > error: the i386 kernel has the SMP stuff compiled into the generic kernel | > by default, while the AMD64 (at least on 5.4) does not. It has a separate | > kernel file called SMP (as I recall), which adds the SMP line and then does | > an include for the rest of the generic kernel config file (or something to | > that effect). | > | > Anyway, if you are testing back and forth, it's easy to forget that and end | > up accidently testing an i386 with SMP against an AMD64 without SMP. | > | | obviously I checked UP kernels against UP and SMP against SMP | but anyway running SMP kernel on single processor systems should not affect | this tests | | Joćo Perhaps it's the fact that AMD64 has to deal with larger pointers? In speaking with AMD on this subject some months ago, I believe they mentioned there was a compiler switch/flag you could use to force 32 bit pointers. I never bothered to try it and don't know the specifics of it, but perhaps it's something to check into further. Ray