Re: testing HS/SR - 1 vs 2 performance
От | Marko Kreen |
---|---|
Тема | Re: testing HS/SR - 1 vs 2 performance |
Дата | |
Msg-id | r2we51f66da1004231122zc9789db6td117e913ea72ca76@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: testing HS/SR - 1 vs 2 performance (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 4/23/10, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Marko Kreen <markokr@gmail.com> writes: > > Um, you have been burned by exactly this on x86 also: > > http://archives.postgresql.org/pgsql-hackers/2009-03/msg01265.php > > > Yeah, we never did figure out exactly how come you were observing that > failure on Intel-ish hardware. I was under the impression that Intel > machines didn't have weak-memory-ordering behavior. > > I wonder whether your compiler had rearranged the code in ProcArrayAdd > so that the increment happened before the array element store at the > machine-code level. I think it would be entitled to do that under > standard C semantics, since that ProcArrayStruct pointer isn't marked > volatile. Sounds likely. Which seems to hint its better to handle all processors as weak ordered and then work with explicit locks/memory barriers, than to sprinkle code with 'volatile' to supress optimizations on intel and then still fail on non-intel. -- marko
В списке pgsql-hackers по дате отправления: