Re: CUDA Sorting

On 15 February 2012 20:00, Gaetano Mendola <mendola(at)gmail(dot)com> wrote:
> On 13/02/2012 19:48, Greg Stark wrote:
>>
>> I don't think we should be looking at either CUDA or OpenCL directly.
>> We should be looking for a generic library that can target either and
>> is well maintained and actively developed. Any GPU code we write
>> ourselves would rapidly be overtaken by changes in the hardware and
>> innovations in parallel algorithms. If we find a library that provides
>> a sorting api and adapt our code to use it then we'll get the benefits
>> of any new hardware feature as the library adds support for them.
>>
>
> I think one option is to make the sort function pluggable with a shared
> library/dll. I see several benefits from this:
>
>  - It could be in the interest of the hardware vendor to provide the most
> powerful sort implementation (I'm sure for example that TBB sort
> implementation is faster that pg_sort)
>
>  - It can permit people to "play" with it without being deep involved in pg
> development and stuffs.

Sorry, but I find it really hard to believe that the non-availability
of pluggable sorting is what's holding people back here. Some vanguard
needs to go and prove the idea by building a rough prototype before we
can even really comment on what an API should look like. For example,
I am given to understand that GPUs generally sort using radix sort -
resolving the impedance mismatch that prevents someone from using a
non-comparison based sort sure sounds like a lot of work for an
entirely speculative reward.

Someone who cannot understand tuplesort, which is not all that
complicated, has no business trying to build GPU sorting into
Postgres.

I had a patch committed a few hours ago that almost included the
capability of assigning an alternative sorting function, but only one
with the exact same signature as my variant of qsort_arg. pg_qsort
isn't used to sort tuples at all, by the way.

Threading building blocks is not going to form the basis of any novel
sorting implementation, because comparators in general are not thread
safe, and it isn't available on all the platforms we support, and
because of how longjmp interacts with C++ stack unwinding and so on
and so on. Now, you could introduce some kind of parallelism into
sorting integers and floats, but that's an awful lot of work for a
marginal reward.

--
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services