Robert Haas wrote:
> Kevin Grittner 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 doesn't really make any difference. Certai
On Wed, Nov 16, 2011 at 9:47 AM, Kevin Grittner
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 from RAM controlled by that
Ants Aasma 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 consistent from run
On Tue, Nov 15, 2011 at 9:02 PM, Kevin Grittner
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 currently lower-hanging fru
Florian Weimer 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 the gen
* 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 i
On Monday, November 14, 2011 10:22:52 PM Tom Lane wrote:
> "Kevin Grittner" writes:
> >> Tom Lane 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
> a
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 wrote:
> > > "Kevin Grittner" writes:
> > >> Also, is there something I should do to deal with the warnings
> > >> before this would be considere
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
Excerpts from Kevin Grittner's message of lun nov 14 17:30:50 -0300 2011:
> Tom Lane wrote:
> > "Kevin Grittner" 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 exactly
"Kevin Grittner" writes:
>> Tom Lane 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 the trouble-detection code is these
d
"Kevin Grittner" wrote:
> Tom Lane wrote:
>> "Kevin Grittner" 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 exactly?
>
> All 10 were like this:
>
> warning: deref
Tom Lane 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 pgsql-hackers mail
Tom Lane wrote:
> "Kevin Grittner" 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 dif
"Kevin Grittner" 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 differences. In
> short,
Florian Pflug 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
16 matches
Mail list logo
