Re: Spinlocks and CPU Architectures
От | Tom Lane |
---|---|
Тема | Re: Spinlocks and CPU Architectures |
Дата | |
Msg-id | 17604.1129055282@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Spinlocks and CPU Architectures (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: Spinlocks and CPU Architectures
|
Список | pgsql-hackers |
Simon Riggs <simon@2ndquadrant.com> writes: > On Tue, 2005-10-11 at 18:45 +0200, Peter Eisentraut wrote: >> A number of packages in the video area (and perhaps others) do compile >> "sub-architecture" specific variants. This could be done for >> PostgreSQL, but you'd probably need to show some pretty convincing >> performance numbers before people start the packaging effort. > I completely agree, just note that we already have some cases where > convincing performance numbers exist. I'm not sure the data we have is convincing enough to justify sub-architecture packaging. We have a somewhat-artificial test case that's designed to generate the maximum possible spinlock contention, and we can measure a significant difference in that context --- but that's a long way from saying that a similar percentage difference would be seen in real-world applications. It's also a long way from saying that the effort needed to set this up wouldn't be better repaid working on other problems. One thought that comes to mind is that these decisions are probably comparable to those made by gcc conditional on -march flags. Do we get access to the -march setting by means of predefined symbols? If so we could compile different TAS code for opteron and em64t without introducing any packaging issues that didn't exist already. It would essentially be up to the source-code builder which sub-arch to tune for. (Since the assembly code in question currently works only for gcc anyway, I'm not too concerned about making gcc-specific assumptions about the availability of flag macros.) regards, tom lane
В списке pgsql-hackers по дате отправления: