From mboxrd@z Thu Jan 1 00:00:00 1970 From: Craig Burley To: pcg@goof.com Cc: egcs@cygnus.com, burley@gnu.org Subject: Re: Performance measurements Date: Thu, 02 Jul 1998 07:14:00 -0000 Message-id: <199807021414.KAA28041@melange.gnu.org> References: <19980702003443.62031@cerebro.laendle> X-SW-Source: 1998-07/msg00087.html [Sorry I haven't tracked this thread; also I removed axp-list@redhat.com, since my comments apply to only the x86 processor.] >I also don't see the bad performance of egcs vs. gcc-2.7.2.3 My guess, not knowing what the code is (even its language), is that this is due to the program being dependent mostly upon *static* double-precision variables and arrays. At least, that would explain the big difference in using -malign-double over -mno-align-double on 2.7.2.3, especially if g77 is the compiler being used. Although, I'm at a loss to understand why a small *opposite* difference is seen using egcs 1.0.3a, which doesn't default to aligning static doubles (based on my `align' package's output, anyway). Even if stack-based doubles are used a lot, whether the bad performance actually shows up in a benchmark can depend on fairly random things -- the "original case" reported to being that the run-times differed *significantly* depending on the length of the *name* of the executable!! So it might be that 2.7.2.3 happened to naturally hit bad alignments with -mno-align-double, nailed great ones (as should normally, but not always, be the case) with -malign-double, but none of the other runs happened to hit such black & white alignments (e.g. maybe there are all either white, eggshell, beige, or ecru ;-). At this point, with the 1.1 freeze looming, I feel we have too much more to learn about solving this problem right to try to rush a quick fix into 1.1. Though, I'm going to try and keep it is a fairly top priority, to avoid having it slip until it's too late to fix properly (or at least decide we can't do so) in 1.2. tq vm, (burley)