From: | Scott Carey <scott(at)richrelevance(dot)com> |
---|---|
To: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
Cc: | Greg Smith <greg(at)2ndquadrant(dot)com>, Glyn Astill <glynastill(at)yahoo(dot)co(dot)uk>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, "david(at)lang(dot)hm" <david(at)lang(dot)hm>, Steve Clark <sclark(at)netwolves(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Linux: more cores = less concurrency. |
Date: | 2011-04-14 22:42:46 |
Message-ID: | C9CCC426.30A29%scott@richrelevance.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 4/14/11 1:19 PM, "Claudio Freire" <klaussfreire(at)gmail(dot)com> wrote:
>On Thu, Apr 14, 2011 at 10:05 PM, Scott Carey <scott(at)richrelevance(dot)com>
>wrote:
>> Huge Pages helps caches.
>> Dual-Pivot quicksort is more cache friendly and is _always_ equal to or
>> faster than traditional quicksort (its a provably improved algorithm).
>
>If you want a cache-friendly sorting algorithm, you need mergesort.
>
>I don't know any algorithm as friendly to caches as mergesort.
>
>Quicksort could be better only when the sorting buffer is guaranteed
>to fit on the CPU's cache, and that's usually just a few 4kb pages.
Of mergesort variants, Timsort is a recent general purpose variant favored
by many since it is sub- O(n log(n)) on partially sorted data.
Which work best under which circumstances depends a lot on the size of the
data, size of the elements, cost of the compare function, whether you're
sorting the data directly or sorting pointers, and other factors.
Mergesort may be more cache friendly (?) but might use more memory
bandwidth. I'm not sure.
I do know that dual-pivot quicksort provably causes fewer swaps (but the
same # of compares) as the usual single-pivot quicksort. And swaps are a
lot slower than you would expect due to the effects on processor caches.
Therefore it might help with multiprocessor scalability by reducing
memory/cache pressure.
From | Date | Subject | |
---|---|---|---|
Next Message | Claudio Freire | 2011-04-15 06:57:45 | Re: Linux: more cores = less concurrency. |
Previous Message | Claudio Freire | 2011-04-14 20:19:17 | Re: Linux: more cores = less concurrency. |