public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: ridiculous amounts of padding
@ 1999-01-31 23:58 John Wehle
  1999-01-31 23:58 ` Marc Espie
  0 siblings, 1 reply; 37+ messages in thread
From: John Wehle @ 1999-01-31 23:58 UTC (permalink / raw)
  To: zack; +Cc: egcs, law

> glibc has very aggressively optimized string functions, that do tricks like
> that.  They do not appear to require more than 8 byte alignment on x86.  I'm
> not sure about other platforms.

I implemented CONSTANT_ALIGNMENT following the recommendations of the
"Intel Architecture Optimization Manual" that objects over a certain
size should be aligned on 32 byte boundaries in order to reduce the
number of cache lines.

> For the case that prompted the question (cpplib.c:print_help()) we emit 4468
> bytes of string constants and 1228 bytes of padding.  That's a 27.5% space
> increase.

It's certainly worth considering having this type of thing controlled by
-Os.  Many of the alignments done for performance result in an increase
in size which may be undesirable in some situations.  BTW, in all fairness
I would be surprised if the 27.5% space increase is representative of the
total size change that the final executable experienced due to extra
alignment.

-- John
-------------------------------------------------------------------------
|   Feith Systems  |   Voice: 1-215-646-8000  |  Email: john@feith.com  |
|    John Wehle    |     Fax: 1-215-540-5495  |                         |
-------------------------------------------------------------------------

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: ridiculous amounts of padding
@ 1999-02-01 17:28 N8TM
  1999-02-28 22:53 ` N8TM
  0 siblings, 1 reply; 37+ messages in thread
From: N8TM @ 1999-02-01 17:28 UTC (permalink / raw)
  To: pcg, law; +Cc: egcs

In a message dated 2/1/99 8:36:31 AM Pacific Standard Time, pcg@goof.com
writes:

<< btw, did you benchmark 1.1.1 or the current snapshot? 1.1.1 seems to be
 slower than gcc-2.8 with every benchmark _I_ tried, and I guess thats what
 people test. The snapshots, however, are faster. >>

