Re: build environment: a different makefile

Zdenek is right.

Normal inlining using -O3 or higher means inlining within the source
file. I currently try to see the effect of inlining over all the
sources. The -xipo flag is specific to the Sun Studio (version 12)
suite. It creates large objects that now include meta data for the
final linking stage. During this linking stage all this stuff is
read, analyzed an the object files are changed. Later this can be
expanded by compiler profiling and/or other trickery. BTW the actual
binary does *not* include all that metadata and is just bigger due to
all that code being inlined in those objects.

This trick has been done for other applications and we find in
general significant approvement. Not a guarantee though ...

However my "suite" has a dependecy on dtrace so the initial idea I
saw from Peter is not complete. Currently creating a quick and dirty
build script. Just to get that "ipo"-ing done and tested.

I'll keep you all updated on the results. If we decide it is too good
to be excluded can we start thinking about an adaption of the build
environement. Hope this sound fair and acceptable to all.

Thanks so far for all that feedback

Cheers
Paul

BTW I build and test on a 16 SPARC @1350MHz V890. 64 bit mode,
currently 16GB of shared memory, and 7 disk arrays (RAID0). This to
exclude the IO part of the equation as much as possible, so we can
focus on CPU related matter: the need for faster (smarter) code
pathes and/or scalability issues like ProcArrayLock contention.

On 7-feb-2008, at 11:08, Zdenek Kotala wrote:

> Peter Eisentraut napsal(a):
>> Paul van den Bogaard wrote:
>>> The SunStudio compiler we are using fortunately has an option
>>> for this. Unfortunately there are restrictions. One restriction
>>> I face is its inability to deal with "ld -r"s. These are used in
>>> the build environment to create all the SUBSYS.o object files.
>>>
>>> I was hoping someone in the community already has a makefile
>>> that "just" creates object files from C-sources directly that I
>>> can use to try out the effect of in-lining to the performance of
>>> postgres.
>> I don't know if anyone has a makefile for it, but the following
>> seems to work
>> for me:
>> pgsql/src/backend$ cc -O2 -Wall -Wmissing-prototypes -Wpointer-
>> arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-
>> strict-aliasing -g -L../../src/port -Wl,-rpath,'/home/peter/devel/
>> pg83/pg-install/lib' -Wl,-E $(find -name "*.o" | grep -v SUBSYS |
>> grep -v conversion_procs) ../../src/timezone/SUBSYS.o ../../src/
>> port/libpgport_srv.a -lxslt -lxml2 -lpam -lssl -lcrypto -
>> lgssapi_krb5 -lcrypt -ldl -lm -lldap -o postgres
>> If you find that the optimizations you are hoping for are useful,
>> I'm sure
>> we could put an option of that sort somewhere in the makefiles.
>
> Peter,
> Suns studio performs inline optimization on -xO3 level.
> Optimization levels are different from GCC. Maximal level is -xO5.
> I think Paul plays with xipo flag which requires at least -xO4.
>
> See
> http://docs.sun.com/app/docs/doc/819-5265/bjapp?a=view
>
> Zdenek
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster

------------------------------------------------------------------------
---------------------
Paul van den Bogaard
Paul(dot)vandenBogaard(at)sun(dot)com
ISV-E -- ISV Engineering, Opensource Engineering group

Sun Microsystems, Inc phone: +31
334 515 918
Saturnus 1
extentsion: x (70)15918
3824 ME Amersfoort mobile: +31
651 913 354
The Netherlands
fax: +31 334 515 001