| From: | Ants Aasma <ants(at)cybertec(dot)at> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: SP-GiST micro-optimizations |
| Date: | 2012-08-28 19:50:20 |
| Message-ID: | CA+CSw_sGs7mSwFsHR7KKextJUcUeF_nLHjrbtagEgwJAP-bTuA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Aug 28, 2012 at 9:42 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Seems like that's down to the CPU not doing "rep stosq" particularly
> quickly, which might well be chip-specific.
AMD optimization manual[1] states the following:
For repeat counts of less than 4k, expand REP string instructions
into equivalent sequences of simple
AMD64 instructions.
Intel optimization manual[2] doesn't provide equivalent guidelines,
but the graph associated with string instructions states about 30
cycles of startup latency. The mov based code on the other hand
executes in 6 cycles and can easily overlap with other non-store
instructions.
[1] http://support.amd.com/us/Processor_TechDocs/25112.PDF
[2] http://www.intel.com/content/dam/doc/manual/64-ia-32-architectures-optimization-manual.pdf
Ants Aasma
--
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2012-08-28 19:51:00 | Re: Audit Logs WAS: temporal support patch |
| Previous Message | Jim Nasby | 2012-08-28 19:37:49 | Re: Audit Logs WAS: temporal support patch |