Re: GSoC - Idea Discussion

From: Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>
To: hitesh ramani <hiteshramani(at)hotmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: GSoC - Idea Discussion
Date: 2015-03-21 01:21:29
Message-ID: 9A28C8860F777E439AA12E8AEA7694F8010C49C2@BPXM15GP.gisp.nec.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> KaiGai Kohei:
> >It seems to me you are a little bit optimistic.
> >Unlike CPU code, GPU-Sorting logic has to reference device memory space,
> >so all the data to be compared needs to be transferred to GPU devices.
> >Any pointer on host address space is not valid on GPU calculation.
> >Amount of device memory is usually smaller than host memory, so your code
> >needs a capability to combined multiple chunks that is partially sorted...
> >Probably, it is not all here.
>
> Aren't there algorithms which help you if the device memory is limited and the
> data is massive? I have a rough memory because I did a course online, where I
> saw algorithms to deal with such problems I suppose.
>
What I took is a hybrid approach to process data set overs device memory
limitation. First, it split input data stream into multiple (= more than
or equal to 1) chunks. Second, it kicks kernel of bitonic-sorting with
key-comparison function generated on the fly. Third, it kicks dynamic
background worker to run merge-sorting logic by CPU.
It does not try to handle all the sorting stuff in GPU. The point we
should not forget is, CPU/GPU is a way to sorting but not a purpose.

Thanks,
--
NEC OSS Promotion Center / PG-Strom Project
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2015-03-21 01:39:49 Re: PATCH: pgbench - merging transaction logs
Previous Message Peter Geoghegan 2015-03-21 00:50:18 Re: Abbreviated keys for Numeric