In most of my benchmarks, 1.1.1 was fastest with -Os.  Recent snapshots (not
this week's!) do as well or better than 1.1.1 at -Os, and often better at -O2
or -O3.

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: ridiculous amounts of padding
@ 1999-01-31 23:58 N8TM
  1999-01-31 23:58 ` Zack Weinberg
  0 siblings, 1 reply; 37+ messages in thread
From: N8TM @ 1999-01-31 23:58 UTC (permalink / raw)
  To: john, zack; +Cc: egcs, law

In a message dated 1/13/99 4:47:58 PM Pacific Standard Time, john@feith.com
writes:

<< It's certainly worth considering having this type of thing controlled by
 -Os.  Many of the alignments done for performance result in an increase
 in size which may be undesirable in some situations.   >>
In my tests (mostly g77), the difference in performance due to alignments is
much greater than the difference between -Os and -O2, so I'd like to continue
to improve the alignments available with -Os.

If you're talking about saving space, turning off .p2align typically saves
about 5% in code space but takes at least that much longer to run on a PPro,
much more on a p2.  I haven't seen anyone seriously wanting to turn off
.p2align, although a smarter compiler could figure out where it may be time
critical and where it definitely isn't.

^ permalink raw reply	[flat|nested] 37+ messages in thread
* ridiculous amounts of padding
@ 1999-01-31 23:58 Zack Weinberg
  1999-01-31 23:58 ` Alfred Perlstein
  1999-01-31 23:58 ` Joern Rennecke
  0 siblings, 2 replies; 37+ messages in thread
From: Zack Weinberg @ 1999-01-31 23:58 UTC (permalink / raw)
  To: egcs

Since everyone is discussing string functions...

Code of the form

puts("line 1");
puts("line 2");
puts("line 3");
...
puts("line 96");

is compiled (at least on x86) into a series of calls and a bunch of string
table entries.  Fine.  The problem is, in the string table we emit
.align 32 directives between all the strings.  This wastes quite a lot of
space.  It seems that this is because of a general policy of aligning
.rodata items on 32 byte boundaries - I assume for cache reasons.  When we
know, as in this case, that all the strings will be accessed in succession,
I think we should be able to remove the padding.  (Kaveh's suggested
collapse-to-one-call optimization would be good too.)

I would rewrite it
puts(	"line 1\n"
	"line 2\n"
	...
	"line 96");

but it has to compile on K+R compilers.

zw

^ permalink raw reply	[flat|nested] 37+ messages in thread
* Re: ridiculous amounts of padding
@ 1999-01-31 23:58 John Wehle
  0 siblings, 0 replies; 37+ messages in thread
From: John Wehle @ 1999-01-31 23:58 UTC (permalink / raw)
  To: Marc.Espie; +Cc: egcs

> I'm also pretty new to the i386, I'm more used to m68k. I've given a few 
> code fragments to fellow OpenBSD developpers, and what's come out is that
> egcs produces larger code, apparently because it prefers leaving stuff
> in memory to using registers when code speed is the same... but size
> is definitely not the same.

You mentioned a similar problem involving regmove in December.

  1) Did the patch I mentioned help?

  2) Does the problem occur using current snapshots?

Code fragments where current egcs snapshots don't compile to efficient
instruction sequences (or when using -Os the instruction sequence is
overly large) are of interest, especially if older versions of the
compiler (or gcc 2.8) do a better job when using the same compiler
options.  Keep in mind that there are cases where egcs will produce
larger code in the interest of performance, and that it's not always
obvious from code inspection why it's being done.  -Os addresses some
of the speed versus size issues, though I'm sure it can be improved
(especially if someone can point out the exact failing :-).

> I am not trying to start a flamewar here, just trying to get some help.

There are certainly people here willing to help though at times it may
take a while for someone to get back to you due to other things being in
their queue.  Anything you can do to supply specifics (or small test cases)
which isolate the problem helps tremendously.

-- John
-------------------------------------------------------------------------
|   Feith Systems  |   Voice: 1-215-646-8000  |  Email: john@feith.com  |
|    John Wehle    |     Fax: 1-215-540-5495  |                         |
-------------------------------------------------------------------------

^ permalink raw reply	[flat|nested] 37+ messages in thread
end of thread, other threads:[~1999-02-28 22:53 UTC | newest]

Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-01-31 23:58 ridiculous amounts of padding John Wehle
1999-01-31 23:58 ` Marc Espie
1999-01-31 23:58   ` Joe Buck
1999-01-31 23:58     ` Marc Espie
1999-01-31 23:58   ` David Edelsohn
1999-01-31 23:58     ` Joe Buck
1999-01-31 23:58       ` Gabriel Dos Reis
1999-01-31 23:58         ` Joe Buck
1999-01-31 23:58           ` Jeffrey A Law
1999-01-31 23:58   ` Jeffrey A Law
1999-01-30 16:35     ` Marc Lehmann
1999-01-31 20:05       ` Jeffrey A Law
1999-02-01  8:07         ` Marc Lehmann
1999-02-28 22:53           ` Marc Lehmann
1999-01-31 23:58       ` Marc Lehmann
  -- strict thread matches above, loose matches on Subject: below --
1999-02-01 17:28 N8TM
1999-02-28 22:53 ` N8TM
1999-01-31 23:58 N8TM
1999-01-31 23:58 ` Zack Weinberg
1999-01-31 23:58   ` Jeffrey A Law
1999-01-31 23:58 Zack Weinberg
1999-01-31 23:58 ` Alfred Perlstein
1999-01-31 23:58 ` Joern Rennecke
1999-01-31 23:58   ` Jeffrey A Law
1999-01-31 23:58     ` Peter Barada
1999-01-31 23:58       ` Zack Weinberg
1999-01-31 23:58         ` Jeffrey A Law
1999-01-31 23:58           ` Zack Weinberg
1999-01-31 23:58             ` Jeffrey A Law
1999-01-31 23:58       ` Marc Espie
1999-01-31 23:58       ` Nick Ing-Simmons
1999-01-31 23:58         ` Joern Rennecke
1999-01-31 23:58           ` John Vickers
1999-01-31 23:58             ` Joern Rennecke
1999-01-31 23:58     ` Joern Rennecke
1999-01-31 23:58       ` Jeffrey A Law
1999-01-31 23:58 John Wehle

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).