From owner-freebsd-performance@FreeBSD.ORG Tue Feb 24 17:17:17 2004 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E44316A4CE; Tue, 24 Feb 2004 17:17:17 -0800 (PST) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F2D143D1D; Tue, 24 Feb 2004 17:17:17 -0800 (PST) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i1P1HG1T004899; Tue, 24 Feb 2004 17:17:16 -0800 (PST) Received: from [10.1.1.193] ([199.103.21.225]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 3.0) with ESMTP id i1P1HFXp012110; Tue, 24 Feb 2004 17:17:16 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v612) In-Reply-To: <20040224202652.GA13675@diogenis.ceid.upatras.gr> References: <20040223192103.59ad7b69.lehmann@ans-netz.de> <20040224202652.GA13675@diogenis.ceid.upatras.gr> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5410C982-6730-11D8-8D4C-003065ABFD92@mac.com> Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Tue, 24 Feb 2004 20:17:07 -0500 X-Mailer: Apple Mail (2.612) cc: freebsd-performance@FreeBSD.org cc: freebsd-alpha@FreeBSD.org Subject: Re: Bad performance on alpha? (make buildworld) X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 01:17:17 -0000 On Feb 24, 2004, at 3:26 PM, Nikos Ntarmos wrote: > IIRC the 600MHz EV56's performance wrt integer operations (such as > compiling) is somewhere in the vicinity of a 400MHz P-II, so the > difference you see in turn-around times when buildworld'ing isn't > quite that big. If the operations were identical, you should see > better times when building on the alpha. However, also take into > account that compiling (and optimizing) for a RISC CPU, apart from > generating larger binaries, is AFAIK supposedly more difficult than > compiling (and optimizing) for a CISC CPU. I'm afraid you've got this backwards. :-) The primary attributes of RISC architectures, namely lots of registers, a relatively simple but orthagonal instruction set, and a relatively fast clock rate / CPI ~= 1.0 / a short pipeline make it far easier for the compiler to generate and optimize code. CISC architectures make the compilers job much harder because they tend to require lots of register spills, they tend to have very long pipelines which involve hazards and require a lot of instruction reordering to avoid stalling the pipeline to often. The amount of CPU clocks it takes per instruction (CPI) often varies on CISC as is generally much larger than ~1.0, and sometimes varies from CPU model to CPU model making it far more difficult to determine the "fastest" instruction sequence. At a broader level, RISC closely matches the intermediate code model compilers work with than CISC does, which makes it easier to generate target code from the intermediate code. Often, on RISC there is little difference between the two, just as there is less difference between optimized and unoptimized code, whereas on CISC there is a lot more work to be done in order to get optimized code working with comparible efficiency. -- -Chuck