gcc: why optimize for size flag is not the default

Nikhil Sontakke wrote:

I was wondering why -Os is not used in place of -O2 while compiling the
Postgres sources with gcc. I prepared 2 install directories by respectively
using -Os and -O2 flags and in the former case it seems to reduce the
install footprint by about 1MB or so. Agreed this is not significant for
normal systems. But I was wondering if there is a performance reason too for
not using -Os.

-Os disables optimizations that make the code run faster, like loop
unrolling. There's no free lunch.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:

Nikhil Sontakke wrote:

I was wondering why -Os is not used in place of -O2 while compiling the
Postgres sources with gcc.

There's no free lunch.

In any case, this sort of choice is generally something that ought to be
applied at a distro level. If, say, Fedora or Debian chose to use -Os
uniformly across all their packages, then there might be a meaningful
amount of space saved in the aggregate. As far as I know, though, -Os
is not the preferred choice in any distro, which ought to tell you
something ...

regards, tom lane

On Wed, Mar 11, 2009 at 12:42 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

As far as I know, though, -Os
is not the preferred choice in any distro, which ought to tell you
something ...

Unless of course you include distributions like ucLinux or emDebian
which only proves the point.

--
greg

On 3/11/09, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:

Nikhil Sontakke wrote:

I was wondering why -Os is not used in place of -O2 while compiling the
Postgres sources with gcc.

There's no free lunch.

In any case, this sort of choice is generally something that ought to be
applied at a distro level. If, say, Fedora or Debian chose to use -Os
uniformly across all their packages, then there might be a meaningful
amount of space saved in the aggregate. As far as I know, though, -Os
is not the preferred choice in any distro, which ought to tell you
something ...

Linux kernel is moving to use -Os everywhere. AFAIK their argument is
that kernel code should not be doing anything CPU-intensive, thus
minimal cache usage is more important than unrolled loops.

This also seems to hint that -Os is not really appropriate to Postgres.
Although it would be good fit for eg. PgBouncer.

--
marko

On 11 Mar 2009, at 13:51, Marko Kreen wrote:

Linux kernel is moving to use -Os everywhere. AFAIK their argument is
that kernel code should not be doing anything CPU-intensive, thus
minimal cache usage is more important than unrolled loops.

This also seems to hint that -Os is not really appropriate to
Postgres.
Although it would be good fit for eg. PgBouncer.

while it might be right in case of linux kernel (which I won't agree
totally with personally), I don't see any reason to compare it with
postgresql.
Kernel is extensively use by everything in system, hence their
reasoning. Postgresql is an application.

On Mar 11, 2009, at 3:18 PM, Grzegorz Jaskiewicz wrote:

On 11 Mar 2009, at 13:51, Marko Kreen wrote:

Linux kernel is moving to use -Os everywhere. AFAIK their argument
is
that kernel code should not be doing anything CPU-intensive, thus
minimal cache usage is more important than unrolled loops.

This also seems to hint that -Os is not really appropriate to
Postgres.
Although it would be good fit for eg. PgBouncer.

while it might be right in case of linux kernel (which I won't agree
totally with personally), I don't see any reason to compare it with
postgresql.
Kernel is extensively use by everything in system, hence their
reasoning. Postgresql is an application.

MacOS X defaults to and recommends -Os with the rationales that
smaller code causes less paging and less CPU instruction cache
thrashing.

http://developer.apple.com/ReleaseNotes/DeveloperTools/RN-GCC3/index.html
For deployment builds, the recommended setting is -Os, which produces
the smallest possible binary size. Generally, a binary that's smaller
is also faster. That's because a large application spends much of its
time paging its binary code in and out of memory. The smaller the
binary, the less the application needs to page. For example, say a
binary uses aggressive function inlining. That binary saves time with
fewer function calls, but it could easily spend far more time paging
the binary code containing those inlined functions in and out of memory.

-Os Optimize for size. -Os enables all -O2 optimizations that do not
typically increase code size. It also performs further optimizations
designed to reduce code size.

-Os is still "optimizing" but using a slightly different heuristic as
to what "optimization" means.

That said, if postgresql is paging out, the DBA probably has
postgresql or the server misconfigured.

Cheers,
M

A.M. wrote:

That said, if postgresql is paging out, the DBA probably has postgresql
or the server misconfigured.

Keep in mind that "paging in" in this context also means moving stuff
from plain RAM into cache.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.