On 2016-01-18 16:56:22 -0600, Kevin Grittner wrote:
> On Mon, Jan 18, 2016 at 4:50 PM, Andres Freund wrote:
>
> > Now I'm equally unconvinced that it's worthwhile to do anything
> > here. I just don't think benchmarking plays a role either way.
>
> Well, that would be the crucial point on which
On Mon, Jan 18, 2016 at 4:50 PM, Andres Freund wrote:
> Now I'm equally unconvinced that it's worthwhile to do anything
> here. I just don't think benchmarking plays a role either way.
Well, that would be the crucial point on which we differ -- the
rest is all agreement. I don't think we should
On Mon, Jan 18, 2016 at 2:39 PM, Kevin Grittner wrote:
>> but I don't think that Andreas' patch is necessarily a
>> performance patch. There can be value in removing superfluous
>> code; doing so sometimes clarifies intent and understanding.
>
> Well, that's why I said I would be satisfied with a
On 2016-01-18 16:14:05 -0600, Kevin Grittner wrote:
> Unconvinced that we should do performance testing on a proposed
> performance patch before accepting it
I'm unconvinced that it makes sense to view this as a performance
patch. And unconvinced that you can sanely measure it. The lock prefix
is
On Mon, Jan 18, 2016 at 4:24 PM, Peter Geoghegan wrote:
> On Mon, Jan 18, 2016 at 2:14 PM, Kevin Grittner wrote:
>> It's hard to understand quite what you're saying there. If you're
>> saying that code changes that should be performance neutral can
>> sometimes affect performance because of ali
On Mon, Jan 18, 2016 at 2:14 PM, Kevin Grittner wrote:
>> You get just as much churn by changing code elsewhere, which
>> often causes code movement and alignment changes.
>
> It's hard to understand quite what you're saying there. If you're
> saying that code changes that should be performance n
On Mon, Jan 18, 2016 at 3:47 PM, Andres Freund wrote:
> On January 18, 2016 10:42:42 PM GMT+01:00, Kevin Grittner
> wrote:
>> I took a look at this and agree that the shorter, simpler code
>> proposed in this patch should make no *logical* difference, and
>> looks like it *should* have a neutra
On January 18, 2016 10:42:42 PM GMT+01:00, Kevin Grittner
wrote:
>On Mon, Jan 18, 2016 at 3:04 PM, Andres Freund
>wrote:
>> On January 18, 2016 7:27:59 PM GMT+01:00, Robert Haas
> wrote:
>>> On Sun, Jan 17, 2016 at 6:38 AM, Andreas Seltenreich
> wrote:
>
While discussing issues with its dev
On Mon, Jan 18, 2016 at 3:04 PM, Andres Freund wrote:
> On January 18, 2016 7:27:59 PM GMT+01:00, Robert Haas
> wrote:
>> On Sun, Jan 17, 2016 at 6:38 AM, Andreas Seltenreich
>> wrote:
>>> While discussing issues with its developers, it was pointed out to me
>>> that our spinlock inline assem
On January 18, 2016 7:27:59 PM GMT+01:00, Robert Haas
wrote:
>On Sun, Jan 17, 2016 at 6:38 AM, Andreas Seltenreich
> wrote:
>> I'm currently experimenting with just-in-time compilation using
>libfirm.
>> While discussing issues with its developers, it was pointed out to me
>> that our spinlock in
On Sun, Jan 17, 2016 at 6:38 AM, Andreas Seltenreich wrote:
> I'm currently experimenting with just-in-time compilation using libfirm.
> While discussing issues with its developers, it was pointed out to me
> that our spinlock inline assembly is less than optimal. Attached is a
> patch that addre
Hi,
I'm currently experimenting with just-in-time compilation using libfirm.
While discussing issues with its developers, it was pointed out to me
that our spinlock inline assembly is less than optimal. Attached is a
patch that addresses this.
,
| Remove the LOCK prefix from the XCHG instruc
12 matches
Mail list logo
