Re: [HACKERS] [PATCH] Improve spinlock inline assembly for x86.

2016-01-18 Thread Robert Haas
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

Re: [HACKERS] [PATCH] Improve spinlock inline assembly for x86.

2016-01-18 Thread Peter Geoghegan
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

Re: [HACKERS] [PATCH] Improve spinlock inline assembly for x86.

2016-01-18 Thread Kevin Grittner
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

Re: [HACKERS] [PATCH] Improve spinlock inline assembly for x86.

2016-01-18 Thread Andres Freund
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

Re: [HACKERS] [PATCH] Improve spinlock inline assembly for x86.

2016-01-18 Thread Kevin Grittner
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

Re: [HACKERS] [PATCH] Improve spinlock inline assembly for x86.

2016-01-18 Thread Andres Freund
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

Re: [HACKERS] [PATCH] Improve spinlock inline assembly for x86.

2016-01-18 Thread Kevin Grittner
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 >>

Re: [HACKERS] [PATCH] Improve spinlock inline assembly for x86.

2016-01-18 Thread Andres Freund
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

Re: [HACKERS] [PATCH] Improve spinlock inline assembly for x86.

2016-01-18 Thread Andres Freund
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

[HACKERS] [PATCH] Improve spinlock inline assembly for x86.

2016-01-17 Thread Andreas Seltenreich
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