Date: Wed, 10 Mar 1999 17:37:16 +0100 To: pgcc AT delorie DOT com Subject: Re: gcc-2.7.0 creates faster code than pgcc-1.1.1 Message-ID: <19990310173716.F29392@cerebro.laendle> Mail-Followup-To: pgcc AT delorie DOT com References: <199903022313 DOT RAA17721 AT mail DOT mankato DOT msus DOT edu> <19990303165906 DOT A4028 AT cerebro DOT laendle> <36DDD2C1 DOT 421DD4AF AT t-online DOT de> <19990309175312 DOT G2217 AT cerebro DOT laendle> <36E5C625 DOT 57398450 AT t-online DOT de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <36E5C625.57398450@t-online.de>; from Hans-Peter Jansen on Wed, Mar 10, 1999 at 02:08:53AM +0100 X-Operating-System: Linux version 2.2.3 (root AT cerebro) (gcc driver version pgcc-2.93.09 19990221 (gcc2 ss-980929 experimental) executing gcc version 2.7.2.3) From: Marc Lehmann Reply-To: pgcc AT delorie DOT com X-Mailing-List: pgcc AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Wed, Mar 10, 1999 at 02:08:53AM +0100, Hans-Peter Jansen wrote: > > I don't feel offended, but on which CPU did you do your tests? My > > slackware 1995 binary runs significantly slower on my machine (p-ii) than > > the pgcc compiled ones, that is with current pgcc as well as the old libc5 > > binary that we happen to have on our homepage. > > Oops, sorry, bootstraped pgcc 1.1.1 on a linux 2.0.35 libc5 (SuSE 5.3) > amd K2/300 (ähem 330) 128 MB, IDE HD system. Alternative 2.0.36pre15 libc5 > Dual PII 300, 320 MB, hardware raid 5 UWSCSI subsystem (the server) compared > to standard gcc 3.7.2.1 generated code. A libc6 system's still waiting > for configuration... (will do it soon) Hmm... > > This is with the snapshot pgcc, btw. The release might have some > > hand-tuning to be correct rather than fast in some cases. > > Because of some probs with current pgcc mentioned in linux-kernel and (btw, the linux-kernel is not fixed to work with newer versions of gcc, so you better not try that one. Also, kde only recently upgraded their sources to C++ (they used an unsupported c++ dialect before that pgcc does not understand)). > kde-devel, I restrained from installing egcs/pgcc snapshot versions. I'm very picky about these issues. AFAIK there are problems with both kde and linux-kernel, NOT with egcs or pgcc. (Surely pgcc snapshots have bugs, but people just like to claim "egcs" is broken. They will be surprised when the next gcc version won't compile their programs, either) > When the next release is planned? What about Linus' whining about > undefined references and inlining? Is there a consence now? The consensus is that Linus tries to read the documentation before flaming and the egcs developers try to help the kernel by supporting more interfaces in the future. Also, Linus does not support current gcc, egcs or pgcc. Point. > Do you think, that current snapshots optimizes k6 objects really better, > or is there any other explanation about our experiences? The snapshots have a totally different (and IMHO better) scheduling system for amd. I haven't benchmarked these extensivley (not at all, to be clear), but they might indeed make a few percent difference. When in doubt, run your favourite benchmark/application. The latter test will tell you wether pgcc is _really_ faster for _your_ problem. -- -----==- | ----==-- _ | ---==---(_)__ __ ____ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / pcg AT goof DOT com |e| -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |