From owner-freebsd-chat@FreeBSD.ORG Sun Mar 7 09:44:58 2004 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 CDE8316A4CE for ; Sun, 7 Mar 2004 09:44:58 -0800 (PST) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AA5D43D46 for ; Sun, 7 Mar 2004 09:44:58 -0800 (PST) (envelope-from narvi@haldjas.folklore.ee) Received: from haldjas.folklore.ee (localhost [127.0.0.1]) by haldjas.folklore.ee (8.12.10/8.12.10) with ESMTP id i27HioUA068389; Sun, 7 Mar 2004 19:44:50 +0200 (EET) (envelope-from narvi@haldjas.folklore.ee) Received: from localhost (narvi@localhost)i27HiovV068386; Sun, 7 Mar 2004 19:44:50 +0200 (EET) (envelope-from narvi@haldjas.folklore.ee) Date: Sun, 7 Mar 2004 19:44:49 +0200 (EET) From: Narvi To: stephan mantler In-Reply-To: <404A465A.1040009@stephanmantler.com> Message-ID: <20040307052509.F38020@haldjas.folklore.ee> References: <20040306005744.T38020@haldjas.folklore.ee> <20040306013914.D38020@haldjas.folklore.ee> <404A465A.1040009@stephanmantler.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on haldjas.folklore.ee cc: freebsd-chat@freebsd.org Subject: Re: FreeBSD Most wanted 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: Sun, 07 Mar 2004 17:44:59 -0000 On Sat, 6 Mar 2004, stephan mantler wrote: > Narvi wrote: > >>"Familiarity with the target machine and its instruction set is a > >>prerequisite for designing a good code generator. Unfortunately, in a > >>general discussion of code generation it is not possible to describe > >>the nuances of any target machine in sufficient detail to be able to > >>generate good code for a complete language on that machine." > >> -- The "Dragon" Book, pp 519 > > > > Sure - but code generation is but one part of the compiler and usualy not > > the largest. > > Well, it is still a crucial part of the compiler and deeply tied into the > rest. It is also the reason why simply using the Intel C++ compiler instead > of .NET2003 (both at full optimization) made our vector math library run > five times faster... guess who knows the target architecture ;-) In this Umm... It soudns far more plausible that Intel's compiler was able to make use of vectorisiation so that it uses SSE2 instead of x87 fpu. This is for the most part not ASM, but code analysis / rewriting. Sure, you need to be able to isse the SSE2 opcoides but that is a tiny part. Knowing any amount of SSE2 tricks will not help you one bit if the compiler cannot flatten the loop so you can make use of SIMD / vector instructions. Once you have that part done, you canthen relatively easily (at least in comparison to the ananlysis you need to be able to do) interface this to SSE2 && SSE and Altivec and VIS. > highly specific example hand optimized assembler code is another four times > faster for some functions, but I think this is not a problem of compilers per > se. I guess the C/C++ language simply isn't giving the compiler all the > information it would need. I haven't yet tried Intel's feedback optimization > feature, but it will be interesting to see what it will do to our library. > Its not all the information, its that it is unable to assume some things. If you have a compiler that can do interfile optimisations and profile feedback, it might generate better code. alternatively, if you want to see what the compiler can achieve, rewrite the routines in fortran (no i'm not kidding). In C, it is often very hard for the compiler to make assumptions about array overlap or aliasing. > Also, to get a bit closer to the original topic. I can't remember where I > read this (DDJ probably), but apparently programmers who have a deep > understanding of computer architecture through low level programming also > produce "better" code in high level languages. My interpretation is that > they are simply feeding the compiler a better foundation to work with. > The understanding would probably be about things like memory hierarchy and not ASM though. > Cheers, > -stephan > > -- > stephan mantler | web www.stephanmantler.com > ----------------------------| net step@stephanmantler.com > It's not an adventure | fon +43 (699) 104 128 42 > until something f--ks up. | fax +43 (699) 404 128 42 >