Re: [HACKERS] strict aliasing

2011-11-16 Thread Kevin Grittner
Ants Aasma ants.aa...@eesti.ee wrote: Concurrency 8 results should probably be ignored - variance was huge, definitely more than the differences. I'm not so sure it should be ignored -- one thing I noticed in looking at the raw numbers from my benchmarks was that the -O2 code was much more

Re: [HACKERS] strict aliasing

2011-11-16 Thread Robert Haas
On Wed, Nov 16, 2011 at 9:47 AM, Kevin Grittner kevin.gritt...@wicourts.gov wrote: This suggests that in the long term, it might be worth investigating whether we can arrange for a connection's process to have some degree of core affinity and encourage each process to allocate local memory

Re: [HACKERS] strict aliasing

2011-11-16 Thread Kevin Grittner
Robert Haas robertmh...@gmail.com wrote: Kevin Grittner kevin.gritt...@wicourts.gov wrote: This suggests that in the long term, it might be worth [...] The other possibility is that the OS is smart enough about moving things around to get good locality that sticking locality hints on top

Re: [HACKERS] strict aliasing

2011-11-15 Thread Florian Weimer
* Andres Freund: I don't gcc will ever be able to call all possible misusages. E.g. The List api is a case where its basically impossible to catch everything (as gcc won't be able to figure out what the ListCell.data.ptr_value pointed to originally in the general case). Correct, if code is

Re: [HACKERS] strict aliasing

2011-11-15 Thread Kevin Grittner
Florian Weimer fwei...@bfk.de wrote: * Andres Freund: I don't gcc will ever be able to call all possible misusages. E.g. The List api is a case where its basically impossible to catch everything (as gcc won't be able to figure out what the ListCell.data.ptr_value pointed to originally in

Re: [HACKERS] strict aliasing

2011-11-15 Thread Ants Aasma
On Tue, Nov 15, 2011 at 9:02 PM, Kevin Grittner kevin.gritt...@wicourts.gov wrote: From my reading, it appears that if we get safe code in terms of strict aliasing, we might be able to use the restrict keyword to get further optimizations which bring it to a net win, but I think there is

Re: [HACKERS] strict aliasing (was: const correctness)

2011-11-14 Thread Kevin Grittner
Florian Pflug f...@phlo.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

Re: [HACKERS] strict aliasing (was: const correctness)

2011-11-14 Thread Tom Lane
Kevin Grittner kevin.gritt...@wicourts.gov writes: 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

Re: [HACKERS] strict aliasing (was: const correctness)

2011-11-14 Thread Kevin Grittner
Tom Lane t...@sss.pgh.pa.us wrote: Kevin Grittner kevin.gritt...@wicourts.gov writes: 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

Re: [HACKERS] strict aliasing (was: const correctness)

2011-11-14 Thread Kevin Grittner
Tom Lane t...@sss.pgh.pa.us wrote: Dunno ... where were the warnings exactly? Ah, you asked where, not what. I don't think I saved that, and I had to reboot for a new kernel, so I don't have the buffer sitting around. I'll do a new build and let you know shortly. -Kevin -- Sent via

Re: [HACKERS] strict aliasing (was: const correctness)

2011-11-14 Thread Kevin Grittner
Kevin Grittner kevin.gritt...@wicourts.gov wrote: Tom Lane t...@sss.pgh.pa.us wrote: Kevin Grittner kevin.gritt...@wicourts.gov writes: Also, is there something I should do to deal with the warnings before this would be considered a meaningful test? Dunno ... where were the warnings

Re: [HACKERS] strict aliasing (was: const correctness)

2011-11-14 Thread Tom Lane
Kevin Grittner kevin.gritt...@wicourts.gov writes: Tom Lane t...@sss.pgh.pa.us wrote: Dunno ... where were the warnings exactly? From HEAD checkout of a few minutes ago I now see only 9: Hmm ... well, none of those look likely to be in performance-sensitive areas. But I wonder just how good

Re: [HACKERS] strict aliasing (was: const correctness)

2011-11-14 Thread Alvaro Herrera
Excerpts from Kevin Grittner's message of lun nov 14 17:30:50 -0300 2011: Tom Lane t...@sss.pgh.pa.us wrote: Kevin Grittner kevin.gritt...@wicourts.gov writes: Also, is there something I should do to deal with the warnings before this would be considered a meaningful test? Dunno ...

Re: [HACKERS] strict aliasing (was: const correctness)

2011-11-14 Thread Martijn van Oosterhout
On Mon, Nov 14, 2011 at 06:25:19PM -0300, Alvaro Herrera wrote: All 10 were like this: warning: dereferencing type-punned pointer will break strict-aliasing rules Uhm, shouldn't we expect there to be one warning for each use of a Node using some specific node pointer type as

Re: [HACKERS] strict aliasing (was: const correctness)

2011-11-14 Thread Andres Freund
On Monday, November 14, 2011 10:25:19 PM Alvaro Herrera wrote: Excerpts from Kevin Grittner's message of lun nov 14 17:30:50 -0300 2011: Tom Lane t...@sss.pgh.pa.us wrote: Kevin Grittner kevin.gritt...@wicourts.gov writes: Also, is there something I should do to deal with the warnings

Re: [HACKERS] strict aliasing (was: const correctness)

2011-11-14 Thread Andres Freund
On Monday, November 14, 2011 10:22:52 PM Tom Lane wrote: Kevin Grittner kevin.gritt...@wicourts.gov writes: Tom Lane t...@sss.pgh.pa.us wrote: Dunno ... where were the warnings exactly? From HEAD checkout of a few minutes ago I now see only 9: Hmm ... well, none of those look likely to