From owner-freebsd-current Sun Feb 9 10: 3:59 2003 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 CD5DA37B401 for ; Sun, 9 Feb 2003 10:03:57 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by mx1.FreeBSD.org (Postfix) with SMTP id 0E60343F93 for ; Sun, 9 Feb 2003 10:03:56 -0800 (PST) (envelope-from mdcki@gmx.net) Received: (qmail 18959 invoked by uid 0); 9 Feb 2003 18:03:54 -0000 Received: from cvpn017.gwdg.de (HELO gmx.net) (134.76.22.17) by mail.gmx.net (mp003-rz3) with SMTP; 9 Feb 2003 18:03:54 -0000 Message-ID: <3E469901.8000500@gmx.net> Date: Sun, 09 Feb 2003 19:08:01 +0100 From: Marcin Dalecki User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021230 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Schultz Cc: Adrian Chadd , Terry Lambert , Ray Kohler , freebsd-current@freebsd.org Subject: Re: Compiling with high optimization? References: <20030208173756.GA56030@arkadia.nv.cox.net> <20030208232724.GA20435@HAL9000.homeunix.com> <3E459BF3.BB3FC381@mindspring.com> <20030209002542.GA20812@HAL9000.homeunix.com> <20030209141006.GB33928@skywalker.creative.net.au> <20030209150120.GA2263@HAL9000.homeunix.com> <3E4671E6.8090000@gmx.net> <20030209152836.GB1390@HAL9000.homeunix.com> In-Reply-To: <20030209152836.GB1390@HAL9000.homeunix.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG David Schultz wrote: > Thus spake Marcin Dalecki : > >>David Schultz wrote: >> >> >>>Strangely, gcc in FreeBSD 5.0 actually generates *slower* code >>>when compiling for more recent architectures than when compiling >>>for a 386. I don't know whether that is a bug in gcc or whether >>>gcc is using some fancy feature like SSE that the kernel handles >>>poorly on context switches. I think there was some discussion on >>>the lists about it earlier. >> >>The reason is that the optimization done by GCC are ill balanced. >>All the scheduling of instractions and what a not - which would be >>fine on a micro scope level is causing so much higher pressure >>on the CPUs caches that the code is actually loosing. > > > Interesting. So they redid the code generation for gcc 3 and > their new tricks backfired. But at least they fixed the > completely braindead things gcc 2.9x was doing with alignment, > floating point, and combinations thereof, and they got the > compiler to do more reasonable things on ia64. Any idea when they > will have fixed the i386 anti-optimizations? Well one of the aims seems currently to fix the most hideous design idiocy inside GCC. Namely: optimizing on the code generation level only instead of the parse tree. However at the current speed of things they will maybe only in about 10 years there. It would make much more sense to support efforts like www.tendra.org or www.openwatcom.org instead of giving any kind of hope to GCC. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message