Re: strict aliasing (was: const correctness)

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Florian Pflug" <fgp(at)phlo(dot)org>
Cc: "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Thomas Munro" <munro(at)ip9(dot)org>, <pgsql-hackers(at)postgresql(dot)org>,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: strict aliasing (was: const correctness)
Date: 2011-11-14 19:47:17
Message-ID: 4EC11BE50200002500042EA3@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Florian Pflug <fgp(at)phlo(dot)org> wrote:

> If we're concerned about helping the compiler produce better code,
> I think we should try to make our code safe under strict aliasing
> rules. AFAIK, that generally helps much more than
> const-correctness. (Dunno how feasible that is, though)

To get a preliminary feel for how much this might help, I set my
workstation with an i7-2600 and 16GB RAM to run Robert Haas's
pgbench concurrency tests against PostgreSQL built with (default)
-O2 and no strict aliasing versus -O3 and strict aliasing. I
ignored the ten warnings about punning under strict aliasing. Both
builds were with asserts disabled. No other changes from Friday's
HEAD. All runs were at the REPEATABLE READ isolation level. I
scheduled it for a window of time where the box wasn't running any
scheduled maintenance.

The results were interesting. While the small overlap between
samples from the two builds at most levels means that this was
somewhat unlikely to be just sampling noise, there could have been
alignment issues that account for some of the differences. In
short, the strict aliasing build always beat the other with 4
clients or fewer (on this 4 core machine), but always lost with more
than 4 clients.

1 client: +0.8%
2 clients: +2.0%
4 clients: +3.2%
8 clients: -0.9%
16 clients: -0.5%
32 clients: -0.9%

I wouldn't want to make too much out of this without repeating the
tests and trying different hardware, but I'm wondering whether the
abrupt difference at the number of cores makes sense to anybody.
Also, is there something I should do to deal with the warnings
before this would be considered a meaningful test?

Raw numbers:

no-strict-aliasing.1 tps = 7140.253910
no-strict-aliasing.1 tps = 7291.465297
no-strict-aliasing.1 tps = 7219.054359
no-strict-aliasing.2 tps = 16592.613779
no-strict-aliasing.2 tps = 15418.602945
no-strict-aliasing.2 tps = 16826.200551
no-strict-aliasing.4 tps = 48145.694444
no-strict-aliasing.4 tps = 47141.611960
no-strict-aliasing.4 tps = 47263.175254
no-strict-aliasing.8 tps = 93466.397174
no-strict-aliasing.8 tps = 93757.111493
no-strict-aliasing.8 tps = 93422.349453
no-strict-aliasing.16 tps = 88758.623319
no-strict-aliasing.16 tps = 88976.546555
no-strict-aliasing.16 tps = 88521.025343
no-strict-aliasing.32 tps = 87799.019143
no-strict-aliasing.32 tps = 88006.881881
no-strict-aliasing.32 tps = 88295.826711

strict-aliasing.1 tps = 7067.461710
strict-aliasing.1 tps = 7415.244823
strict-aliasing.1 tps = 7277.643321
strict-aliasing.2 tps = 14576.820162
strict-aliasing.2 tps = 16928.746994
strict-aliasing.2 tps = 19958.285834
strict-aliasing.4 tps = 48780.830247
strict-aliasing.4 tps = 49067.751657
strict-aliasing.4 tps = 48303.413578
strict-aliasing.8 tps = 93155.601896
strict-aliasing.8 tps = 92279.973490
strict-aliasing.8 tps = 92629.332125
strict-aliasing.16 tps = 88328.799197
strict-aliasing.16 tps = 88283.503270
strict-aliasing.16 tps = 88463.673815
strict-aliasing.32 tps = 87148.701204
strict-aliasing.32 tps = 87398.233624
strict-aliasing.32 tps = 87201.021722

-Kevin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thom Brown 2011-11-14 20:04:26 Re: patch: CHECK FUNCTION statement
Previous Message Alvaro Herrera 2011-11-14 19:26:04 Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers