Re: 64-bit vs 32-bit performance ... backwards?
От | Sven Geisler |
---|---|
Тема | Re: 64-bit vs 32-bit performance ... backwards? |
Дата | |
Msg-id | 448EA989.5000408@aeccom.com обсуждение исходный текст |
Ответ на | Re: 64-bit vs 32-bit performance ... backwards? ("Luke Lonergan" <llonergan@greenplum.com>) |
Ответы |
Re: 64-bit vs 32-bit performance ... backwards?
|
Список | pgsql-performance |
Luke Luke Lonergan schrieb: > On 6/13/06 2:04 AM, "Sven Geisler" <sgeisler@aeccom.com> wrote: >> Please find attached a small patch with does apply a change to the >> x86_64 part also to the i386 part of src/include/storage/s_lock.h. >> Without this change the performance of PostgreSQL 8.0 was horrible on a >> Opteron. The effect is smaller with PostgreSQL 8.1. > > Can you describe what kinds of tests you ran to check your speed? I has create a test scenario with parallel client which running mostly SELECTs on the same tables. I used a sequence of 25 queries using 10 tables. We use the total throughput (queries per second) as result. > > Since it's the TAS lock that you are patching, the potential impact is > diffuse and large: xlog.c, shmem.c, lwlock.c, proc.c, all do significant > work. Yes, I know. We had a problem last year with the performance of the Opteron. We have started the futex patch to resolve the issue. The futex patch itself did have no effect, but there was a side effect because the futex patch did use also another assembler sequence. This make a hole difference on a Opteron. It turned out that removing the lines cmpb jne lock was the reason why the Opteron runs faster. I have created a sequence of larger query with following result on Opteron 875 and PostgreSQL 8.0.3 orignal 8.0.3 => 289 query/time and 10% cpu usage patched 8.0.3 => 1022 query/time and 45% cpu usage I has a smaller effect on a XEON MP with EM64T. But this effect wasn't that huge. There was no effect on classic XEON's. Cheers Sven.
В списке pgsql-performance по дате отправления: